The important thing for us to remember and understand here is that we need to ensure that the broadest range of technical options are available to the policy folks on the GNSO PDP, if we artificially (in so far as something that is technically possible and available but we restrict its availability via this process) restrict any options or backload certain technical possibilities we are inadvertently pushing policy into one direction over the other. James Gannon IGM Manager – Projects & IT Security SME -----Original Message----- From: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Francisco Arias Sent: 08 January 2016 01:49 To: Andrew Newton; Andrew Sullivan Cc: gtld-tech@icann.org Subject: Re: [gtld-tech] Draft RDAP Operational Profile for gTLD Registries and Registrars Hi Andy, Defining what should or should not be shown is probably better suited for the new Policy Development Process on Next-Generation gTLD Registration Directory Service. There is a call for volunteers (and observers) at https://www.icann.org/news/announcement-2016-01-04-en Regards, -- Francisco On 1/7/16, 2:21 PM, "gtld-tech-bounces@icann.org on behalf of Andrew Newton" <gtld-tech-bounces@icann.org on behalf of andy@hxr.us> wrote:

First, is it right of me to assume that commenting here is sufficient to be considered providing feedback for this: https://www.icann.org/public-comments/rdap-profile-2015-12-03-en ?

I agree with the general aim and direction of this proposal. Comments in-line:

On Thu, Nov 19, 2015 at 5:57 PM, Andrew Sullivan <asullivan@dyn.com> wrote:

...

I understand the difficulty of specifying a profile where the possible future policy options are not known, but I believe that RDAP was designed with the goal of being able to deliver selectively any field at all depending on the identity of the querying party. Therefore, I think the profile could specify at least three roles: public1, authenticated-full, authenticated-test.

I would call these authorization profiles, not authentication profiles.

...

RDAP services MUST provide a form of authentication service as described in RFC 7481. RDAP services MAY use any of the federated authentication models described in RFC 7481, section 3.2.1.

RDAP services MUST provide differentiated access based on authorization, as described in RFC 7481, section 3.3. RDAP services MUST provide a minimum of three different authorized levels of access, called public1, authenticated-full, and authenticated-test. In the sections that follow, members appropriate to the public1 and authenticated-full roles are marked as appropriate to either or both. Any member not explicitly marked is assumed to appropriate to the authenticated-full role only The authenticated-test role is for testing, and is used to demonstrate the ability to selectively disable response for some field at test time.

RDAP services MAY NOT implement additional differentiated responses based on authorization except as contemplated by ICANN policy or under agreement with ICANN under the RSEP process.

Then, each member mentioned should be marked as "public1", "authenticated-full", or both. I think only the following fields are part of the public1 list:

for domain objects:

objectClassName ldhName unicodeName variants (all of it) nameservers publicIDs, but only when it's used for a registrar secureDNS status

for nameserver objects:

objectClassName ldhName unicodeName ipAddresses

Nothing else goes in public1. I've called this public1 to make it clear that it is but one possible interpretation of what "public access" could be in the future; I'm not wedded to the name.

I would include handle and any remarks the registrant intended for public consumption.

...

Now, the final bit is to make it clear that access that is _un_authenticated will use the authenticated-full role until ICANN policy changes.

The point of all this is to have differentiated role functionality sitting there and ready to go as soon as the ICANN policy changes, and to include in the RDAP deployment policy now all the mechanisms necessary to implement whatever policy the PDP comes up with. By doing it this way, the current policy can be respected while yet laying the ground for the just-launched PDP to do something sane.

I hope this is useful. Apologies again for the long time to send it. If you have further questions, obviously, please don't hesitate to poke me.

I don't know if this is the right place, but it would be nice if something like draft-hollenbeck-weirds-rdap-openid could be implemented as well, say 6 months after it is published as an RFC.

-andy