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
GarethCOliver,
Sakurann,
awoie,
bc-pi,
c2bo,
danielfett,
paulbastian,
tlodderstedt and
tplooker
| 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
| 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 :)
There was a problem hiding this comment.
Yeah I'm ok with the restructured language you have offered and therefore keeping the paragraph in now.
|
I don't have approver here, but looks like an improvement to me. |
|
3 approvals one this one (third one is here: #525 (comment) ), we've had input from at least 2 more people, and been discussed in a few WG calls and all comments have been resolved - merging. Feel free to open a new PR/issue if you can see further improvements we could make. |
7 participants
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