[TSG-Access-RD] [Ext] Re: Bulk Data, Bulk Query, WhoWas and Charter scope

[Hollenbeck, Scott]

LOL, I was literally just writing up my own note with a description of what I think I've read. Thanks, Gavin.

Assuming this is accurate, I do want to ask again if this is a suggested model or a required model, and if it’s a required model, what's driving the requirement. Is there some specific contract language or policy that we need to consider?

Scott

> -----Original Message-----
> From: Gavin Brown <gavin.brown at centralnic.com>
> Sent: Monday, January 7, 2019 7:31 AM
> To: Hollenbeck, Scott <shollenbeck at verisign.com>; andy at hxr.us
> Cc: tsg-access-rd at icann.org
> Subject: [EXTERNAL] Re: [TSG-Access-RD] [Ext] Re: Bulk Data, Bulk Query,
> WhoWas and Charter scope
>
> As I understand it, Francisco is proposing that:
>
> 1. Registries and registrars would provide RDAP services which provide
> redacted* responses to all clients - except ICANN.
>
> 2. ICANN would provide an RDAP service, only available to authenticated and
> authorised parties, which would act as a proxy: queries sent to that RDAP
> service would be forwarded to the registry/registrar, which would return an
> unredacted response to ICANN, which would then return that response to
> the client.
>
> We want an in-band solution that allows an RDAP client to perform a normal
> RDAP query, receive a redacted response from the registry/registrar, and,
> when non-public data is required, re-query the ICANN service for that data.
>
> If the above is correct, then the we need to address the following
> questions:
>
> 1. How do RDAP clients learn the URL of ICANN's RDAP service?
>
>       - an entry in the "links" object with an appropriate relation value
> (which may need to
>       be registered with IANA since I don't see one that's applicable)
> seems like it would
>       work.
>
> 2. How do registries/registrars authenticate ICANN as a client which is
> allowed to receive unredacted records?
>
>       - there are a number of solutions here, from simple IP-based
>       access control to HTTP and TLS-based authentication solutions.
>
> 3. When forwarding an RDAP request, how does ICANN provide (in-band)
> the
> registry/registrar:
>
>       i. which (if not all) non-public data that's been requested
>       ii. the purpose for which the data has been requested
>       iii. the identity of the requesting client
>
>       - IIRC the RDAP RFCs would allow the use of HTTP request
> parameters for this.
>       Otherwise HTTP header fields could be used.
>
> 5. How do RDAP clients authenticate with ICANN?
>
>       - again there are a number of solutions. ICANN can directly identify
> and authenticate
>       clients, but could also use OAuth2/OpenID Connect to allow third-
> party
>       authentication.
>
>       I assume that the authorisation process (determining whether the
> client is permitted
>       to receive the data they are requesting) would all be handled
> internally to ICANN
>       and would therefore not require any sort of interoperable protocol.
>
> G.
>
> * unless the subject has opted in to having their information included in
> responses
>
> On 04/01/2019 19:55, Hollenbeck, Scott via TSG-Access-RD wrote:
> >> -----Original Message-----
> >> From: Andrew Newton <andy at hxr.us>
> >> Sent: Friday, January 4, 2019 1:04 PM
> >> To: Hollenbeck, Scott <shollenbeck at verisign.com>
> >> Cc: francisco.arias at icann.org; tsg-access-rd at icann.org
> >> Subject: [EXTERNAL] Re: Re: Re: [TSG-Access-RD] [Ext] Re: Bulk Data,
> >> Bulk Query, WhoWas and Charter scope
> >>
> >> On Fri, Jan 4, 2019 at 12:56 PM Hollenbeck, Scott
> >> <shollenbeck at verisign.com> wrote:
> >>>
> >>
> >>>> But I disagree. :)
> >>>> I client seeking non-public data would use the non-public data
> >>>> query mechanism and the answer from that should contain both
> >>>> non-public data and public data. Why would it not?
> >>>
> >>> I believe Francisco mentioned that ICANN does not want/intend to
> >>> provide
> >> a public-facing interface for queries that will return public data.
> >>
> >> Why would they filter out the public data from an authenticated query?
> >> I'm not sure what Francisco said, but perhaps the intent was that
> >> they do not intend to be a service for unauthenticated queries.
> >
> > Hence the need for clarity.
> >
> > Scott
> >
>
> --
> Gavin Brown
> Chief Technology Officer
> CentralNic Group plc (LSE:CNIC)
> Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private
> domain name registries https://www.centralnic.com/
> +44.7548243029
>
> CentralNic Group plc is a company registered in England and Wales with
> company number 8576358. Registered Offices: 35-39 Moorgate, London,
> EC2R 6AR.