]> mesur.io

mprorock@mesur.io

Transmute

orie@transmute.industries

Fraunhofer SIT

Rheinstrasse 75 Darmstadt 64295 Germany henk.birkholz@ietf.contact

Rohan Mahy Consulting Services

rohan.ietf@gmail.com

Security Secure Patterns for Internet CrEdentials cose cwt selective disclosure This document describes a data minimization technique for use with CBOR Web Token (CWT). The approach is based on Selective Disclosure JSON Web Token (SD-JWT), with changes to align with CBOR Object Signing and Encryption (COSE). About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Secure Patterns for Internet CrEdentials Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction This document updates the CBOR Web Token (CWT) specification , enabling the holder of a CWT to disclose or redact special claims marked disclosable by the issuer of a CWT. The approach is modeled after SD-JWT , with changes to align with conventions from CBOR Object Signing and Encryption (COSE) . This specification enables Holders of CWT based credentials to prove the integrity and authenticity of selected attributes asserted by an Issuer about a Subject to a Verifier. Although techniques such as one time use and batch issuance can improve the confidentiality and security characteristics of CWT based credential protocols, CWTs remain traceable. Selective Disclosure CBOR Web Tokens (SD-CWTs) are CWTs and can be deployed in protocols that are already using CWTs, even if they contain no optional to disclose claims. Credential types are distinguished by their attributes, for example a license to operate a vehicle and a license to import a product will contain different attributes. The specification of credential types is out of scope for this document, and the examples used in this document are informative. SD-CWT operates on CWT Claims Sets as described in . CWT Claims Sets contain Claim Keys and Claim Values. SD-CWT enables Issuers to mark certain Claim Keys or Claim Values mandatory or optional for a holder of a CWT to disclose. A holder cannot send redacted claim keys to a verifier who does not understand selective disclosure at all. However, Claim Keys and Claim Values which are not understood remain ignored as described in .

High level flow Figure 1: High level SD-CWT Issuance and Presentation Flow | Request Nonce | | Receive SD-CWT +-------------------------------->| | | | | |<--------------------------------+ | | Receive Nonce | | +---+ | | | | Redact Claims | | |<--+ | | | | | +---+ | | | | Demonstrate | | |<--+ Posession | | | | | | Present SD-CWT | | +-------------------------------->| | | | ]]> This diagram captures the essential details necessary to issue and present an SD-CWT. The parameters necessary to support these processes can be obtained using transports or protocols which are out of scope for this specification. However the following guidance is generally recommended, regardless of protocol or transport.

1. The issuer SHOULD confirm the holder controls all confirmation material before issuing credentials using the cnf claim.
2. To protect against replay attacks, the verifier SHOULD provide a nonce, and reject requests that do not include an acceptable an nonce (cnonce). This guidance can be ignored in cases where replay attacks are mitigated at another layer.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses terms from CWT , and COSE . The terms Claim Name, Claim Key and Claim Value are defined in . This document defines the following new terms:

Selective Disclosure CBOR Web Token (SD-CWT):

A CWT with claims enabling selective disclosure with key binding.

Selective Disclosure Key Binding Token (SD-CWT-KBT):

A CWT used to demonstrate possession of a confirmation method, associated to an SD-CWT.

Issuer:

An entity that produces a Selective Disclosure CBOR Web Token.

Holder:

An entity that presents a Selective Disclosure CBOR Web Token which includes a Selective Disclosure Key Binding Token.

Verifier:

An entity that validates a Partial or Full Disclosure by a holder.

Partial Disclosure:

When a subset of the original claims protected by the Issuer, are disclosed by the Holder.

Full Disclosure:

When the full set of claims protected by the Issuer, is disclosed by the Holder. An SD-CWT with no blinded claims (all claims are marked mandatory to disclose by the Issuer) is considered a Full Disclosure.

Salted Disclosed Claim:

A salted claim disclosed in the unprotected header of an SD-CWT.

Digested Salted Disclosed Claim / Blinded Claim Hash:

A hash digest of a Salted Disclosed Claim.

Blinded Claim:

Any Redacted Claim Key or Redacted Claim Element which has been replaced in the CWT payload by a Blinded Claim Hash.

Redacted Claim Key:

The hash of a claim redacted from a map data structure.

Redacted Claim Element:

The hash of an element redacted from an array data structure.

Presented Disclosed Claims Set:

The CBOR map containing zero or more Redacted Claim Keys or Redacted Claim Elements.

Validated Disclosed Claims Set:

The CBOR map containing all mandatory to disclose claims signed by the issuer, all selectively disclosed claims presented by the holder, and omitting all undisclosed instances of Redacted Claim Keys and Redacted Claim Element claims that are present in the original SD-CWT.

Overview of Selective Disclosure CWT

A CWT without Selective Disclosure Below is the payload of a standard CWT without selective disclosure. It consists of standard CWT claims, the holder confirmation key, and five specific custom claims. The payload is shown below in CBOR Extended Diagnostic Notation (EDN) . Note that some of the CWT claim map keys shown in the examples have been invented for this example and do not have registered integer keys. The custom claims deal with attributes of an inspection of the subject: the pass/fail result, the inspection location, the license number of the inspector, and a list of date when the subject was inspected.

Holder gets an SD-CWT from the Issuer Alice would like to selectively disclose some of these (custom) claims to different verifiers. Note that some of the claims may not be selectively disclosable. In our next example the pass/fail status of the inspection, the most recent inspection date, and the country of the inspection will be fixed claims (always present in the SD-CWT). After the Holder requests an SD-CWT from the issuer, the issuer generates an SD-CWT as follows: >, / unprotected / { / sd_claims / 17 : / these are all the disclosures / <<[ <<[ /salt/ h'8d5c15fa86265d8ff77a0e92720ca837', /claim/ 501, / inspector_license_number / /value/ "ABCD-123456" ]>>, <<[ /salt/ h'86c84b9c3614ba27073c7e5a475a2a13', /value/ 1549560720 / inspected 7-Feb-2019 / ]>>, <<[ /salt/ h'86c84b9c3614ba27073c7e5a475a2a13', /value/ 1612498440 / inspected 4-Feb-2021 / ]>>, <<[ /salt/ h'30eef86edeaa197df7bd3d17dd89cd87', /claim/ "region", /value/ "ca" /California/ ]>>, <<[ /salt/ h'284538c4a1881fac49b2edc550c1913e', /claim/ "postal_code", /value/ "94188" ]>> ]>> }, / payload / << { / iss / 1 : "https://issuer.example", / sub / 2 : "WRQ2RbY5RYJCIxfDQL9agl9fFSCYVu4Xocqb6zerc1M", / exp / 4 : 1725330600, /2024-09-02T19:30:00Z/ / nbf / 5 : 1725243840, /2024-09-01T19:25:00Z/ / iat / 6 : 1725244200, /2024-09-01T19:30:00Z/ / cnf / 8 : { / cose key / 1 : { / alg: ES256 / 3: -7, / kty: EC2 / 1: 2, / crv: P-256 / -1: 1, / x / -2: h'hVTrJ13Nb70cesZBqiyQ2SAi_Q0wJLWvGMfMYa1Sei0', / y / -3: h'TceuLGd-ltDMgll2Vc6S1VA_VCk9h4ddHnnOR3AZQ0M' } }, /most_recent_inspection_passed/ 500: true, / redacted_claim_keys / 59(0) : [ / redacted inspector_license_number / h'7e6e350907d0ba3aa7ae114f8da5b360' + h'601c0bb7995cd40049b98e4f58fb6ec0' ], /inspection_dates/ 502 : [ / redacted inspection date 7-Feb-2019 / 60(h'a0f74264a8c97655c958aff3687f1390' + h'ed0ab6f64cd78ba43c3fefee0de7b835') / redacted inspection date 4-Feb-2021 / 60(h'1e7275bcda9bc183079cd4515c5c0282' + h'a2a0e9105b660933e2e68f9a3f40974b') 1674004740, / 2023-01-17T17:19:00 / ], / inspection_location / 503 : { "country" : "us", / United States / / redacted_claim_keys / 59(0) : [ / redacted region / h'c47e3b047c1cd6d9d1e1e01514bc2ec9' + h'ed010ac9ae1c93403ec72572bb1e00e7', / redacted postal_code / h'0b616e522a05d8d134a834979710120d' + h'41ac1522b056d5f9509cf7e850047302' ] } } >>, / signature / h'3337af2e66959614' /TODO: fix / ]) ]]> Some of the claims are redacted in the payload. The corresponding disclosure is communicated in the unprotected header in the sd_claims key. For example, the inspector_license_number claim is a Salted Disclosed Claim, consisting of a per-disclosure random salt, the claim name, and claim value. > ]]> The SHA-256 hash (the hash algorithm identified in the sd_alg protected header field) of that bytes string is the Digested Salted Disclosed Claim (in hex). The digest value is included in the payload in a redacted_claim_keys field for a Redacted Claim Key (in this example), or in a named array for a Redacted Claim Element (ex: for a redacted claim element of inspection_dates).

Holder prepares an SD-CWT for a Verifier When the Holder wants to send an SD-CWT and disclose none, some, or all of the redacted values, it makes a list of the values to disclose and puts them in sd_claims in the unprotected header. For example, Alice decides to disclose to a verifier the inspector_license_number claim (ABCD-123456), the region claim (California), and the earliest date element in the inspection_dates array (7-Feb-2019). >, <<[ /salt/ h'86c84b9c3614ba27073c7e5a475a2a13', /value/ 1549560720 / inspected 7-Feb-2019 / ]>>, <<[ /salt/ h'30eef86edeaa197df7bd3d17dd89cd87', /claim/ "region", /value/ "ca" /California/ ]>> ]>> ]]> The Holder MAY fetch a nonce from the Verifier to prevent replay, or obtain a nonce acceptable to the verifier through a process similar to the method described in . Finally, the Holder generates a Selective Disclosure Key Binding Token (SD-KBT) that ties together the SD-CWT generated by the Issuer (with the disclosures the Holder chose for the Verifier in its unprotected header), the Verifier target audience and optional nonces, and proof of possession of the Holder's private key. The issued SD-CWT is placed in the kcwt (Confirmation Key CWT) protected header field (defined in ). >, / unprotected / {}, / payload / << { / cnonce / 39 : h'8c0f5f523b95bea44a9a48c649240803', / aud / 3 : "https://verifier.example/app", / iat / 6 : 1725283443, / 2024-09-02T06:24:03Z / } >>, / signature / h'1237af2e678945' / TODO: fix / ]) >> ]]> Together the digests in protected parts of the issued SD-CWT, and the disclosures hashed in unprotected header of the issuer_sd_cwt are used by the Verifier to confirm the disclosed claims. Since the unprotected header of the included SD-CWT is covered by the signature in the SW-KBT, the Verifier has assurance the Holder included the sent list of disclosures.

Update to the CBOR Web Token Specification The CBOR Web Token Specification (Section 1.1 of ), uses strings, negative integers, and unsigned integers as map keys. This specification relaxes that requirement, by also allowing CBOR tagged integers and text strings as map keys. Note that holders presenting to a verifier that does not support this specification would need to present a CWT without tagged map keys. Tagged keys are not registered in the CBOR Web Token Claims IANA registry. Instead the tag provides additional information about the tagged claim key and the corresponding (untagged) value. Multiple levels of tags in a key are not permitted.

SD-CWT definition SD-CWT is modeled after SD-JWT, with adjustments to align with conventions in CBOR and COSE. An SD-CWT MUST include the protected header parameter typ with the value "application/sd-cwt" in the SD-CWT. An SD-CWT is a CWT containing the "blinded claim hash" of at least one blinded claim in the CWT payload. Optionally the salted claim values (and often claim names) for the corresponding Blinded Claim Hash are actually disclosed in the sd_claims claim in the unprotected header of the CWT (the disclosures). Any party with a Salted Disclosed Claim can generate its hash, find that hash in the CWT payload, and unblind the content. However a Verifier with the hash cannot reconstruct the corresponding blinded claim without disclosure of the Salted Disclosed Claim.

Types of blinded claims Salted Disclosed Claims for named claims are structured as a 128-bit salt, the name of the redacted element, and the disclosed value. For Salted Disclosed Claims of items in an array, the name is omitted. When a blinded claim is a key in a map, its blinded claim hash is added to a redacted_claim_keys array claim in the CWT payload that is at the same level of hierarchy as the key being blinded. The redacted_claim_keys key is the integer 0 (which is reserved for top-level CWT claim keys), wrapped with a CBOR tag (requested tag number 59). When blinding an individual item in an array, the value of the item is replaced with the digested salted hash as a CBOR binary string, wrapped with a CBOR tag (requested tag number 60). Blinded claims can be nested. For example, both individual keys in the inspection_location claim, and the entire inspection_location element can be separately blinded. An example nested claim is shown in . Finally, an issuer may create "decoy digests" which look like a blinded claim hash but have only a salt. Decoy digests are discussed in .

SD-CWT Issuance How the Holder communicates to the Issuer to request a CWT or an SD-CWT is out-of-scope of this specification. Likewise, how the Holder determines which claims to blind or to always disclose is a policy matter which is not discussed in this specification. This specification defines the format of an SD-CWT communicated between an Issuer and a Holder in this section, and describes the format of a Key Binding Token containing that SD-CWT communicated between a Holder and a Verifier in . The protected header MUST contain the sd_alg field identifying the algorithm (from the COSE Algorithms registry) used to hash the Salted Disclosed Claims. The unprotected header MUST contain an sd_claims section with a Salted Disclosed Claim for every blinded claim hash present anywhere in the payload, and any decoys (see ). If there are no disclosures sd_claims is an empty array. The payload MUST also include a key confirmation element (cnf) for the Holder's public key.

Issuer generation The Issuer follows all the requirements of generating a valid CWT as updated by . The Issuer MUST implement COSE_Sign1 using an appropriate asymmetric signature algorithm / curve combination (for example ES256/P-256 or EdDSA/Ed25519) The Issuer MUST generate a unique cryptographically random salt with at least 128-bits of entropy for each Salted Disclosed Claim. If the client communicates a client-generated nonce (cnonce) when requesting the SD-CWT, the Issuer SHOULD include it in the payload.

Holder validation Upon receiving an SD-CWT from the Issuer with the Holder as the subject, the Holder verifies the following:

• the issuer (iss) and subject (sub) are correct;
• if an audience (aud) is present, it is acceptable;
• the CWT is valid according to the nbf and exp claims;
• a public key under the control of the Holder is present in the cnf claim;
• the hash algorithm in the sd_alg protected header is supported by the Holder;
• if a cnonce is present, it was provided by the Holder to this Issuer and is still "fresh";
• there are no unblinded claims about the subject which violate its privacy policies;
• every blinded claim hash (some of which may be nested as in ) has a corresponding Salted Disclosed Claim, and vice versa;
• all the Salted Disclosed Claims are correct in their unblinded context in the payload.

The following informative CDDL is provided to describe the syntax for an SD-CWT issuance. A complete CDDL schema is in . "application/sd+cwt", &(alg: 1) ^ => int, &(sd_alg: 18) ^= int, ; -16 for sha-256 * key => any } sd-unprotected = { ? &(sd_claims: 17) ^ => bstr .cbor salted-array, * key => any } sd-payload = { ; standard claims &(iss: 1) ^ => tstr, ; "https://issuer.example" ? &(sub: 2) ^ => tstr, ; "https://device.example" ? &(aud: 3) ^ => tstr, ; "https://verifier.example/app" ? &(exp: 4) ^ => int, ; 1883000000 ? &(nbf: 5) ^ => int, ; 1683000000 ? &(iat: 6) ^ => int, ; 1683000000 &(cnf: 8) ^ => { * key => any }, ; key confirmation ? &(cnonce: 39) ^ => bstr, ; ? &(redacted_keys: #6.59(0)) ^ => [ * bstr ], * key => any } ]]>

SD-CWT Presentation When a Holder presents an SD-CWT to a Verifier, it can disclose none, some, or all of its blinded claims. If the Holder wishes to disclose any claims, it includes that subset of its Salted Disclosed Claims in the sd_claims claim of the unprotected header. An SD-CWT presentation to a Verifier has the same syntax as an SD-CWT issued to a Holder, except the Holder choses the subset of disclosures included in the sd_claims claim. Since the unprotected header is not included in the signature, it will contain all the Salted Disclosed Claims when sent from the Issuer to the Holder. When sent from the Holder to the Verifier, the unprotected header will contain none, some, or all of these Claims. Finally, the SD-CWT used for presentation to a Verifier is included in a key binding token, as discsused in the next section.

Creating a Key Binding Token Regardless if it discloses any claims, the Holder sends the Verifier a unique Holder key binding (SD-KBT) for every presentation of an SD-CWT to a different Verifier. An SD-KBT is itself a type of CWT, signed using the private key corresponding to the key in the cnf claim in the presented SD-CWT. The SD-KBT contains the SD-CWT, including the Holder's choice of presented disclosures, in the kcwt protected header field in the SD-KBT. The sub and iss of an SD-KBT are implied from the cnf claim in the included SD-CWT. The aud claim MUST be included and relevant to the Verifier. The protected header of the SD-KBT MUST include the typ header parameter with the value application/sd-kbt. The SD-KBT provides the following assurances to the Verifier:

• the Holder of the SD-CWT controls the confirmation method chosen by the Issuer;
• the Holder's disclosures have not been tampered with since confirmation occurred;
• the Holder intended to address the SD-CWT to the Verifier specified in the audience (aud) claim;
• the Holder's disclosure is linked to the creation time (iat) of the key binding.

The SD-KBT prevents an attacker from copying and pasting disclosures, or from adding or removing disclosures without detection. Confirmation is established according to RFC 8747, using the cnf claim in the payload of the SD-CWT. The Holder signs the SD-KBT using the key specified in the cnf claim in the SD-CWT. This proves possession of the Holder's private key. "application/kb+cwt", &(alg: 1) ^ => int, &(kcwt: 13) ^ => bstr .cbor sd-cwt-issued, * key => any } kbt-unprotected = { * key => any } kbt-payload = { &(aud: 3) ^ => tstr, ; "https://verifier.example" ? &(exp: 4) ^ => int, ; 1883000000 ? &(nbf: 5) ^ => int, ; 1683000000 &(iat: 6) ^ => int, ; 1683000000 ? &(cnonce: 39) ^ => bstr, * key => any } ]]> The cnonce is a bstr and MUST be treated as opaque to the Holder.

SD-KBT and SD-CWT Verifier Validation The exact order of the following steps MAY be changed, as long as all checks are performed before deciding if an SD-CWT is valid. First the Verifier must open the protected headers of the SD-KBT and find the issuer SD-CWT present in the kcwt field. Next the Verifier must validate the SD-CWT as described in . The Verifier extract the confirmation key from the cnf claim in the SD-CWT payload. Using the confirmation key, the Verifier validates the SD-KBT as described in . Finally, the Verifier MUST extract and decode the disclosed claims from the sd_claims in the unprotected header of the SD-CWT. The decoded sd_claims are converted to an intermediate data structure called a Digest To Disclosed Claim Map which is used to transform the Presented Disclosed Claimset, into a Validated Disclosed Claimset. The Verifier MUST compute the hash of each Salted Disclosed Claim (salted), in order to match each disclosed value to each entry of the Presented Disclosed Claimset. One possible concrete representation of the intermediate data structure for the Digest To Disclosed Claim Map could be: salted } ]]> The Verifier constructs an empty cbor map called the Validated Disclosed Claimset, and initializes it with all mandatory to disclose claims from the verified Presented Disclosed Claimset. Next the Verifier performs a breadth first or depth first traversal of the Presented Disclosed Claimset, Validated Disclosed Claimset, using the Digest To Disclosed Claim Map to insert claims into the Validated Disclosed Claimset when they appear in the Presented Disclosed Claimset. By performing these steps, the recipient can cryptographically verify the integrity of the protected claims and verify they have not been tampered with. If there remain unused Digest To Disclosed Claim Map at the end of this procedure the SD-CWT MUST be considered invalid, as if the signature had failed to verify. Otherwise the SD-CWT is considered valid, and the Validated Disclosed Claimset is now a CWT Claimset with no claims marked for redaction. Further validation logic can be applied to the Validated Disclosed Claimset, as it might normally be applied to a validated CWT claimset.

Decoy Digests TODO

Credential Types This specification defines the CWT claim vct (for verifiable credential type). The vct value MUST be a case-sensitive StringOrURI (see ) value serving as an identifier for the type of the SD-CWT claimset. The vct value MUST be a Collision-Resistant Name as defined in Section 2 of . This claim is defined for COSE based verifiable credentials, similar to the JOSE based verifiable credentials claim (vct) described in Section 3.2.2.1.1 of . Profiles built on this specification are also encouraged to use more specific media types, as described in .

Examples TODO - Provide more examples

Minimal spanning example The following example contains claims needed to demonstrate redaction of key-value pairs and array elements.

An EDN Example >, / CWT unprotected / { / sd_claims / 17 : <<[ /these are the disclosures/ <<[ /salt/ h'8d5c15fa86265d8ff77a0e92720ca837', /claim/ 501, / inspector_license_number / /value/ "ABCD-123456" ]>>, <<[ /salt/ h'86c84b9c3614ba27073c7e5a475a2a13', /value/ 1549560720 / inspected 7-Feb-2019 / ]>>, <<[ /salt/ h'30eef86edeaa197df7bd3d17dd89cd87', /claim/ "region", /value/ "ca" /California/ ]>> ]>>, }, / CWT payload / << { / iss / 1 : "https://issuer.example", / sub / 2 : "https://device.example", / aud / 3 : "https://verifier.example", / exp / 4 : 1883000000, / iat / 6 : 1683000000, / cnf / 8 : { / cose key / 1 : { / alg: ES256 / 3: 35, / kty: EC2 / 1: 2, / crv: P-256 / -1: 1, / x / -2: h'768ed88626', / y / -3: h'6a48ccfd5d' } }, /most_recent_inspection_passed/ 500: true, / redacted_claim_keys / 59(0) : [ / redacted inspector_license_number / h'7e6e350907d0ba3aa7ae114f8da5b360' + h'601c0bb7995cd40049b98e4f58fb6ec0' ], /inspection_dates/ 502 : [ / redacted inspection date 7-Feb-2019 / 60(h'a0f74264a8c97655c958aff3687f1390' + h'ed0ab6f64cd78ba43c3fefee0de7b835') / redacted inspection date 4-Feb-2021 / 60(h'1e7275bcda9bc183079cd4515c5c0282' + h'a2a0e9105b660933e2e68f9a3f40974b') 1674004740, / 2023-01-17T17:19:00 / ], / inspection_location / 503 : { "country" : "us", / United States / / redacted_claim_keys / 59(0) : [ / redacted region / h'c47e3b047c1cd6d9d1e1e01514bc2ec9' + h'ed010ac9ae1c93403ec72572bb1e00e7', / redacted postal_code / h'0b616e522a05d8d134a834979710120d' + h'41ac1522b056d5f9509cf7e850047302' ] } } >>, / end of issuer_sd_cwt payload / / CWT signature / h'3337af2e66959614' ])>>, / end of issuer SD-CWT / }>>, / end of KBT protected header / KBT unprotected / {}, / KBT payload / << { / cnonce / 39 : h'e0a156bb3f', / aud / 3 : "https://verifier.example", / iat / 6 : 1783000000 } >>, / end of kbt payload / / KBT signature / h'1237af2e678945' ]) / end of kbt / ]]>

Nested example TODO

Implementation Status Note to RFC Editor: Please remove this section as well as references to before AUTH48. This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

Transmute Prototype Organization: Transmute Industries Inc Name: github.com/transmute-industries/sd-cwt Description: An open source implementation of this draft. Maturity: Prototype Coverage: The current version ('main') implements functionality similar to that described in this document, and will be revised, with breaking changes to support the generation of example data to support this specification. License: Apache-2.0 Implementation Experience: No interop testing has been done yet. The code works as proof of concept, but is not yet production ready. Contact: Orie Steele (orie@transmute.industries)

Security Considerations Security considerations from COSE {(RFC9052)} and CWT apply to this specification.

Random Numbers Each salt used to protect disclosed claims MUST be generated independently from the salts of other claims. The salts MUST be generated from a source of entropy that is acceptable to the issuer. Poor choice of salts can lead to brute force attacks that can reveal redacted claims.

IANA Considerations

COSE Header Parameters IANA is requested to add the following entries to the CWT claims registry (https://www.iana.org/assignments/cose/cose.xhtml#header-parameters).

sd_claims The following completed registration template per RFC8152 is provided:

• Name: sd_claims
• Label: TBD1 (requested assignment 17)
• Value Type: bstr
• Value Registry: (empty)
• Description: A list of selectively disclosed claims, which were originally redacted, then later disclosed at the discretion of the sender.
• Reference: RFC XXXX

sd_alg The following completed registration template per RFC8152 is provided:

• Name: sd_alg
• Label: TBD2 (requested assignment 18)
• Value Type: int
• Value Registry: COSE Algorithms
• Description: The hash algorithm used for redacting disclosures.
• Reference: RFC XXXX

CBOR Tags

To be redacted tag The array claim element, or map key and value inside the "To be redacted" tag is intended to be redacted using selective disclosure.

• Tag: TBD3 (requested assignment 58)
• Data Item: (any)
• Semantics: An array claim element, or map key and value intended to be redacted.
• Specification Document(s): RFC XXXX

Redacted claim keys tag This tag encloses the integer claim key 0 (reserved as a CWT claim key). It indicates that the claim value is an array of redacted claim keys at the same level.

• Tag: TBD4 (requested assignment 59)
• Data Item: unsigned integer 0
• Semantics: Tags the claim key 0. The value of the key is an array of selective disclosure redacted claim keys.
• Specification Document(s): RFC XXXX

Redacted claim element tag The binary string inside the tag is a selective disclosure redacted claim element of an array.

• Tag: TBD5 (requested assignment 60)
• Data Item: byte string
• Semantics: A selective disclosure redacted (array) claim element.
• Specification Document(s): RFC XXXX

CBOR Web Token (CWT) Claims IANA is requested to add the following entries to the CWT claims registry (https://www.iana.org/assignments/cwt/cwt.xhtml).

vct The following completed registration template per RFC8392 is provided:

• Claim Name: vct
• Claim Description: Verifiable credential type
• JWT Claim Name: vct
• Claim Key: TBD6 (request assignment 11)
• Claim Value Type(s): bstr
• Change Controller: IETF
• Specification Document(s): RFC XXXX

Media Types This section requests the registration of new media types in https://www.iana.org/assignments/media-types/media-types.xhtml.

application/sd+cwt IANA is requested to add the following entry to the media types registry in accordance with RFC6838, RFC4289, and RFC6657. The following completed registration template is provided:

• Type name: application
• Subtype name: sd+cwt
• Required parameters: n/a
• Optional parameters: n/a
• Encoding considerations: binary
• Security considerations: See the Security Considerations section of RFC XXXX, and
• Interoperability considerations: n/a
• Published specification: RFC XXXX
• Applications that use this media type: TBD
• Fragment identifier considerations: n/a
• Additional information:
  • Magic number(s): n/a
  • File extension(s): n/a
  • Macintosh file type code(s): n/a
• Person & email address to contact for further information: Michael Prorock, mprorock@mesur.io
• Intended usage: COMMON
• Restrictions on usage: none
• Author: Michael Prorock, mprorock@mesur.io
• Change controller: IETF
• Provisional registration? No

application/kb+cwt IANA is requested to add the following entry to the media types registry in accordance with RFC6838, RFC4289, and RFC6657. The following completed registration template is provided:

• Type name: application
• Subtype name: kb+cwt
• Required parameters: n/a
• Optional parameters: n/a
• Encoding considerations: binary
• Security considerations: See the Security Considerations section of RFC XXXX, and
• Interoperability considerations: n/a
• Published specification: RFC XXXX
• Applications that use this media type: TBD
• Fragment identifier considerations: n/a
• Additional information:
  • Magic number(s): n/a
  • File extension(s): n/a
  • Macintosh file type code(s): n/a
• Person & email address to contact for further information: Orie Steele, orie@transmute.industries
• Intended usage: COMMON
• Restrictions on usage: none
• Author: Orie Steele, orie@transmute.industries
• Change controller: IETF
• Provisional registration? No

References Normative References JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. Universität Bremen TZI The Concise Binary Object Representation (CBOR) (STD 94, RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. In addition to the binary interchange format, CBOR from the outset (RFC 7049) defined a text-based "diagnostic notation" in order to be able to converse about CBOR data items without having to resort to binary data. RFC 8610 extended this into what is known as Extended Diagnostic Notation (EDN). This document consolidates the definition of EDN, sets forth a further step of its evolution, and is intended to serve as a single reference target in specifications that use EDN. It specifies an extension point for adding application-oriented extensions to the diagnostic notation. It then defines two such extensions that enhance EDN with text representations of epoch-based date/times and of IP addresses and prefixes (RFC 9164). A few further additions close some gaps in usability. The document modifies one extension originally specified in Appendix G.4 of RFC 8610 to enable further increasing usability. To facilitate tool interoperation, this document specifies a formal ABNF grammar, and it adds media types. // (This "cref" paragraph will be removed by the RFC editor:) The // present revision -13 reflects the branches "roll-up" and "roll-up- // 2" in the repository, an attempt to contain the entire // specification of EDN in this document, instead of describing // updates to the existing documents RFC 8949 and RFC 8610. // Editorial work on the branch "roll-up-2" might continue. The // exact reflection of this document being a replacement for both // Section 8 of RFC 8949 and Appendix G of RFC 8610 needs to be // recorded in the metadata and in abstract and introduction. This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios, and a main use case is to establish an Object Security for Constrained RESTful Environments (OSCORE) security context. By reusing CBOR Object Signing and Encryption (COSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding, and Constrained Application Protocol (CoAP) for transport, the additional code size can be kept very low. This specification adds the equivalent of the JSON Object Signing and Encryption (JOSE) "typ" (type) header parameter to CBOR Object Signing and Encryption (COSE). This enables the benefits of explicit typing (as defined in RFC 8725, "JSON Web Token Best Current Practices") to be brought to COSE objects. The syntax of the COSE type header parameter value is the same as the existing COSE content type header parameter. This specification describes how to declare in a CBOR Web Token (CWT) (which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs). Informative References Authlete Keio University Ping Identity This specification defines a mechanism for the selective disclosure of individual elements of a JSON-encoded data structure used as the payload of a JSON Web Signature (JWS). The primary use case is the selective disclosure of JSON Web Token (JWT) claims. MATTR Authlete Inc. Ping Identity This specification describes data formats as well as validation and processing rules to express Verifiable Credentials with JSON payloads with and without selective disclosure based on the SD-JWT [I-D.ietf-oauth-selective-disclosure-jwt] format. Google LLC Guardian Project Cloudflare Inc. Most HTTP authentication schemes are probeable in the sense that it is possible for an unauthenticated client to probe whether an origin serves resources that require authentication. It is possible for an origin to hide the fact that it requires authentication by not generating Unauthorized status codes, however that only works with non-cryptographic authentication schemes: cryptographic signatures require a fresh nonce to be signed. Prior to this document, there was no existing way for the origin to share such a nonce without exposing the fact that it serves resources that require authentication. This document defines a new non-probeable cryptographic authentication scheme.

Complete CDDL Schema

A complete CDDL description of SD-CWT "application/sd+cwt", &(alg: 1) ^ => int, &(sd_alg: TBD2) ^= int, ; -16 for sha-256 * key => any } kbt-protected = { &(typ: 16) ^ => "application/kb+cwt", &(alg: 1) ^ => int, &(kcwt: 13) ^ => bstr .cbor sd-cwt-issued, * key => any } sd-unprotected = { ? &(sd_claims: TBD1) ^ => bstr .cbor salted-array, * key => any } kbt-unprotected = { * 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 ; ? &(redacted_claim_keys: TBD3) ^ => [ * bstr ], * key => any } kbt-payload = { &(aud: 3) ^ => tstr, ; "https://verifier.example" ? &(exp: 4) ^ => int, ; 1883000000 ? &(nbf: 5) ^ => int, ; 1683000000 &(iat: 6) ^ => int, ; 1683000000 ? &(cnonce: 39) ^ => bstr, * key => any } salted-array = [ +bstr .cbor salted ] salted = salted-claim / salted-element / decoy salted-claim = [ bstr .size 16, ; 128-bit salt (int / text), ; claim name any ; claim value ] salted-element = [ bstr .size 16, ; 128-bit salt any ; claim value ] decoy = [ bstr .size 16 ; 128-bit salt ] key = int / text TBD1 = 17 TBD2 = 18 ;TBD3 = #6.58(any) ; CBOR tag wrapping to-be-redacted keys or elements TBD4 = #6.59(0) ; CBOR tag 59 wrapping reserved integer claim key 0 ;TBD5 = #6.60( bstr ) ;redacted_claim_element ]]>

Comparison to SD-JWT SD-CWT is modeled after SD-JWT, with adjustments to align with conventions in CBOR and COSE.

Media Types The COSE equivalent of application/sd-jwt is application/sd+cwt. THe COSE equivalent of application/kb+jwt is application/kb+cwt.

Redaction Claims The COSE equivalent of _sd is a CBOR tag (requested assignment 59) of the claim key 0. The corresponding claim value is an array of the redacted claim keys. The COSE equivalent of ... is a CBOR tag (requested assignment 60) of the digested salted claim.

Issuance The issuance process for SD-CWT is similar to SD-JWT, with the exception that a confirmation claim is REQUIRED.

Presentation The presentation process for SD-CWT is similar to SD-JWT, except that a Key Binding Token is REQUIRED. The Key Binding Token then includes the issued SD-CWT, including the Holder-selected disclosures. Because the entire SD-CWT is included as a claim in the SD-KBT, the disclosures are covered by the Holder's signature in the SD-KBT, but not by the Issuer's signature in the SD-CWT.

Validation The validation process for SD-CWT is similar to SD-JWT, however, JSON Objects are replaced with CBOR Maps which can contain integer keys and CBOR Tags.

Keys used in the examples

Subject / Holder Holder key pair in JWK format Input to Holder public JWK thumbprint (ignore line breaks) SHA-256 of the Holder public JWK input string (in hex) Holder public JWK thumbprint Holder public key in PEM format Hodler private key in PEM format

Issuer Issuer key pair in JWK format Input to Issuer JWK thumbprint (ignore line breaks) SHA-256 of the Issuer JWK input string (in hex) Issuer JWK thumbprint Issuer public key in PEM format Issuer private key in PEM format

Document History Note: RFC Editor, please remove this entire section on publication.

draft-ietf-spice-sd-cwt-02

• KBT now includes the entire SD-CWT in the Confirmation Key CWT (kcwt) existing COSE protected header. Has algorithm now specified in new sd_alg COSE protected header. No more sd_hash claim. (PR #34, 32)
• Introduced tags for redacted and to-be-redacted claim keys and elements. (PR#31, 28)
• Updated example to be a generic inspection certificate. (PR#33)
• Add section saying SD-CWT updates the CWT spec (RFC8392). (PR#29)

draft-ietf-spice-sd-cwt-01

• Added Overview section
• Rewrote the main normative section
• Made redaacted_claim_keys use an unlikely to collide claim key integer
• Make cnonce optional (it now says SHOULD)
• Made most standard claims optional.
• Consistently avoid use of bare term "key" - to make crypto keys and map keys clear
• Make clear issued SD-CWT can contain zero or more redactions; presented SD-CWT can disclose zero, some, or all redacted claims.
• Clarified use of sd_hash for issuer to holder case._
• Lots of editorial cleanup
• Added Rohan as an author and Brian Campbell to Acknowledgements
• Updated implementation status section to be BCP205-compatible
• Updated draft metadata

draft-ietf-spice-sd-cwt-00

• Initial working group version based on draft-prorock-spice-cose-sd-cwt-01.

Acknowledgments The authors would like to thank those that have worked on similar items for providing selective disclosure mechanisms in JSON, especially: Brent Zundel, Roy Williams, Tobias Looker, Kristina Yasuda, Daniel Fett, Brian Campbell, Oliver Terbu, and Michael Jones.