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 <regext-boun...@ietf.org> On Behalf Of internet-dra...@ietf.org
Sent: Friday, December 2, 2022 9:26 AM
To: i-d-annou...@ietf.org
Cc: regext@ietf.org
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
regext@ietf.org
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: pawel.kowa...@denic.de, Fon: +49 173 3087096
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/
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
