> -----Original Message----- > From: Mario Loffredo <[email protected]> > Sent: Friday, November 18, 2022 6:59 AM > To: Pawel Kowalik <[email protected]>; Hollenbeck, Scott > <[email protected]>; [email protected] > Subject: [EXTERNAL] Re: [regext] Web Service Client Flow > > 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. > > Il 18/11/2022 12:19, Pawel Kowalik ha scritto: > > Hi Scott, > > > > Am 17.11.22 um 20:26 schrieb Hollenbeck, Scott: > >>> The RDAP Web Service Client sends queries that require user > >>>> identification, authentication, and authorization to an RDAP server > >>>> that include the ID Token in an HTTP bearer authorization header. > >>> [PK] The client should never be sending ID Token, but access_token > >>> in this case. > >> [SAH] That's a problem, because the Access Token is an opaque value > >> per RFC 6749. If an RDAP server receives only an Access Token along > >> with an RDAP query, it has no way of knowing who the OP is, how to > >> contact that OP, etc. > >> The ID Token identifies that the issuer, which allows the RDAP server > >> to contact the OP - right? > > > > True. This was the reason I posed the question whether we want to > > support "Any OP". Maybe I should have been more specific to ask > > whether we want to support "any OP" as access_token issuer. > > The workable model is to have the the RDAP server integrated with its > > local IdP, which makes identity brokerage to other IdPs. This local > > IdP is then sole token issuer so the problem is gone. The RDAP client > > can be offered with a way of triggering authentication with OP of its > > choice, by using a specific authorization URL. > > Keycloak for example allows for query parameter kc_idp_hint to control > > that. > > > > I would strongly opt for this scenario, as most of the frameworks for > > resource server do not go well with multiple token issuer schema, so > > the implementation would be a way more complex RDAP server side. > > + 1
[SAH] Me too. This is MUCH easier if we don't have to worry about remote OPs. Revised flow: The RDAP Web Service Client sends an RDAP "help" query to an RDAP server to determine the type and capabilities of the OpenID Providers (OPs) that are used by the RDAP server. The RDAP Web Service Client determines the End-User's OP and confirms that it's supported by the RDAP server. The RDAP Web Service Client sends an Authentication Request to the OP. The OP authenticates the End-User. The OP obtains End-User consent/authorization. The OP returns an Authorization Code to the RDAP Web Service Client. The RDAP Web Service Client requests tokens using the Authorization Code at the OP's Token Endpoint. The RDAP Web Service Client receives a response that contains an ID Token and an Access Token in the response body. The RDAP Web Service Client monitors the token validity period and either refreshes the token or requests new tokens as necessary. The RDAP Web Service Client sends queries that require user identification, authentication, and authorization to an RDAP server that include a JWT Access Token [RFC9068] in an HTTP bearer authorization header. The RDAP server validates the Access Token and retrieves the claims associated with the End-User's identity from the Access Token or the local OP. The RDAP server determines the End-User's authorization level and processes the query in accordance with the End-User's authorization level. Scott _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
