DPoP key binding via cnf.jkt in RFC7523 client assertions as an alternative

[matthieusieben]

I am very glad to see that the draft is progressing and, in particular, that there is traction to make things better for DPoP.

Could I ask you to consider the problem from the perspective of OAuth profiles already built on RFC9449 (DPoP) and RFC7523 (JWT client assertions)?

When both are in use, the AS already processes payloads of the following shape:

POST /token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik\
  VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR\
  nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE\
  QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiItQndDM0VTYzZhY2MybFRjIiwiaHRtIj\
  oiUE9TVCIsImh0dSI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIiwia\
  WF0IjoxNTYyMjYyNjE2fQ.2-GxA6T8lP4vfrg8v-FdWP0A0zdrj8igiMLvqRMUvwnQg\
  4PtFLbdLXiOSsX0x7NVY-FNyJK70nfbV37xRZT3Lg

grant_type=authorization_code&
code=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4&
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A
client-assertion-type%3Ajwt-bearer&
client_assertion=eyJhbGciOiJSUzI1NiIsImtpZCI6IjIyIn0.\
  eyJpc3Mi[...omitted for brevity...].\
  cC4hiUPo[...omitted for brevity...]

These AS already implement DPoP header verification and client_assertion JWT validation. In that context, binding the client assertion to the DPoP key can be as simple as embedding the DPoP key thumbprint in the cnf.jkt claim of the client assertion. This is essentially a one-line spec change and a minimal implementation.

The current draft introduces a new token_endpoint_auth_method and a new OAuth-Client-Attestation header with semantics that largely overlap with mechanisms already defined in RFC7523 and RFC9449. The result is an additive design that diverges from existing primitives rather than composing with them.

Starting from those existing RFCs instead would, I believe:

• lower the barrier to adoption, since implementations already handling DPoP and JWT client assertions require minimal changes,
• allow simpler partial adoption (e.g. the DPoP binding alone, without a new auth method),
• reduce the overall complexity added to the OAuth ecosystem.

[matthieusieben]

Just to clarify things, I am not opposed to the creation of a new token_endpoint_auth_method per say. I think that being able to distinguish that the client attestation should be bound to the dpop key somehow is required.

My point is that an alternate version of this draft could also be written as a new client_assertion_type, which already has a IANA registry, existing implemetations, etC.

[c2bo]

My point is that an alternate version of this draft could also be written as a new client_assertion_type, which already has a IANA registry, existing implemetations, etC.

That was our initial idea and also what the draft started with and after pretty long discussions the decision was made to move away from client_assertion to the current header based syntax - see this PR: #74

[matthieusieben]

Found the IETF 119 slides and minutes, thank you.

[matthieusieben]

I believe that my point still stands though.

It seems as though a new PoP mechanism was introduced, which is not DPoP, which resulted in the duplicate PoP mechanism (when DPoP is also used), and the ~ concatenation approach which was "criticized" during IETF 119. This, in turn became a new header (for reasons that are not directly clear to me though).

If this entire draft had been written on top of existing primitives (RFC7523 and RFC9449), it feels to me that it might not have reached the status it currently is in.

If it did use DPoP as basis, this draft could potentially be split in three, much smaller, parts, that would me much easier to compose from:

1. A new client_assertion_type that uses client_assertion in the body (as designed by RFC7523) + the DPoP header for token auth.

2. A new OAuth-Client-Attestation header for resource server requests that need a recent client attestation.

3. An endpoint for getting the nonce.

What am I missing that makes me not understand why such a complex system is required (a new PoP mechanism, new headers, a new "Concatenated Serialization Format" syntax, etc.) ?

[matthieusieben]

We are interested in adopting an Attestation-Based Client Authentication mechanism in ATproto (as discussed in #123).

In that context, we don't really care about 1) having a fresh client attestation for resource endpionts and 2) about fetching the PoP nonce ahead of time. All we really want is DPoP bound client attestation at the AS's endpoints.

Similarly, our distributed system has multiple implementations (both server and client side), which we don't control, and for which we already got tons of feedback saying that the oauth profile is pretty complex (we have a user literally selling master classes for it).

The current state of this draft makes it really hard for us to adopt because we only need part of it, and we need to keep our OAuth profile as simple as can be.

I feel like it would be beneficial, not only for us, but for the whole OAuth community to be able to rely on one(multiple) simpler spec(s).

[paulbastian]

I see some issues of re-using RFC7523:

• the title says that this is a JWT Bearer token, which a Client Attestation JWT is not
• it is designed for a model, where the Issuer of the Bearer-JWT already knows the Authorization Server, that the OAuth client wants to interact with:

The JWT MUST contain an "aud" (audience) claim containing a
value that identifies the authorization server as an intended
audience.

• this is incompatible with the design ideas of Attestation-Based Client Authentication, where the Issuer of the client attestation should not learn whom the OAuth client is interacting with.
• so while combining this with RFC7523 makes no sense to me, we see the value of using DPoP as the proof of possession mechanism (despite a number of downsides of DPoP itself) - this is a way forward that was extensively discussed and also has a current PR (beware, the PR is rather stale, @tplooker to provide an update in the coming days)

[matthieusieben]

Hey @paulbastian, thank you for your answer, and for your patience helping me understand how Attestation-Based Client Authentication is meant to work. This super helpful!

---

the title says that this is a JWT Bearer token, which a Client Attestation JWT is not

You are right, though I don't think that that spec actually meant for those JWT to be used as Authorization: Bearer <token> header. In my read "bearer" should be interpreted as "the client can present this token to prove it was issued this attestation". Indeed, RFC7523 only talks about using those tokens as client_assertion or assertion parameter for token requests, and never in any header.

In my previous suggestion to describe:

2. A new OAuth-Client-Attestation header for resource server requests that need a recent client attestation.

Those the client attestation tokens would be used not as "Bearer tokens", but as simple attestation indeed. The actual Bearer in those requests to the resource server would be the access token anyway.

---

The JWT MUST contain an "aud" (audience) claim containing a value that identifies the authorization server as an intended audience.

this is incompatible with the design ideas of Attestation-Based Client Authentication, where the Issuer of the client attestation should not learn whom the OAuth client is interacting with.

I also see this extract from the draft's intro, which probably explains the motivation for omitting the "aud":

In ecosystems such as the Issuer-Holder-Verifier model used in [SD-JWT], this model raises privacy concerns, as it would enable the backend to recognize which Holder (i.e. client) interacts with which Issuer (i.e. Authorization Server)

Could you expand on the actual privacy threat here? I would typically expect both the Client Attester and Client Instance to be part of the same deployment and be controlled by the same actor. That actor has full control over both parts of the Client.

[c2bo]

Could you expand on the actual privacy threat here? I would typically expect both the Client Attester and Client Instance to be part of the same deployment and be controlled by the same actor. That actor has full control over both parts of the Client.

We have been influenced quite a bit by looking at this from a smartphone perspective: You might have installed an App and require certain guarantees about state, authenticity etc. of said app / client when interacting with other parties in an ecosystem (e.g.,, an AS or RS where AS and RS are completely different parties from the App provider). In that scenario, the App provider would create such attestations for Apps, but should not be able to learn about interactions between the App and other parties.

We are using this mechanism for example in OpenID for Verifiable Credential Issuance 1.0 as a "Wallet Attestation" - a statement that the other party (in this case credential issuer) is interacting with a known/valid Wallet. In our case, the Issuer and Wallet Provider (provider of the app and of the client attestations) are completely separate entities and the Wallet Provider should not learn about interactions with specific issuers - the Wallet provider in general should not be able to learn how and where the Wallet is used.