Improve CDDL and fix examples

[rohanmahy]

First commit fixes the example (missing commas, wrong keys).
Subsequent commits will make changes to CDDL.

[OR13]

This belongs in the key binding token... we want the confirmation method to be bound to the exact claims (via hash) that the holder disclosed.

[rohanmahy]

both the sd_claims and the salted values are in an sd-cwt-issued (sent from Issuer to Holder). In order for the holder to validate the sd_claims completely, they need to be hashed and the Holder needs to know the hash function and the hash of the whole sd_claims array (which are in the unprotected).

I guess the sd-kbt needs sd-hash as well to be a hash of whichever sd_claims are disclosed in that particular parent sd-cwt-presentation.

[rohanmahy]

maybe we need 2 parameters:
issued_claims_hash in the sd-cwt and presented_claims_hash in the sd-kbt?

[OR13]

In order for the holder to validate the sd_claims completely, they need to be hashed and the Holder needs to know the hash function and the hash of the whole sd_claims array (which are in the unprotected).

I see why you are saying the issuer needs to include the sd_hash here... You want the holder to be assured they know all claims.

This can be accomplished by including the "all claims disclosed hash" in the issuer payload, un redacted... and then they holder acts as a verifier for the included disclosures from the issuer, and confirms they are correct before attempting redaction.

The holder can also process the issuer payload, and if they encounter any redactions which are not satisfied by the issuer disclosed claims, they can error.

The latter is how I have been solving this problem to date.

[rohanmahy]

I'm not sure what you are suggesting. if the all claims unredacted array is in the unprotected header we still need a hash of it in the payload so it is covered by the issuer signature. if all claims is in the payload, we can't removed the unredacted claims without breaking the issuer signature when presenting it. if I am wrong here, maybe a concrete example would help me get it. thanks, -rohan

…

On Wed, Jul 10, 2024, 15:15 Orie Steele ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In editor_drafts/draft-prorock-spice-cose-sd-cwt.md <#9 (comment)>: > + * key => any +} + +sd-payload = { + ; standard claims + &(iss: 1) ^ => tstr, ; "https://issuer.example" + &(sub: 2) ^ => tstr, ; "https://device.example" + &(aud: 3) ^ => tstr, ; "https://verifier.example" + ? &(exp: 4) ^ => int, ; 1883000000 + ? &(nbf: 5) ^ => int, ; 1683000000 + &(iat: 6) ^ => int, ; 1683000000 + &(cnf: 8) ^ => { * key => any }, ; key confirmation + ? &(cnonce: 39) ^ => bstr, + ; + ; sd-cwt new claims + &(sd_hash: TBD3) ^ => bstr, In order for the holder to validate the sd_claims completely, they need to be hashed and the Holder needs to know the hash function and the hash of the whole sd_claims array (which are in the unprotected). I see why you are saying the issuer needs to include the sd_hash here... You want the holder to be assured they know all claims. This can be accomplished by including the "all claims disclosed hash" in the issuer payload, un redacted... and then they holder acts as a verifier for the included disclosures from the issuer, and confirms they are correct before attempting redaction. The holder can also process the issuer payload, and if they encounter any redactions which are not satisfied by the issuer disclosed claims, they can error. The latter is how I have been solving this problem to date. — Reply to this email directly, view it on GitHub <#9 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADSQPTLHLI4JOKXRGDG6STZLUXW3AVCNFSM6AAAAABJITZ2QGVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDCNRZGA3DCMZQG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[OR13]

The issuer signs all redacted claims in the payload, and the disclosed salted claims for each in the unprotected header.

There are a few cases, but let's look at a complex one as an example:

3 nested redacted claims.

The holder gets the credential from the issuer, and they are only able to disclose the first 2 layers... They know the issuer left off the last disclosure.

If the holder can disclose all 3, and there are no remaining disclosures, the holder has all the disclosures and knows where they go in the payload, and the issuer does not need to include a separate hash of all disclosures in the payload.

When the holder presents to a verifier, the key binding token needs to be associated to a specific set of disclosure.

The holder filters the disclosures array, encodes the full array as a bstr, hashes the bstr and uses their confirmation key to sign the kbt.

The verifier, checks the issuer signature.
Checks the key binding token signature.
Checks the kbt claims digest and ensures that it matches the digest of disclosed claims in the unprotected header.

And then the verifier processes each disclosed claim updating the payload until there are no more redactions to substitute.

At this point, if there are unprocessed disclosures that's an error.

If there are redactions for which there is no disclosure they are omitted.

Assume the issuer signed a hash of all disclosures.

The holder doesn't need this information, because they can confirm if the issuer has not revealed all disclosures without it.

A verifier cannot use it, because a common case for the verifier is that they receive a subset of disclosed claims.

This is why the hash of disclosed claims is in the kbt which is signed by the holder, instead of the issuer signed token.

This process is the same in sd-jwt, and possibly explained better than me in a GitHub comment written from my phone :)

[OR13]

this is the JWT version not the CWT version of this

[OR13]

technically this should be some "tag": bstr