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

[Eleeza Agopian]

Thanks, Gavin for providing those terms. I've added them to a Google doc that captures some proposed definitions. Feel free to edit/add to these as useful: https://docs.google.com/document/d/1XaLDOD5LdOKpLexmwYEJn_uCdDQLTUrwY1SDdCWpQF8/edit 

I've proposed definitions for public and non-public data. The definitions for authentication/authorization include citations. These came from Francisco and his team.  

Thank you,
Eleeza

-----Original Message-----
From: TSG-Access-RD <tsg-access-rd-bounces at icann.org> On Behalf Of Andrew Newton
Sent: Friday, December 14, 2018 10:07 AM
To: Gavin Brown <gavin.brown at centralnic.com>
Cc: tsg-access-rd at icann.org
Subject: Re: [TSG-Access-RD] Useful resource on OAuth2/OpenID Connect

That's a great video, and I like the idea of using those terms.

-andy
On Fri, Dec 14, 2018 at 12:13 PM Gavin Brown <gavin.brown at centralnic.com> wrote:
>
> I know we have yet to agree on a charter but I don't think there's any 
> harm in starting to explore the solution space.
>
> I've been meaning to get my head around OAuth2 and OpenID Connect for 
> some time, being aware of the work of Scott and Marc Blanchet of 
> Viagenie on using OpenID Connect to authenticate RDAP queries.
> Suspecting that any protocol we might produce will be based on them, I 
> spent some time today looking for an "idiot's guide" and found this 
> video on YouTube which I think is worth an hour of your time:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_w
> atch-3Fv-3D996OiexHze0&d=DwICAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7x
> cl4I5cM&r=YHDWysfNgG9kn4Mk3Oyp9ccgD3bKUf2w88Lvdup8hZw&m=Sd5PK8_P0HVkcd
> 5mOHbUFJIgRqFE-i7XTKm_hN79JM8&s=GzwsxCU4-FavVKB_NdRcdAM8S7TvwOqov8e4mc
> KEtTE&e=
>
> I've tried to conceptualise how the different parts of OAuth2 might 
> map onto our use case:
>
> * "Resource owner" - for us, this would not be owner of the 
> registration data, but the person requesting access to non-public registration data.
>
> * "Authorisation server" - this would be operated by ICANN, but could 
> redirect to other authorisation servers. The might also redirect to a 
> third-party authentication server.
>
> * "Resource server" - this is an RDAP server. It seems as though a way 
> for ICANN and RO to agree on a client's access token is needed.
>
> * "Authorisation grants" - one difference to the traditional OAuth2 
> model is that the specific permissions granted are determined by the 
> authz server, not the user.
>
> Scott - any thoughts on the above?
>
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.centralnic.co
> m_&d=DwICAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=YHDWysfNgG
> 9kn4Mk3Oyp9ccgD3bKUf2w88Lvdup8hZw&m=Sd5PK8_P0HVkcd5mOHbUFJIgRqFE-i7XTK
> m_hN79JM8&s=sQqAPb_ka8nRGMLC1HAFovIqITeCEIgClCDhRvIflJc&e=
> +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.
>
>