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

[Eleeza Agopian]

Hi Scott, all,

With regard to the question of whether this is a suggested or required model: Göran has commissioned this group in order to more deeply explore this particular model, as it may provide an opportunity to diminish the contracted parties’ legal liability with regard to the GDPR. It does not derive from specific contract language or a policy, but rather is an opportunity to explore the technical feasibility of this possible solution.

Eleeza 

-----Original Message-----
From: TSG-Access-RD <tsg-access-rd-bounces at icann.org> On Behalf Of Hollenbeck, Scott via TSG-Access-RD
Sent: Monday, January 7, 2019 4:37 AM
To: gavin.brown at centralnic.com; andy at hxr.us
Cc: tsg-access-rd at icann.org
Subject: Re: [TSG-Access-RD] [Ext] Re: Bulk Data, Bulk Query, WhoWas and Charter scope

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://urldefense.proofpoint.com/v2/url?u=https-3A__www.centralnic.co
> m_&d=DwIGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=YHDWysfNgG
> 9kn4Mk3Oyp9ccgD3bKUf2w88Lvdup8hZw&m=jIucHoG10R5twxUG_C442UUwztdMz8ZVRG
> YDHHhKQ_M&s=NK3gCf5dH1Lw0D6awCRADlnDo3CpvOLziC6x7QhGA4Q&e=
> +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.