[gtld-tech] Draft RDAP Operational Profile for gTLD Registries and Registrars

[Gannon, James-1]

Precisey.

Sent from my iPhone

> On 8 Jan 2016, at 18:42, Andrew Newton <andy at hxr.us> wrote:
> 
> So I believe that is addressed in Andrew's proposal.
> 
> What we don't want is for the PDP to make a recommendation only to
> have people say, "but the gTLD profile doesn't support tiered access."
> 
> -andy
> 
> On Thu, Jan 7, 2016 at 8:48 PM, Francisco Arias
> <francisco.arias at icann.org> wrote:
>> 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 at icann.org on behalf of Andrew Newton" <gtld-tech-bounces at icann.org on behalf of andy at 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 at 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