Is c_nonce required in proof or not?

[awoie]

Nonces in proof types are OPTIONAL but the following sentence confused me:

The proof element MUST incorporate the Credential Issuer Identifier (audience), and a c_nonce value generated by the Authorization Server or the Credential Issuer to allow the Credential Issuer to detect replay.

It says MUST ..., and a c_nonce. Does that MUST refer to c_nonce as well? Isn't this conflicting with the optionality of nonces in proofs? If it is not conflicting then it is at least confusing.

[awoie]

Assuming it is NOT required, I'd propose changing the text to:

The proof element MUST incorporate the Credential Issuer Identifier (audience), and if provided a c_nonce value generated by the Authorization Server or the Credential Issuer to allow the Credential Issuer to detect replay.

[awoie]

This text makes it probably more clear:

The proof element MUST incorporate the Credential Issuer Identifier (audience), and a nonce value if a c_nonce value was provided by the Authorization Server or the Credential Issuer to allow the Credential Issuer to detect replay.

[Sakurann]

I think c_nonce is currently meant to be mandatory (either from a token endpoint or from credential endpoint in the error response)...
but I know an implementer for whom adding c_nonce was a hurdle to implement VCI, so they implemented at_hash in the proof instead to prevent replay and achieve the same result.

[awoie]

I think c_nonce is currently meant to be mandatory (either from a token endpoint or from credential endpoint in the error response)... but I know an implementer for whom adding c_nonce was a hurdle to implement VCI, so they implemented at_hash in the proof instead to prevent replay and achieve the same result.

Okay but why is nonce OPTIONAL in the proof in that case if it was meant to be mandatory? Does it mean that this particular implementer used at_hash for nonce in the jwt PoP?

[awoie]

For reference, from the spec:

nonce: OPTIONAL (string). The value type of this claim MUST be a string, where the value is a server-provided c_nonce. It MUST be present when the Wallet received a server-provided c_nonce.

[awoie]

For reference, from the spec:

nonce: OPTIONAL (string). The value type of this claim MUST be a string, where the value is a server-provided c_nonce. It MUST be present when the Wallet received a server-provided c_nonce.

This suggests that under some circumstances the intention was to allow JWT proofs without a nonce.

[Sakurann]

because c_nonce can be returned either from the token endpoint or credential error response. and when it is received from credential error response, the first proof sent from the wallet cannot have a nonce parameter because the wallet is yet to receive it in the error..

[awoie]

because c_nonce can be returned either from the token endpoint or credential error response. and when it is received from credential error response, the first proof sent from the wallet cannot have a nonce parameter because the wallet is yet to receive it in the error..

Why would somebody create an "always" invalid proof (i.e. without a nonce) in that case? That sounds strange to me. Wouldn't it make more sense to send no proof (it is optional anyways) in this case?

[awoie]

because c_nonce can be returned either from the token endpoint or credential error response. and when it is received from credential error response, the first proof sent from the wallet cannot have a nonce parameter because the wallet is yet to receive it in the error..

Why would somebody create an "always" invalid proof (i.e. without a nonce) in that case? That sounds strange to me. Wouldn't it make more sense to send no proof (it is optional anyways) in this case?

And in that case, why make nonce OPTIONAL if it is required anyways to get a valid credential?

If nonce is really always required, then I would rather remove optionality by making nonce etc. mandatory and send no proof at all to get a fresh nonce from the issuer.

[bc-pi]

I hereby concur with @awoie that the current treatment of c_nonce into the nonce/challenge/Claim Key 10 (Nonce) of the proof(s) of the Credential Request is, if not conflicting, then at least confusing. I'd actually been meaning to raise an issue about it myself but hadn't yet managed to summon the time or energy to do so.

It has been stated elsewhere (slack, signal, email, etc., I can't keep track) that this the same mechanism as DPoP. But as currently written in VCI, it is definitely not the same.

[Sakurann]

WG discussion/proposal on the table:

• make c_nonce optional (credential ). credential endpoint has an option to respond with an c_nonce if it wants to require it (DPoP behavior)
• ath (access token hash) mandatory (?) in the proof - does not prevent replay if access token is long-lived, might be an incentive for issuer to do c_nonce (issue VC Issuance is vulnerable to Unknown Key Share attacks #19)
• (potentially, also no c_nonce from the token endpoint (Remove c_nonce from the token response #39), but decided to deal with it in the separate issue)
• (proof does not have jti, so that cannot be used to detect proofs encountered before..)

[peppelinux]

(potentially, also no c_nonce from the token endpoint (#39), but decided to deal with it in the separate issue)

I support this. The RS is technically able to evaluate if the AT was previously used. The Credential Endpoint can issue the c_nonce within the credential response. c_nonce is optional, because it is optional that the Credential Endpoint issues more than a credential using the same AT.

Removing c_nonce in the token endpoint response eliminates the need to modify legacy AS implementations while maintaining security against replay attacks and preventing the reuse of the AT at the RS (Credential Endpoint).

[awoie]

I'm still in favor of allowing the credential issuer to decide whether or not to accept proofs without a c_nonce value. But this is a separate discussion.

In any case, this language has to be adapted since it confuses wallet implementers:

The proof element MUST incorporate the Credential Issuer Identifier (audience), and a c_nonce value generated by the Authorization Server or the Credential Issuer to allow the Credential Issuer to detect replay.

Independent of whether or not c_nonce is required, the language above has to be adapted to something something like this:

The proof element MUST incorporate the Credential Issuer Identifier (audience) and if provided a c_nonce value generated by the Authorization Server or the Credential Issuer to allow the Credential Issuer to detect replay.

This would allow for:

1. wallet hasn't received a c_nonce but has an access_token, then the wallet can create a valid in terms of spec-compliant credential request without a c_nonce.
2. wallet has received a c_nonce from the token endpoint, then the wallet can create a valid in terms of spec-compliant credential request with a c_nonce value.

Otherwise, wallets cannot conform to the spec since they would not know where to get the c_nonce from if they haven't received one from the token endpoint and stop processing since the spec requires a c_nonce based on the original language. All language that relates to issuer sending invalid_proof plus c_nonce is issuer-related, not wallet-related. The wallet just reacts to invalid_proof error responses that may or may not include a c_nonce.