Improve CDDL and fix examples

[rohanmahy]

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

[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 https://github.com/mesur-io/ietf-misc/pull/9#discussion_r1672249168:

• • 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 https://github.com/mesur-io/ietf-misc/pull/9#discussion_r1672249168, 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 :)