Hi Scott,
Am 17.11.22 um 15:47 schrieb Hollenbeck, Scott:
Is this a correct sequence of steps for a web service client 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.
[PK] All OK till here.
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.
The RDAP server validates the ID Token, exchanges it for an Access Token, and
retrieves the claims associated with the End-User's identity from the OP.
[PK] RDAP server needs to validate the access_token. It would be done
either by introspection (call to OP)
or if it's JWT it can be validated offline.
Access token may either contain all needed information in its claims, or
also additional identity
information can be requested by RDAP server from OP's user-info endpoint
using the access token.
The RDAP server determines the End-User's authorization level and processes
the query in accordance with the End-User's authorization level.
Note that this requires the RDAP server to contact the OP as part of
processing every query that requires authorization.
[PK] In most basic and not optimized implementation yes. Caching of the
information would be a typical choice to avoid that.
Quite common practice is to include all needed information in the JWT
access token to avoid these kind of calls.
It's easy to assure for that with an OP being well integrated with the
RDAP server, less likely for public OPs.
Kind Regards,
Pawel
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
