Subject: [OAUTH-WG] DPoP and Client Registration Access Token

From: Nicolas Mora <[email-masked]>
Date: Sat, 12 Mar 2022 19:32:47 -0500

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

---

From: Justin Richer <[email-masked]>
Date: Thu, 17 Mar 2022 15:15:09 -0400

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 <[email-masked]> 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]
> 
> 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
> 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
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth