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

[Tomofumi Okubo]

I think it is a good starting point.

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

For non-public data, this would be an issue as data requester can freely query whatever once the connection is established. I believe there needs to be some sanity check per query for non-public data especially as RDAP allows regex-ish searches.

Cheers,
Tomofumi



On 12/14/18, 3:13 PM, "TSG-Access-RD on behalf of Gavin Brown" <tsg-access-rd-bounces at icann.org on behalf of gavin.brown at centralnic.com> wrote:

    
    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://clicktime.symantec.com/a/1/6JUpJmw0XpLPThVoCpfPIsfMkHRql8tIosrQ2uG_XWo=?d=mZMkVOXcWwFtBIS6LSCKt3ic2uQw_TQg_tKwgKocUBbCepW8iN2XFHhHQCUS6H7HXMleSxXfM5yB5geGhfFcWOZWxkJRKuZGS1-IsVNWjOGh4LZ841v6Xogt1MmmeNyrRXtA3-0HUGl9wpSvb4EJ8UBpMCp9U_Scc8oo71B5Frs4otJ2fBqGBBHv_WPPyG7KRfQ5qOawcIuZ1wlRMCY_9Gfq-631uTfGPFWHS33EZdHd0iv5VMcvH3EySelEow2gF7qVdiqLvCsYNSt3Glf16lr4EoJBg49wGrLLYfPgZDi8nAkBsYTG7zUJt9NGXXZ0O3P_JTn7DoLXBBHKJKb1puzxXZAoATl9GDq_-vzSK-B0D8hfsntotzKrrCI83Z7sERI9NJ-8AKbRWFxUiAO_GsfIynjThgrmgnoFM-t5OjJF9Fo%3D&u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-hollenbeck-regext-rdap-openid%2F
    
    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://clicktime.symantec.com/a/1/MSFIe1ilSiLK-ijai-sTFNZRChg8hXTOTGdGBJ2djHo=?d=mZMkVOXcWwFtBIS6LSCKt3ic2uQw_TQg_tKwgKocUBbCepW8iN2XFHhHQCUS6H7HXMleSxXfM5yB5geGhfFcWOZWxkJRKuZGS1-IsVNWjOGh4LZ841v6Xogt1MmmeNyrRXtA3-0HUGl9wpSvb4EJ8UBpMCp9U_Scc8oo71B5Frs4otJ2fBqGBBHv_WPPyG7KRfQ5qOawcIuZ1wlRMCY_9Gfq-631uTfGPFWHS33EZdHd0iv5VMcvH3EySelEow2gF7qVdiqLvCsYNSt3Glf16lr4EoJBg49wGrLLYfPgZDi8nAkBsYTG7zUJt9NGXXZ0O3P_JTn7DoLXBBHKJKb1puzxXZAoATl9GDq_-vzSK-B0D8hfsntotzKrrCI83Z7sERI9NJ-8AKbRWFxUiAO_GsfIynjThgrmgnoFM-t5OjJF9Fo%3D&u=https%3A%2F%2Fwww.centralnic.com%2F
    +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: smime.p7s
Type: application/pkcs7-signature
Size: 4508 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/tsg-access-rd/attachments/20181217/ed4cdf3b/smime.p7s>