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

[Jody Kolker]

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