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

Mon Jan 7 23:47:39 UTC 2019

My bad, Jody, I misspoke. We can only attempt to *diminish* the contracted parties’ legal liability with regard to the GDPR.

-- 
Francisco

On 1/7/19, 1:01 PM, "Jody Kolker" <jkolker at godaddy.com> wrote:

    Thanks Francisco.

    What does "fully shield" in this instance mean?  That ICANN is taking on all legal responsibility for access to the data, including indemnification of contracted parties if a client requesting data is found to not have a legitimate purpose for the data?  

    From a registrar perspective, I would like to be able to determine who is requesting the private data.  

    Thanks,
    Jody Kolker

    -----Original Message-----
    From: TSG-Access-RD <tsg-access-rd-bounces at icann.org> On Behalf Of Francisco Arias
    Sent: Monday, January 7, 2019 1:00 PM
    To: Gavin Brown <gavin.brown at centralnic.com>; Hollenbeck, Scott <shollenbeck at verisign.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

    Hi Gavin,

    Regarding your point 2.3, about how ICANN will provide (in-band) information to the registry/registrar: I believe that in order to fully shield the contracted parties from legal risk, the idea is to *not* share details about the query like justification for the request, or identity of the requestor.

    -- 
    Francisco

    On 1/7/19, 4:31 AM, "TSG-Access-RD on behalf of Gavin Brown" <tsg-access-rd-bounces at icann.org on behalf of gavin.brown at centralnic.com> wrote:

        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.