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.
Otherwise we'd need to invent a way to transport identification of the
OP with every RDAP request.
It's not super complicated - either with http header or query parameter
- just there is no standard for that.
The other way around is to require the access tokens to be always JWTs
(per RFC9068), where the iss claim is always there.
This may be too restrictive for some OPs so to support them RDAP server
would need to setup a proxy anyway.
[SAH] Ah, "JWT access token". Are you assuming that "access token" is
something other than the Access Token defined by OAuth? If so, it sounds like
we need to design our own token format.
See above. RFC9068 defines such access tokens.
Kind Regards,
Pawel
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
