[gtld-tech] Draft RDAP Operational Profile for gTLD Registries and Registrars
Francisco Arias
francisco.arias at icann.org
Fri Jan 8 01:48:33 UTC 2016
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: 4564 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20160108/c9f70e01/smime.p7s>
More information about the gtld-tech
mailing list