[TSG-Access-RD] Useful resource on OAuth2/OpenID Connect

[Gavin Brown]

On 14/12/2018 18:58, Hollenbeck, Scott wrote:

[snip]

> These look fine. Anyone who cares to see how I've tried to apply these concepts to a model for RDAP may want to read through my Internet-Draft:
> 
> https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rdap-openid/

One thing I note from reading this draft is that the RDAP server relies
on the Identity Provider for authentication only; authorization is done
on the RDAP server itself.

If ICANN is to perform the authorization function, then the grants need
to be determined by the authorization server, which would also do the
authentication (potentially relying on other third parties): in fact, it
may be the case that the RDAP server might not even need to know the
identity of the user; only that ICANN has authorised that client to have
some level of access (my assumption is that some operators would want
this information in order to satisfy their own legal obligations, but it
may be that others might not).

So I think users are going to need to follow a two-step process of
authentication and authorisation, as per the following, which I present
below as a straw man, based on the flow that Scott describes in Section
3.1.2 of his draft.

I have the servers communicate using the "front channel", which I think
is preferable to having them communicate via a "back" channel (assuming
that it provides appropriate security, is more scalable, and keeps ICANN
out of the critical path of handling RDAP queries):

1.  The RDAP client sends a query containing OAuth 2.0 request
parameters to the RDAP server.

2. The RDAP server prepares an Authorization Request and sends the
client to ICANN's Authorization server via HTTP redirect.

3. The Authorization server uses the OpenID Connect Discovery protocol
to identify the client's Authentication server (this may be an ICANN
server but could be another party's), prepares an Authentication Request
and sends the client to the Authentication server via HTTP redirect.

4. The Authentication Server authenticates the client.

5. The Authentication Server sends the client back to the Authorization
server with an ID token using an HTTP redirect.

6. The Authorization server determines the appropriate authorization
grants and sends the client back to the RDAP server with an Access Token
using an HTTP redirect.

7. The RDAP server validates the ID and/or access token and returns the
response to the client. Subsequent requests would bypass steps 2-6.

G.

-- 
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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mm.icann.org/pipermail/tsg-access-rd/attachments/20181214/449138e0/signature.asc>