Similar proposal in AT Protocol: DPoP-bound private_key_jwt client authentication

[devinivy]

In AT Protocol we've recently published a proposal that takes a similar shape and fills similar use cases to attestation-based client authentication as described in the draft being worked on here. It can be found here: 0010-client-assertion-backend. Once the proposal is finalized, it could end up being widely adopted in the AT Protocol ecosystem, as we have many folks who want to author browser-based clients that are given the security and UX affordances of a confidential client.

We wanted to share our use case and our thinking with the hopes that we may be able to converge on something compatible with the work being done here.

Rather than proposing a new client authentication method, we opted to layer a small mechanism on top of the private_key_jwt method from RFC 7523. It's quite limited:

[If] the client_assertion JWT contains a cnf claim using the jkt method (JWK Thumbprint Confirmation Method) then it MUST be validated by the AS against the public key of the request’s DPoP proof.

The result is DPoP-bound client assertions, which fits neatly with existing DPoP-bound authorization flows, i.e. both authorization code and access token binding as described in RFC 9449. We considered the need for separate client keys in the client attestation vs. the authorization flow in our proposal, as has been raised in #67 and more recently #74. We do not anticipate any practical issues with using a single PoP key and mechanism, but would be interested to continue getting to the bottom of that question.

On the flip side, we certainly see many benefits to using a single PoP mechanism across these OAuth flows. We found the following benefits aligning on DPoP and private_key_jwt client authentication:

• overall the specification becomes much smaller:
  • answers questions around the nonce mechanism, as actively discussed in Support returning nonce in any responses, similar to DPoP #101 and Evolution of the nonce fetching #110.
  • supports authorization code binding, as discussed in Authorization code binding to client instance #56.
  • supports binding the PoP to the attestation used to authenticate, as discussed in PoP attestation binding  #47.
  • answers to the attack surface area when used in conjunction with DPoP-bound access tokens, as discussed in Usecase: authenticating the key used for DPoP bound access tokens back to the client #69.
• as a result it's more straightforward for client implementers, particularly those who already implement DPoP-bound access tokens, which we believe will continue to rise in popularity. Fewer novel PoP implementations on the client side has its security benefits too.

That's where we're currently at—appreciate the consideration from this group, and the work being done on this draft.

[c2bo]

We had a long discussion about DPoP and in general what mechanism to use for nonce/challenge retrieval. The problem with only relying on DPoP is that for a part of the use-cases interested in this mechanism, the current mode of getting a fresh DPoP nonce is problematic:

• DPoP nonces can be retrieved from an error or from any previous response
• Triggering an error is somewhat ambiguous, the usual way is to create a valid request with an invalid/no nonce and then retrieve a fresh nonce
• This requires a valid request which might be expensive (requires user interaction or a call to a remote system)

Especially in the context of smartphone interactions (e.g., digital wallets), interactions would often happen for the first time with a specific AS (e.g., credential issuance). In those cases, it is highly beneficial to be able to explicitly request a fresh nonce/challenge to avoid additional roundtrips or even worse user confirmation. It also feels a lot cleaner than somehow trying to create an error case.
From my perspective, those are the main motivations to deviate from the DPoP model here.

[matthieusieben]

If this is the main motivation, wouldn't it be simpler to add a small spec for a dpop_nonce_endpoint that returns the nonce, rather than re-inventing something essentially identical to DPoP?

This would benefit any DPoP only implementation in addition to this one.

FWIW we did feel the pain of not knowing the DPoP nonce in advance and still think this mechanism is worth pursuing.

[c2bo]

That is the main motivation for the nonce/challenge fetching mechanism.

Compared to private_key_jwt, we have the problem that that mechanism is usually used for confidential clients. The mechanism of attestation based client authentication aims towards client that would be traditionally viewed as public clients, where the attestation contains additional information useful to the server to establish some level of trust into that client. We should imho not use private_key_jwt for such a scenario -> it makes sense to have a dedicated mechanism imho.

Regarding the nonce issue when using DPoP: For OpenID4VCI, we added the possibility to retrieve a DPoP nonce via a nonce endpoint (in addition to the challenge/nonce that the endpoint is usually used for): https://openid.github.io/OpenID4VCI/openid-4-verifiable-credential-issuance-wg-draft.html#section-7.2 Would such a mode also work for you?

[matthieusieben]

Even though our solutions are somewhat different, it seems that our motivations are very much aligned!

The reason we want an "attestation" protocol is also because we have "public" clients (native & single page web applications) to which we want to grant an elevated level of trust, without requiring them to implement a complex backend (BFF / TMB).

For context, the use case of ATProto is a little particular in the sense that it is essentially supporting a decentralized form of OAuth (clients and authorization providers have no pre-established relationships). This works thanks to @aaronpk's OAuth Client ID Metadata Document. That flavor of OAuth supports both "public" and "confidential" clients. Because of the distributed & dynamic nature of the protocol, private_key_jwt is the authentication mechanism that makes most sense. Similarly, the ATProto spec tried to adopt the most secure recommendations from the various OAuth related BCP (such as the use of DPoP).

We are trying to keep our spec as simple as can be (e.g. we don't want to introduce another PoP mechanism), while also trying to stay as compliant as possible with existing RFCs. So we would love to be able to get behind this draft. But in its current form, that seems hard to achieve.

A possible option would be to make this draft less specific, and leave more options to the implementer:

• The proof of possession mechanism to use could be left out entirely (DPoP being referenced as one of the viable option). This draft would only specify that some form of PoP mechanism MUST be used. The PoP mechanism described in this draft could become its own, seperate, draft.

• It's understandable that it might be desirable to keep the method to convey the attestation distinct from the client authentication mechanism. An example of reason for that is that there already exists assumptions around "application_type": "native" being "public" (like in this section of RFC 8252). That being said, an attestation is a form of authentication, and it feels, again, that when private_key_jwt is used, any other mechanism would feel quite redundant with it (unnecessarily increasing the complexity). Here too, it'd be nice if this draft could leave some leeway to implementations. In particular, it'd be nice if private_key_jwt was one of the available ways to convey the PoP key's thumbprint. Alternatively, since it seems that both our motivations for client attestation are to provide better support for "public" apps, this draft could introduce a dedicated client property for this case (or maybe a new value for application_type), as a way to decrease the trust level that an AS would otherwise grant to a client authenticated though private_key_jwt.

The nonce retrieval method defined in https://openid.github.io/OpenID4VCI/openid-4-verifiable-credential-issuance-wg-draft.html#section-7.2 would indeed work for us, though we would not be able to adopt that full spec. Too bad there isn't an RFC just for the retrieval of nonces (that I know of).

[c2bo]

The nonce retrieval method defined in https://openid.github.io/OpenID4VCI/openid-4-verifiable-credential-issuance-wg-draft.html#section-7.2 would indeed work for us, though we would not be able to adopt that full spec. Too bad there isn't an RFC just for the retrieval of nonces (that I know of).

There was https://datatracker.ietf.org/doc/draft-demarco-nonce-endpoint/ proposed a year ago and people didn't like that since it was too generic if I recall correctly. That is part of the reason why we tried to scope the whole mechanism within this draft clearly around the intended use-case.

[paulbastian]

I agree with @c2bo , extending private_key_jwt spec like this looks quite far-stretched and maybe dangerous, as this becomes basically a fundamental new client authentication mechanism, it deserves it's own identifier, as it wouldn't be possible to distinguish them otherwise in the metadata. We have been thinking about how to optionally leverage DPoP for this spec, see #69
In general, I think it makes sense to discuss on a call?

[paulbastian]

bump @matthieusieben @devinivy are you still interested in discussing this?