Rephrase conditions to provide `nonce` in proof types based on presence of Nonce endpoint

[awoie]

Potentially fixes #677 , potentially fixes #676

Note that I created the PR based on https://github.com/openid/OpenID4VCI/issues/676#issuecomment-3501443791.

IMO, one implication is that for nonce claims in a key_attestation in a jwt proof, it means, the wallet decides whether to include it which is how I interpret the current version of the spec but wanted to point this out in case it is not obvious for readers of this PR. If the issuer insists on the presence which is unlikely, it could still provide a nonce error. To improve this behaviour, we could define a dedicated issuer metadata parameter, e.g., require_nonce_in_key_attesatation_in_jwt_proof in a backward compatible way to improve this behaviour.

[babisRoutis]

Hi @awoie

Please consider updating the definition of nonce claim of key_attestation found in appendix E.

Currently the definition is

nonce: OPTIONAL. String that represents a nonce provided by the Issuer to prove that a key attestation was freshly generated

IMO this could be update to include

MUST be present if the attestation is used with attestation Proof type, if credential issuer provides a nonce endpoint

[c2bo]

Hi @awoie

Please consider updating the definition of nonce claim of key_attestation found in appendix E.

Currently the definition is

nonce: OPTIONAL. String that represents a nonce provided by the Issuer to prove that a key attestation was freshly generated

IMO this could be update to include

MUST be present if the attestation is used with attestation Proof type, if credential issuer provides a nonce endpoint

I was wondering about the same point - we should be clear where exactly nonce is required and where not. In the case of proof type attestation we still want to mandate its presence, right?

[babisRoutis]

I was wondering about the same point - we should be clear where exactly nonce is required and where not. In the case of proof type attestation we still want to mandate its presence, right?

@c2bo

My truth table ( :smile: ) for nonce in the key_attestation:

key_attestation carrier	Nonce endpoint present	Nonce endpoint absent
Proof of type jwt	Optional (Wallet's decision). If present should be from nonce_endpoint	Must not be present
Proof of type attestation	Mandatory	Must not be present

[awoie]

Hi @awoie Please consider updating the definition of nonce claim of key_attestation found in appendix E. Currently the definition is

nonce: OPTIONAL. String that represents a nonce provided by the Issuer to prove that a key attestation was freshly generated

IMO this could be update to include

MUST be present if the attestation is used with attestation Proof type, if credential issuer provides a nonce endpoint

I was wondering about the same point - we should be clear where exactly nonce is required and where not. In the case of proof type attestation we still want to mandate its presence, right?

For the attestation proof type we have this:

If the Credential Issuer has a Nonce Endpoint (as defined in Section 8), the c_nonce value provided by the Credential Issuer MUST be provided in the key attestation's nonce parameter.

[awoie]

Hi @awoie Please consider updating the definition of nonce claim of key_attestation found in appendix E. Currently the definition is

nonce: OPTIONAL. String that represents a nonce provided by the Issuer to prove that a key attestation was freshly generated

IMO this could be update to include

MUST be present if the attestation is used with attestation Proof type, if credential issuer provides a nonce endpoint

I was wondering about the same point - we should be clear where exactly nonce is required and where not. In the case of proof type attestation we still want to mandate its presence, right?

For the attestation proof type we have this:

If the Credential Issuer has a Nonce Endpoint (as defined in Section 8), the c_nonce value provided by the Credential Issuer MUST be provided in the key attestation's nonce parameter.

But yes, I agree with @babisRoutis.

I will clean up the language again to clarify all of this since I agree it is language that can be misinterpreted.

[awoie]

@jogu I applied the change to 1.0. Let me know if there is anything else needed wrt change log. Also added some language on pre-generated attestations and how a wallet could detect whether an issuer requires a nonce in the key attestation based on the current specification, e.g., invalid_nonce error.