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

[Andrew Sullivan]

Dear colleagues,

At the Dublin ICANN meeting I made some comments at the microphone and
said I'd send text.  So,

On Mon, Sep 28, 2015 at 11:07:09PM +0000, Francisco Arias wrote:
> IETF in Yokohama. Your feedback on this early document would be greatly
> appreciated by 9 November 2015.

…here I am, late by only 10 days.  I do apologise to all of you and
especially to ICANN staff.  I'd sincerely hoped that at least on the
way to the IGF meeting I'd be able to do something about this, but I
found I was unable.  In any case, in case these comments are still
useful, here they are.

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.  

    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.

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.

Best regards,

A

-- 
Andrew Sullivan
Dyn
asullivan at dyn.com