[TSG-Access-RD] FW: RDAP Operational Models

[Jody Kolker]

<<
To be clear, are you proposing considering having a contracted party play the role of authorizing agent for access to the data they hold?
>>

Yes - Any model needs to support the idea that data holders have the ability to authorize entities to access their data.  Unless ICANN is unwilling to indemnify CPHs for fines levied due to entities that have been approved by ICANN (either directly or indirectly) leaking the private data, I don't see how CPHs will allow any entities but CPH approved entities to access the data. 

I think we have missed an important assumption:  ICANN will indemnify CPHs if CPHs are fined for data that was required to be released by the ICANN system or policies.

Registrars/Registrys have been whitelisting entities to receive access to whois port 43 for years.
  
Thanks,
Jody Kolker

-----Original Message-----
From: Francisco Arias <francisco.arias at icann.org> 
Sent: Monday, February 4, 2019 7:33 PM
To: Jody Kolker <jkolker at godaddy.com>; tsg-access-rd at icann.org
Subject: Re: [TSG-Access-RD] FW: RDAP Operational Models

Jody,

Per our charter, the model we are being asked to consider has ICANN as the only party acting as proxy for access to non-public data. However, there could be multiple parties authorizing access to the data. I suppose an organization could be accredited to be an authorizing agent, even if that same organization also plays the role of contracted party? 

To be clear, are you proposing considering having a contracted party play the role of authorizing agent for access to the data they hold?

-- 
Francisco

On 2/4/19, 10:59 AM, "TSG-Access-RD on behalf of Jody Kolker" <tsg-access-rd-bounces at icann.org on behalf of jkolker at godaddy.com> wrote:

    
    Thanks for creating the visual models of these Scott.
    
    All listed models are based on the presumption that ICANN will either validate clients or will validate entities that would validate clients (identity providers).  Without an indemnification agreement between the registrars/registries(CPH) and ICANN, I don't see how registrar/registries legal or policy departments will approve any of the these three models.  I'm not sure how likely ICANN is to enter into this type of agreement.  Without that agreement, CPHs will want to approve clients themselves.  Therefore I think this model needs to be discussed and listed.
    
    In regards to the fourth model:
    <<
    Are there any other models worth capturing? I didn't mention "Direct client-to-registry/registrar services with client identification/authentication responsibilities held by the registries/registrars" because we've already discussed how that model doesn't scale well. It would be worth mentioning in the text only to note that it was discussed and dismissed.
    >>
    
    
    
    Thanks,
    Jody Kolker
    
    
    -----Original Message-----
    From: TSG-Access-RD <tsg-access-rd-bounces at icann.org> On Behalf Of Hollenbeck, Scott via TSG-Access-RD
    Sent: Friday, February 1, 2019 1:18 PM
    To: tsg-access-rd at icann.org
    Subject: [TSG-Access-RD] RDAP Operational Models
    
    I just uploaded three documents to the Google Drive as part of the effort Andy and I volunteered for to develop background material for our final output. They're named "RDAP Model X", and each document contains a drawing of interactions between players in different operational scenarios. I'm suggesting that we should describe as many of these models as we can identify to better document available options.
    
    RDAP Model 1: AN ICANN-run proxy service with client identification/authentication responsibilities delegated to identity providers.
    
    RDAP Model 2: AN ICANN-run proxy service with client identification/authentication responsibilities held within ICANN.
    
    RDAP Model 3: Direct client-to-registry/registrar services with client identification/authentication responsibilities delegated to identity providers.
    
    Are there any other models worth capturing? I didn't mention "Direct client-to-registry/registrar services with client identification/authentication responsibilities held by the registries/registrars" because we've already discussed how that model doesn't scale well. It would be worth mentioning in the text only to note that it was discussed and dismissed.
    
    Scott