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 #676 (comment).

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.

[paulbastian]

I can't judge for DI, but the fix on jwt proof_type looks right

[jogu]

We still have the part here to solve: #676 (comment) (or we should raise a new issue for that, I don't have a strong opinion which).

I think we should apply the change to 1.0 as well.

[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 ( 😄 ) 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.

[awoie]

Applied @GarethCOliver suggestion. Please review again.

As a general thought, we might use the opportunity to clean up the language a bit more and also include a table such as the one that @babisRoutis provided to make things more explicit.

[awoie]

We need more reviews for this PR @jogu @Sakurann

[andprian]

@awoie the changes you made are in multiple places and describe how the wallet is expected to behave. I think we also need this kind on explanation in Clause 7. Nonce Endpoint. It would be useful for the Issuer's side to have the big picture here. If he provides a nonce endpoint, explain how this is expected to work, when it is mandatory to use this endpoint and when not.

[Sakurann]

discussed in the WG call:

• @andprian please open an issue and we can do another PR, but let's merge this PR first
• @c2bo @jogu @babisRoutis @GarethCOliver can you please re-review/approve?

[Sakurann]

@jogu put request for changes which i think have been addressed. please re-review:

We still have the part here to solve: #676 (comment) (or we should raise a new issue for that, I don't have a strong opinion which).

we now have the following text: "In some environments, a nonce is unnecessary because the key material in the key_attestation already provides sufficient entropy and freshness. Omitting the nonce also enables pre-generation of attestations prior to interacting with a specific Issuer. If the Issuer returns an invalid_nonce error, this can be interpreted as an indication that the Issuer expects a nonce claim in the key_attestation."

I think we should apply the change to 1.0 as well.

has been applied

[andprian]

Initially there was a suggestion to have a parameter require_nonce_in_key_attestation_in_jwt_proof and I believe that this is necessary to have, otherwise the wallet cannot know what the issuer expects without trial and error.

[andprian]

this can be interpreted as an indication -> can it be interpreted in another way as well?

[andprian]

Considering that the issuer can still enforce the presence of the nonce in the key_attestation, it is not actually true that including a nonce claim is left to the Wallet. Saying this is left to the wallet makes one believe that the request will succeed in both cases.

[brentzundel]

@jogu can you re-review?