Cleanup language around c_nonce #525
Conversation
We still had text that assumed the c_nonce was proactively sent to the wallet, rather than (as is now the case) fetched by the wallet. Also clarify that the nonce is a challenge rather than a nonce (without changing any parameter names!), and that 'unpredictable' does not mean that the same value cannot be used for a short time. Some of the language is quite similar to the language in DPoP around the DPoP nonces, as there is a lot of similarity - both mechanisms do not (fully) prevent replay but do ensure freshness. relates to some of the points raised in #461 relates the confusion that prompted #496 adds some clarify around the 'what nonces are' part of #491
Sakurann
requested review from
danielfett,
tlodderstedt,
GarethCOliver,
c2bo,
tplooker,
paulbastian,
awoie,
bc-pi and
Sakurann
| @@ -1053,7 +1053,7 @@ Below is a non-normative example of a `proofs` parameter: | |||
|
|
|||
| A key attestation in JWT format as defined in (#keyattestation-jwt). | |||
|
|
|||
| When a key attestation is used as a proof type, it MUST contain the `c_nonce` value provided by the Credential Issuer in its `nonce` parameter. | |||
| If the Credential Issuer has a Nonce Endpoint (as defined in (#nonce-endpoint)), the `c_nonce` value provided by the Credential Issuer MUST be provided in the key attestation's `nonce` parameter. | |||
There was a problem hiding this comment.
This is a normative change. Should we mandate nonce endpoint in this case?
There was a problem hiding this comment.
I probably should have called this out. It was previously left very unsaid what to do if there was no nonce endpoint, my thinking was if you can't get a nonce the logical conclusion is the issuer accepts attestations without nonces. I'm not sure there's a reason we'd require nonce in this case when we allow proofs without nonces?
There was a problem hiding this comment.
I agree its better to be consistent here unless there is compelling reason not to be.
There was a problem hiding this comment.
We don't have any freshness guarantee with this change. Yet again, it's also optional for jwt proof type. So I think I'm okay with this.
cc @c2bo
| @@ -820,11 +820,11 @@ See (#identifying_credential) for the summary of the options how requested Crede | |||
|
|
|||
| The proof type contained in the `proofs` parameter is an extension point that enables the use of different types of proofs for different cryptographic schemes. | |||
|
|
|||
| The proof(s) in the `proofs` parameter MUST incorporate the Credential Issuer Identifier (audience), and optionally a `c_nonce` value generated by the Credential Issuer to allow the Credential Issuer to detect replay. The way that data is incorporated depends on the key proof type. In a JWT, for example, the `c_nonce` value is conveyed in the `nonce` claim, whereas the audience is conveyed in the `aud` claim. In a Linked Data proof, for example, the `c_nonce` is included as the `challenge` element in the key proof object and the Credential Issuer (the intended audience) is included as the `domain` element. | |||
| The proof(s) in the `proofs` parameter MUST incorporate the Credential Issuer Identifier (audience), and optionally a `c_nonce` value generated by the Credential Issuer to allow the Credential Issuer to detect freshness. The way that data is incorporated depends on the key proof type. In a JWT, for example, the `c_nonce` value is conveyed in the `nonce` claim, whereas the audience is conveyed in the `aud` claim. In a Linked Data proof, for example, the `c_nonce` is included as the `challenge` element in the key proof object and the Credential Issuer (the intended audience) is included as the `domain` element. | |||
There was a problem hiding this comment.
| The proof(s) in the `proofs` parameter MUST incorporate the Credential Issuer Identifier (audience), and optionally a `c_nonce` value generated by the Credential Issuer to allow the Credential Issuer to detect freshness. The way that data is incorporated depends on the key proof type. In a JWT, for example, the `c_nonce` value is conveyed in the `nonce` claim, whereas the audience is conveyed in the `aud` claim. In a Linked Data proof, for example, the `c_nonce` is included as the `challenge` element in the key proof object and the Credential Issuer (the intended audience) is included as the `domain` element. |
I suggest we just remove this paragraph entirely as each concrete proof type already defines this explicitly and this prevents a situation in future where a new proof type is defined that perhaps couldn't satisfy these constraints (albeit unlikely).
There was a problem hiding this comment.
I also wondered about that whilst I was editing the paragraph, but in the end I think it's setting criteria for people that want to define new proof types, and "incorporating" (which doesn't necessarily mean "has a field that contains exactly") both the audience and potentially a freshness seem fairly straightforward and sensible requirements. Not a hill I'm going to die on though :)
We still had text that assumed the c_nonce was proactively sent to the wallet, rather than (as is now the case) fetched by the wallet.
Also clarify that the nonce is a challenge rather than a nonce (without changing any parameter names!), and that 'unpredictable' does not mean that the same value cannot be used for a short time.
Some of the language is quite similar to the language in DPoP around the DPoP nonces, as there is a lot of similarity - both mechanisms do not (fully) prevent replay but do ensure freshness.
relates to some of the points raised in #461
relates the confusion that prompted #496
adds some clarify around the 'what nonces are' part of #491