Using a server provided nonce to limit the lifetime of a Client Attestation PoP JWT

[pmhsfelix]

Following up on the conversations some of us had after IIW (see openid/OpenID4VCI#71 (comment)), this issue proposes the addition of a server provided nonce mechanism to limit the lifetime of a Client Attestation PoP JWT, similar to the DPoP nonce mechanism.

This relates to openid/OpenID4VCI#71, however the required changes need to be addressed on the attestation spec and not on the VCI spec.

I'm currently working on a PR to add this.

[tplooker]

Please see #67 for a proposal to use DPoP which would provide an alternative solution to this proposal.

[paulbastian]

Thoughts from today's editor call:

Proposal 1: DPoP style

Advantages:

• established mechanism
• high flexiblity for AS to manages nonce lifetime

Disadvantage:

• higher chance of failure and repeated DPoP proof signatures, costly with remote or hardware key
  • no nonce expiration communicated to client
• is there a defined way for a client to request a valid nonce from AS? How can he be sure to end up in the use_dpop_nonce and not in other error conditions? -> clarify with @danielfett @bc-pi

Proposal 2: new/extended mechanism

extend DPoP with:

• define a HTTP Header to explicitly request a new nonce
• add expiration to the nonce delivery (AS may still send a new nonce, even if the time has not passed yet)

Advantages:

• ability to request fresh nonces when needed
  • Wallet doesn't need to store old/fake DPoP Proofs to fetch a new one
  • avoid double DPoP proof, costly with remote or hardware key
• nonces could be delivered as header within other messages

Disadvantage:

• unauthenticated endpoint to request nonce that may generate state on the AS/may be leveraged for DDoS
• unclear how to extend DPoP / more work

---

Do we want the Wallet to cache the nonces at all? Doesn't this open tracking by the issuer? This makes it even more obvious that we need explicit nonce requests!

[tlodderstedt]

@paulbastian How do you envision the client to determine whether a nonce is needed? I'm asking since if the client would know this in advance, it would allow a design where the client could obtain the nonce from a dedicated endpoint before calculating the PoP and sending the token request.

[c2bo]

One idea was to add certain datapoints to the (previous) response - things like expiration time that could be a used as an indicator for the client that a nonce is not valid anymore (but not a guarantee that it will be accepted by the server).
I guess we could also signal the general nonce policies for endpoints somewhere in the metadata?

[tlodderstedt]

My question is related to a client that just received an authorization code and now wants to authentication using a client attestation. How is the client supposed to figure our whether a nonce is needed?

I see the following options:

1. on demand, because the token request with a PoP w/o nonce is rejected
2. some AS metadata tell the client a nonce is needed
3. client and AS belong to a certain domain (e.g. the client is a wallet and the AS represents a credential issuer in the EUDI Wallet space) and nonces are always required in this domain.

[c2bo]

I think there are 2 kinds of information we should consider:
1: Something about the general policy of requiring a nonce (with the 3 options you mentioned)
2: Some form of indicators if a client can re-use an existing nonce or should directly request a new nonce (and avoid an unnecessary signature)