Wallet Attestations and Nonces

[tlodderstedt]

Currently, implementations can protect the PoP for wallet attestations (https://datatracker.ietf.org/doc/draft-looker-oauth-attestation-based-client-auth) by:

• making it short lived
• making it one time use
• binding it to a protocol artifact like the authorization code (as kind of a nonce)

The latter does not work for Pushed Authorization Requests. The proposal was made, to let the wallet request a nonce from the Issuer that can then be used for binding the wallet attestation. This came up in various discussions including the eIDAS expert group's touch point meeting on OID4VCI and discussions with member states.

The basic idea would be to define another endpoint, e.g. nonce endpoint, the wallet could be use to obtain that nonce.

[peppelinux]

@alenhorvat "wallet proof of reliability (I'm genuine)" for sure, then holder key binding (cnf.jwk), then it could carry wallet metadata, as shown here

https://italia.github.io/eudi-wallet-it-docs/versione-corrente/en/wallet-instance-attestation.html#format-of-the-wallet-instance-attestation

[paulbastian]

So after discussing with @peppelinux , Giada and Amir on Friday, we agreed that:

• we prefer doing the wallet attestation already at the PAR endpoint, as we want to protect the phase of user authentication, as privacy and security related data might flow therein
• we send the client attestation+pop both to PAR endpoint and token endpoint, as these might also be different entities

Question remained whether to use the Dpop-style error providing the nonce at PAR endpoint or dedicated nonce endpoint. @peppelinux suggested that the nonce endpoint may be reused for OpenID4VP, although I don't see too much trouble getting a nonce there, as the Verifier always initiates the communication.

Is it possible to provide the information that a nonce request must be made in the Issuer's metadata? In that way the wallet knows upfront that it should request a nonce first from PAR endpoint?

[peppelinux]

Yes @paulbastian, we agreed!

WIA at the PAR endpoint, indeed. And I confirm that there is some excitement in the idea of ​​using oauth-attestation-based-client-auth on both PAR and Token endpoints, because these are RESTful endpoints where the same kind protection is used, reducing the overall complexity of both implementation and technical specs. Regarding to this point we would like to work on these:

• https://github.com/vcstuff/draft-ietf-oauth-attestation-based-client-auth/issues/45 (to have a better semantic that extends RFC7521 with a specialized parameter for the assertion pop)
• https://github.com/vcstuff/draft-ietf-oauth-attestation-based-client-auth/issues/46 (for having the same authz during the presentation phase)

We also agreed for implementing the nonce, and as you mentioned we may consider a brand new endpoint where a WIA+PoP is submitted for the return of a nonce. This would be reusable in both issuance and presentation and it also satisfy the requirement (even if not widely shared) of the wallet capabilities discovery before any protocol specific flow.

Is it possible to provide the information that a nonce request must be made in the Issuer's metadata? In that way the wallet knows upfront that it should request a nonce first from PAR endpoint?

The answer I would like to give is yes we must, then a nonce_endpoint metadata claim would be then required for any kind of jwt-issuer that issues nonces. It also requires a nonce_endpoint_auth_methods_supported with ["attestation_based_client_auth"] as our default approach for the wallet ecosystem

[bc-pi]

[quote replying to one of @danielfett's earlier comments]

Also, there is no need for a new nonce endpoint to issue nonces; DPoP issues nonces in headers in error messages.

It's worth mentioning that the DPoP-Nonce response header can also appear in normal non-error responses, which can be a more efficient way of supplying a new nonce value in cases involving multiple requests/responses - https://www.rfc-editor.org/rfc/rfc9449.html#section-8.2-3

I wonder if the whole approach should not be structured more like DPoP, defining headers that can be used in requests of many types. Or even a DPoP extension, reusing the DPoP nonces and/or the DPoP PoP.

As best I can remember, some early conceptual designs/ideas for draft-ietf-oauth-attestation-based-client-auth used the DPoP Proof rather than the Client Attestation PoP JWT. The thinking, as I recall mostly from @tplooker, was to not have to reinvent or redefine a PoP mechanism in draft-ietf-oauth-attestation-based-client-auth - the experience developing DPoP did show that it was more tricky than was expected. Is it really worthwhile to have draft-ietf-oauth-attestation-based-client-auth go though the same?

Perhaps that idea should be revisited? i.e. consider using the DPoP Proof header in draft-ietf-oauth-attestation-based-client-auth rather than the Client Attestation PoP JWT (as it is currently in -00). [I'm not trying to imply that DPoP did everything the right way at all but that many of the same issues were discussed during its development and addressed in some way]

Even if not taken that far, I do think I prefer issuing nonces inline with the protocol messages (error or normal) over a dedicated endpoint for nonce getting.

[bc-pi]

Maybe this is obvious to everyone but note that there are these two seemingly very much related issues in the repo for draft-ietf-oauth-attestation-based-client-auth and a resolution to this issue seems like it'll require changes to that piece rather than, or maybe in addition to, OpenID4VC.

https://github.com/vcstuff/draft-ietf-oauth-attestation-based-client-auth/issues/39 https://github.com/vcstuff/draft-ietf-oauth-attestation-based-client-auth/issues/9

[peppelinux]

I agree that technically the DPoP-Nonce is a concrete solution to provide the nonce in aswer to a request that has not previously carried it properly.

However there might be some reactions against this solution due to the fact that in this way we're designing a flow that must handle an error-by-design approach, where the client must send a PAR without a nonce to obtain an error with the nonce to use for the next, equivalent, PAR request. From the development experience this might result frustrating in implementation and patchy in the overall design of the solution.

did I get it wrong or is it this the direction that we may have?

If yes I'm wondering if the nonce endpoint would make sense (as an endpoint protected by WIA~PoP) to give a good division by feature of specialized endpoints, where, if missing the DPoP-Nonce could be provisioned as well with the PAR response, as fallback/backup/hinting approach, but not a the default provisioning method of the nonce.

WDYT?

[sietseringers]

To me it would be much nicer to add a separate HTTP endpoint for requesting the nonce, for the reasons you've indicated (the other approach is error-by-design which is not pretty or developer friendly).

If the issuer requires that the wallet uses a nonce while the wallet tries to use jti (so it does not invoke that specialized endpoint), we can just keep the current idea of including a nonce in the HTTP error response.

[tlodderstedt]

@Sakurann @pmhsfelix @c2bo @jogu @decentralgabe and Markus had a discussion about this topic after IIW. We came to the conclusion the AS provding the nonce in a error response is the better option, as

• the AS has full control if and when an AS provided nonce is needed,
• adding an endpoint is additional complexity, and
• it aligns with the way DPoP works.

We think the client initially should send a attestation PoP with a jti (as specified in draft-ietf-oauth-attestation-based-client-auth).

We suggest to add that feature to draft-ietf-oauth-attestation-based-client-auth as it is related to replay detection for this kind of attestations.

[paulbastian]

If the discussion in OpenID4VP Advanced Flow leads us to not needing a nonce endpoint (which I think it will), I'm fine with DPoP-style nonce providing by the AS. We can define the mechanism in next iteration of Client Attestation

[pmhsfelix]

Related PR on https://github.com/vcstuff/draft-ietf-oauth-attestation-based-client-auth - https://github.com/vcstuff/draft-ietf-oauth-attestation-based-client-auth/pull/64

[peppelinux]

If the discussion in OpenID4VP Advanced Flow leads us to not needing a nonce endpoint (which I think it will), I'm fine with DPoP-style nonce providing by the AS. We can define the mechanism in next iteration of Client Attestation

With your same thought in my mind, see https://github.com/vcstuff/draft-ietf-oauth-attestation-based-client-auth/pull/64#issuecomment-1925504532