Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-19.txt

[Pawel Kowalik <[e-mail]>]

Hi Scott,

Thanks for the progress on that.


I have the following remarks:

- 3.1.1 refers to "Access Token" in RFC9068 instead of RFC6749. I think 
this might be misleading to exclude opaque access tokens just by 
redefining it in the terminology. If the intention is to limit to "JWT 
Access Token" then I would state it in explicit way. If it was not the 
intention then I would define a second term "JWT Access Token" and then 
refer to it where appropriate (see remarks to Section 6 below).

- I would rename the section 3.1.5.  "Specialized Claims for RDAP" to 
"Specialized Claims and Authorization Scope for RDAP" (see below remarks 
to section 6.1)

- in the Section 3.1.3 the Sequence diagram for session-oriented client 
should also contain RDAP server <-> OP interactions to correspond to the 
sequence diagram of token-oriented clients

- in the Section 4.1 I propose to add an additional member to the object 
in openidcProviders array:

   - "additionalAuthorizationQueryParams" being an object where each 
member represents query parameter name and value is the query parameter 
value
   This metadata will allow Token-Oriented Client to trigger 
authorization with a specified OP through Proxy OP, even if the iss and 
authorization endpoints are same. With Keycloak as example this can be 
controlled with "kc_idp_hint" parameter, so the example configuration 
would be:

    "openidcProviders":
             [
               {
                 "iss": "https://local-idp.rdap.example.com",
                 "name": "Example Public IDP",
                 "additionalAuthorizationQueryParams": {
                    "kc_idp_hint": "examplepublicidp"
                 }

               }

             ]

- the Section 5.3 is generic, not depending on client type, so it should 
move to Section 4

- same applies to Section 5.7

- in OAuth2 the authorization is done using scopes. I think in the 
Section 6.1 the RP should always require scope "rdap". Also the usage of 
additionalAuthorizationQueryParams shall be added here.

- in 6.1 it may be necessary to  add also that the OP SHOULD include the 
RDAP server in the "aud" claim of the issued token. Alternatively RDAP 
server may choose to ignore the "aud" claim or exchange the token (as 
described in the section 7)

- we discussed that we do not care that much about remote OPs, however 
the issue of access_token coming from an unknown OP remains. My proposal 
for a simple solution would be just to require a query parameter "OP 
Issuer Identifier" with each RDAP query for non-default OP server. This 
would be an add to 6.2

- the section 6 should have a subsection about access token validation 
including:

   - processing of "OP Issuer Identifier" query parameter and (optional) 
token introspection with OP or validation of the JWT access token - this 
would be mainly reference to OAuth2 RFCs

   - checking "rdap" scope in the access token

   - optional request for User Claim (as needed by the RDAP server) with 
an indication about performance implications and hint for caching

- I would also add token refresh consideration to the Section 6, namely 
that the RP needs to take care about refreshing the token as necessary 
before sending requests to RDAP server

- Section 7 only applies to Token-Oriented Clients, so it belongs under 
Section 6


Kind Regards,

Pawel

Am 02.12.22 um 15:27 schrieb Hollenbeck, Scott:
>> -----Original Message-----
>> From: regext <[e-mail]> On Behalf Of [e-mail]
>> Sent: Friday, December 2, 2022 9:26 AM
>> To: [e-mail]
>> Cc: [e-mail]
>> Subject: [EXTERNAL] [regext] I-D Action: draft-ietf-regext-rdap-openid-19.txt
>>
>> Caution: This email originated from outside the organization. Do not click links
>> or open attachments unless you recognize the sender and know the content is
>> safe.
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Registration Protocols Extensions WG of the
>> IETF.
>>
>>          Title           : Federated Authentication for the Registration Data Access
>> Protocol (RDAP) using OpenID Connect
>>          Author          : Scott Hollenbeck
>>    Filename        : draft-ietf-regext-rdap-openid-19.txt
>>    Pages           : 46
>>    Date            : 2022-12-02
>>
>> Abstract:
>>     The Registration Data Access Protocol (RDAP) provides "RESTful" web
>>     services to retrieve registration metadata from domain name and
>>     regional internet registries.  RDAP allows a server to make access
>>     control decisions based on client identity, and as such it includes
>>     support for client identification features provided by the Hypertext
>>     Transfer Protocol (HTTP).  Identification methods that require
>>     clients to obtain and manage credentials from every RDAP server
>>     operator present management challenges for both clients and servers,
>>     whereas a federated authentication system would make it easier to
>>     operate and use RDAP without the need to maintain server-specific
>>     client credentials.  This document describes a federated
>>     authentication system for RDAP based on OpenID Connect.
> [SAH] This is my first attempt for text that addresses token-oriented clients. I'd greatly appreciate review and feedback.
>
> Scott
>
> _______________________________________________
> regext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext

-- 
Pawel Kowalik
Head of Product Management
--
DENIC eG, Kaiserstraße 75 - 77, 60329 Frankfurt am Main, GERMANY
E-Mail: [e-mail], Fon: ‭[phone]‬
https://www.denic.de

Angaben nach § 25a Absatz 1 GenG: DENIC eG (Sitz: Frankfurt am Main)
Vorstand: Thomas Keller, Martin Küchenthal, Andreas Musielak, Sebastian Röthler
Vorsitzender des Aufsichtsrats: Daniel Rink
Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht Frankfurt am Main

Allgemeiner Hinweis zur Erfüllung unserer Informationspflichten gemäß Art. 13, Art. 14 DS-GVO: Informationen zur Verarbeitung personenbezogener Daten durch DENIC finden Sie unter https://www.denic.de/datenverarbeitung-allgemein/