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

[Gannon, James-1]

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 at icann.org [mailto:gtld-tech-bounces at icann.org] On Behalf Of Francisco Arias
Sent: 08 January 2016 01:49
To: Andrew Newton; Andrew Sullivan
Cc: gtld-tech at 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 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5095 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20160108/e61ff025/smime-0001.p7s>