[TSG-Access-RD] Access Control Protocol in the Charter

[Hollenbeck, Scott]

> -----Original Message-----
> From: TSG-Access-RD <tsg-access-rd-bounces at icann.org> On Behalf Of
> Hollenbeck, Scott via TSG-Access-RD
> Sent: Wednesday, December 12, 2018 9:34 AM
> To: tsg-access-rd at icann.org
> Subject: [EXTERNAL] [TSG-Access-RD] Access Control Protocol in the Charter
>
> I'd like to discuss the "Access Control Protocol" section of the draft charter a
> bit more...
>
> As discussed on the 11 December call, this section presumes an operating
> model in which ICANN operates a centralized access interface. Queries for
> "non-public" registration data are received at this interface and forwarded to
> registries and registrars for processing. Registries and registrars will be the
> primary interface for "public" registration data. Is this correct?
>
> If it is, I'm concerned that this model can make things more difficult for RDAP
> clients. They have to worry about sending two queries to two different
> servers to retrieve a full response when they have no idea which elements
> are in the "public" data set and which elements are in the "non-public" data
> set. Attempts to hard-wire that knowledge into the code aren't wise,
> because policies change and they have to deal with differences in operating
> behavior for servers operated by gTLD providers, ccTLD providers, and
> address registry providers.
>
> Query bootstrapping as described in RFC 7484 may be made more
> complicated. The Bootstrap Service Registry for Domain Name Space allows
> multiple URLs to be associated with a label, but it doesn't explicitly say that a
> client should need to query each specified URL. Section 4 of says, "The client
> chooses one of the base URLs from this array". An RFC-compliant client could
> thus miss a second server.
>
> So, I would feel more comfortable with this section of the charter if it were
> focused on centralized authorization without making assumptions about an
> operating model. Perhaps something like this:
>
> Access Control Protocol
> 1. How could a centralized authorization interface operated by ICANN work?
> 2. How could access to non-public registration data be granted only to clients
> that are authorized by ICANN?
> 3. How could ICANN, in its role as the authorizing party, receive a third-party
> request for access to non-public registration data?
> 4. Categorization/prioritization of RDS data fields: Should all the fields be
> collected in one place? If so, should we design a protocol that allows for the
> categorization of these fields and the prioritization of the request response?

Thinking a bit more, are we constrained to considering only a centralized authorization scheme? Centralized accreditation with distributed authorization is also a workable possibility.

Scott