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

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!

@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.

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?

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.

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)