Way back when we wrote dynamic registration, we made the decision to always
have the registration token just be a bearer token. Part of this is because
OAuth2 doesn’t really have a separate “access token” data structure that we
could just replicate in this spot, so there’s no “token type” or other meta
parameters around the token value itself that come back. The other reason is
that without a process to dynamically bind the key during registration, it
didn’t make sense to require other credentials alongside the token. For another
example of where this confusion comes into play, just see any of the discussion
here about whether the DPoP binding applies to the refresh token, which comes
alongside the access token.
I think you’re absolutely right that things like DPoP (and even MTLS, or
alternatives like HTTP Signatures) raise the question of binding the
registration token in the same way that you can bind other access tokens. To do
this, though, you’d need to extend dynamic registration’s response. I think
you’ve got the right idea here, but you’d need to add a bunch of signaling in
the request and response. I think a dopp-specific flag, or a new field instead
of “registration_access_token” would both do the job with different properties.
You’d also need to define how to use the DPoP proof at the registration request.
All of that seems like it’d fit neatly into a self-contained extension of
dynamic registration.
— Justin
> On Mar 12, 2022, at 7:32 PM, Nicolas Mora wrote:
>
> Hello,
>
> While reading the last DPoP document (draft 6), I was wondering about other
> access tokens delivered by the AS, especially the Registration Access Token
> during Dynamic Client Management Registration [1].
>
> The OAuth 2.0 Dynamic Client Registration Management Protocol RFC states
> that: [2]
>
> "(D) The authorization server registers the client and returns:
> [...]
> * a registration access token to be used when calling the
>client configuration endpoint."
>
> I'm considering the DPoP objectives would be relevant when using the Dynamic
> Client Registration Management Protocol, when the AS provides an access token
> for client.
>
> Although, adding the DPoP proof JWT during the client registration would be
> different than in the /token endpoint. The client registration endpoint can
> be authorized by an access token, therefore this access token can be enforced
> using DPoP.
>
> A solution I thought of is to add the DPoP proof in the client registration
> request itself.
>
> The following example is a sample showing a client registration authorized
> through an access token enforced with DPoP, and a DPoP proof inside the
> registration request. The DPoP jkt will then be attached to the registration
> access token, so the registered client would have to add a DPoP proof each
> time it calls the Client Registration Management endpoint.
>
> POST /register HTTP/1.1
> Content-Type: application/json
> Accept: application/json
> Host: server.example.com
> Authorization: DPoP Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU
> DPoP: eyJ0eXAiOiJkcG9[...]xyz
>
> {
> "redirect_uris": [
>"https://client.example.org/callback;,
>"https://client.example.org/callback2;],
> "client_name": "My Example Client",
> "client_name#ja-Jpan-JP":
> "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
> "token_endpoint_auth_method": "client_secret_basic",
> "logo_uri": "https://client.example.org/logo.png;,
> "jwks_uri": "https://client.example.org/my_public_keys.jwks;,
> "example_extension_parameter": "example_value",
> "DPoP": "eyJ0eXAiOiJkcG9[...]abc"
> }
>
> The client registration DPoP content should use a different key and a
> different jti than the one used with the DPoP access token, but the htm and
> htu values would be the same.
>
> Any thought about that?
>
> /Nicolas
>
> [1] https://datatracker.ietf.org/doc/html/rfc7592
> [2] https://datatracker.ietf.org/doc/html/rfc7592#section-1.3
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
