[TSG-Access-RD] RDAP Operational Models

[Hollenbeck, Scott]

No, that's what the identity providers do. In the pictures where there's no identity provider, authentication would be done by the RDAP server operator.

Scott

> -----Original Message-----
> From: Francisco Arias <francisco.arias at icann.org>
> Sent: Monday, February 4, 2019 8:19 PM
> To: Hollenbeck, Scott <shollenbeck at verisign.com>; tsg-access-rd at icann.org
> Subject: [EXTERNAL] Re: [TSG-Access-RD] RDAP Operational Models
>
> Hi Scott,
>
> Aren't we missing the authenticators in the models?
>
> --
> Francisco
>
> On 2/1/19, 11:18 AM, "TSG-Access-RD on behalf of Hollenbeck, Scott via TSG-
> Access-RD" <tsg-access-rd-bounces at icann.org on behalf of tsg-access-
> rd at icann.org> wrote:
>
>     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
>
>