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

[Andrew Newton]

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