]> mesur.io

mprorock@mesur.io

Tradeverifyd

orie@or13.io

Fraunhofer SIT

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

rohan.ietf@gmail.com

Security Secure Patterns for Internet CrEdentials cose cwt selective disclosure This specification describes a data minimization technique for use with CBOR Web Tokens (CWTs). The approach is based on the Selective Disclosure JSON Web Token (SD-JWT), with changes to align with CBOR Object Signing and Encryption (COSE) and CWTs. 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 specification creates a new format based on the CBOR Web Token (CWT) specification , enabling the Holder of a CWT to disclose or redact special claims marked as selectively 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) and CWT. 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, SD-CWTs remain traceable. Selective Disclosure CBOR Web Tokens (SD-CWTs) can be deployed in protocols that are already using CWTs with minor changes, 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 specification, and the examples used in this specification 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 Verifier that does not understand selective disclosure at all can only act on unblinded claims sent by the Holder; it will ignore Blinded Claims representing array items, and will fail to process any SD-CWT containing Blinded Claims that represent map keys. optional Claim Keys, whether they are disclosed or not, can only be processed by a Verifier that understands this specification. However, Claim Keys and Claim Values that 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 that 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 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 specification uses terms from CWT , COSE and JWT . The terms Claim Name, Claim Key, and Claim Value are defined in . This specification 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 with an SD-CWT.

Assertion Key:

A key used by the Issuer to sign a Claim Values.

Confirmation Key:

A key used by the Holder to sign a Selected Salted Disclosed Claims.

Issuer:

An entity that produces a Selective Disclosure CBOR Web Token by signing a Claim Values with an Assertion Key.

Holder:

An entity that presents a Selective Disclosure Key Binding Token, containing a Selective Disclosure CBOR Web Token and Selected Salted Disclosed Claims signed with a Confirmation Key.

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 (when all claims are marked as 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.

Blinded Claim Hash:

A hash digest of a Salted Disclosed Claim.

Blinded Claim:

Any Redacted Claim Key or Redacted Claim Element that 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.

The following diagram explains the relationships between the terminology used in this specification. This diagram relates the terminology specific to selective disclosure and redaction.

Overview of Selective Disclosure CWT

A CWT without Selective Disclosure Below is the payload of a standard CWT not using 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 dates 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 claims that are always present in the SD-CWT. After the Holder requests an SD-CWT from the Issuer, the Issuer generates the following SD-CWT:

Issued SD-CWT with all disclosures >, / CWT unprotected / { / sd_claims / 17 : [ / these are all the disclosures / <<[ /salt/ h'bae611067bb823486797da1ebbb52f83', /value/ "ABCD-123456", /claim/ 501 / inspector_license_number / ]>>, <<[ /salt/ h'8de86a012b3043ae6e4457b9e1aaab80', /value/ 1549560720 / inspected 7-Feb-2019 / ]>>, <<[ /salt/ h'7af7084b50badeb57d49ea34627c7a52', /value/ 1612560720 / inspected 4-Feb-2021 / ]>>, <<[ /salt/ h'ec615c3035d5a4ff2f5ae29ded683c8e', /value/ "ca", /claim/ "region" / region=California / ]>>, <<[ /salt/ h'37c23d4ec4db0806601e6b6dc6670df9', /value/ "94188", /claim/ "postal_code" ]>>, ] } / CWT payload / << { / iss / 1 : "https://issuer.example", / sub / 2 : "https://device.example", / exp / 4 : 1725330600, /2024-09-03T02:30:00+00:00Z/ / nbf / 5 : 1725243900, /2024-09-02T02:25:00+00:00Z/ / iat / 6 : 1725244200, /2024-09-02T02:30:00+00:00Z/ / cnf / 8 : { / cose key / 1 : { / kty / 1: 2, / EC2 / / crv / -1: 1, / P-256 / / x / -2: h'8554eb275dcd6fbd1c7ac641aa2c90d9 2022fd0d3024b5af18c7cc61ad527a2d', / y / -3: h'4dc7ae2c677e96d0cc82597655ce92d5 503f54293d87875d1e79ce4770194343' } }, /most_recent_inspection_passed/ 500: true, /inspection_dates/ 502 : [ / redacted inspection date 7-Feb-2019 / 60(h'1b7fc8ecf4b1290712497d226c04b503 b4aa126c603c83b75d2679c3c613f3fd'), / redacted inspection date 4-Feb-2021 / 60(h'64afccd3ad52da405329ad935de1fb36 814ec48fdfd79e3a108ef858e291e146'), 1674004740, / 2023-01-17T17:19:00 / ], / inspection_location / 503 : { "country" : "us", / United States / / redacted_claim_keys / simple(59) : [ / redacted region / h'0d4b8c6123f287a1698ff2db15764564 a976fb742606e8fd00e2140656ba0df3' / redacted postal_code / h'c0b7747f960fc2e201c4d47c64fee141 b78e3ab768ce941863dc8914e8f5815f' ] }, / redacted_claim_keys / simple(59) : [ / redacted inspector_license_number / h'af375dc3fba1d082448642c00be7b2f7 bb05c9d8fb61cfc230ddfdfb4616a693' ] } >>, / CWT signature / h'ed7ff84b27e746199698a94cc19292e4 b72dc4c3eb551f0ef2b9da07980c648c 2bb033c337c6ed13e1bc7c5b7b7c9df9 49a70239f51eca1f6d8e058b8b70bcb3 b5746812a932ffb37a2e6e984957e3f6 b003eb3319fbe21e97f6a3a273307424' ]) ]]>

Some of the claims are redacted in the payload. The corresponding disclosure is communicated in the unprotected header in the sd_claims header parameter. For example, the inspector_license_number claim is a Salted Disclosed Claim, consisting of a per-disclosure random salt, the Claim Key, and Claim Value.

CBOR extended diagnostic notation representation of inspector_license_number disclosure >, ]]>

This is represented in CBOR pretty-printed format as follows (with end-of-line comments and spaces inserted for clarity):

CBOR encoding of inspector_license_number disclosure

The cryptographic hash, using the hash algorithm identified by the sd_alg header parameter in the protected headers, of that byte string is the Blinded Claim Hash (shown 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 (for example, for the redacted claim element of inspection_dates).

SHA-256 hash of inspector_license_number disclosure

Finally, since this redacted claim is a map key and value, the Blinded Claim Hash is placed in a redacted_claim_keys array in the SD-CWT payload at the same level of hierarchy as the original claim. Redacted claims that are array elements are handled slightly differently, as described in .

redacted inspector_license_number claim in the issued CWT payload

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 header parameter 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'8de86a012b3043ae6e4457b9e1aaab80', /value/ 1549560720 / inspected 7-Feb-2019 / ]>>, <<[ /salt/ h'ec615c3035d5a4ff2f5ae29ded683c8e', /value/ "ca", /claim/ "region" / region=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 ). >, / end of KBT protected header / / KBT unprotected / {}, / KBT payload / << { / aud / 3 : "https://verifier.example/app", / iat / 6 : 1725244237, / 2024-09-02T02:30:37+00:00Z / / cnonce / 39 : h'8c0f5f523b95bea44a9a48c649240803' } >>, / end of KBT payload / / KBT signature / h'dd49379434b25b03cd8756787ab49731 580a04505439ca78ee53300dd49a00b7 0e8715d015a2a6e8d88455f5850e3d93 eade1366c0040c2cee1cc568322a6b93' ]) / end of kbt / ]]> The digests in protected parts of the issued SD-CWT and the disclosures hashed in unprotected header of the issuer_sd_cwt are used together 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 that the Holder included the sent list of disclosures.

Differences from the CBOR Web Token Specification The CBOR Web Token Specification (Section 1.1 of ), uses text strings, negative integers, and unsigned integers as map keys. This specification also allows the CBOR simple value registered in this specification in , and CBOR tagged integers and text strings as map keys. As in CWTs, CBOR maps used in an SD-CWT or SD-KBT also cannot have duplicate keys. (An integer or text string map key is a distinct key from a tagged map key that wraps the corresponding integer or text string value).

• When sorted, map keys in CBOR are arranged in bytewise lexicographic order of the key's deterministic encodings (see Section 4.2.1 of ). So, an integer key of 3 is represented in hex as 03, an integer key of -2 is represented in hex as 21, and a tag of 60 wrapping a 3 is represented in hex as D8 3C 03

Note that Holders presenting to a Verifier that does not support this specification would need to present a CWT without tagged map keys or simple value 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. Variability in serialization requirements impacts privacy. See for more details on the privacy impact of serialization and profiling.

SD-CWT Definition SD-CWT is modeled after SD-JWT, with adjustments to align with conventions in CBOR, COSE, and CWT. An SD-CWT MUST include the protected header parameter typ with a value declaring that the object is an SD-CWT. This value MAY be the string content type value application/sd-cwt, the uint Constrained Application Protocol (CoAP) content-format value TBD11, or a value declaring that the object is a more specific kind of SD-CWT, such as a content type value using the +sd-cwt structured suffix. An SD-CWT is an extension of a CWT that can contain blinded claims (each expressed as a Blinded Claim Hash) in the CWT payload, at the root level or in any arrays or maps inside that payload. It is not required to contain any blinded claims. Optionally the salted Claim Values (and often Claim Keys) for the corresponding Blinded Claim Hash are disclosed in the sd_claims header parameter in the unprotected header of the CWT (the disclosures). If there are no disclosures (and when no Blinded Claims Hash is present in the payload) the sd_claims header parameter in the unprotected header is an empty array. 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 disclosed value, and the name of the redacted element. 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 CBOR simple type TBD4 registered for that purpose (with the requested value of 59). When blinding an individual item in an array, the value of the item is replaced with the digested salted hash as a CBOR byte string, wrapped with the CBOR tag TBD5 (requested tag number 60). ( bstr ) -- RFC 9682 syntax redacted_claim_element = #6.60( bstr ) ]]> 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 blinded claim hashes 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 for 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 MAY contain the sd_alg header parameter identifying the algorithm (from the COSE Algorithms registry) used to hash the Salted Disclosed Claims. If no sd_alg header parameter is present, the default hash function SHA-256 is used. The unprotected header MUST contain the sd_claims header parameter with a Salted Disclosed Claim for every blinded claim hash present anywhere in the payload, and any decoys (see ). If there are no disclosures, the sd_claims header parameter value is an empty array. The payload also MUST include a key confirmation element (cnf) for the Holder's public key. In an SD-CWT, either the subject sub / 2 claim MUST be present, or the redacted form of the subject MUST be present. The iss / 1 claim SHOULD be present unless the protected header contains a certificate or certificate-like entity that fully identifies the Issuer. All other standard CWT claims (aud / 3, exp / 4, nbf / 5, iat / 6, and cti / 7) are OPTIONAL. The cnonce / 39 claim is OPTIONAL. The cnf / 8 claim, the cnonce / 39 claim, and the standard claims other than the subject MUST NOT be redacted. Any other claims are OPTIONAL and MAY be redacted. Profiles of this specification MAY specify additional claims that MUST, MUST NOT, and MAY be redacted. To further reduce the size of the SD-CWT, a COSE Key Thumbprint (ckt) MAY be used in the cnf claim.

Issuer Generation The Issuer follows all the requirements of generating a valid SD-CWT, largely a CWT extended by . The Issuer MUST implement COSE_Sign1 using an appropriate fully-specified asymmetric signature algorithm (for example, ESP256 or 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 MUST 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, if present;
• a public key under the control of the Holder is present in the cnf claim;
• the hash algorithm identified by the sd_alg header parameter in the protected headers 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 that 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;
• the values of the Salted Disclosed Claims when placed in their unblinded context in the payload are acceptable to the Holder.

• A Holder MAY choose to validate the appropriateness or correctness of some or all of the information in a token, should it have the ability to do so, and it MAY choose to not present information to a Verifier that it deems to be incorrect.

The following informative CDDL is provided to describe the syntax for SD-CWT issuance. A complete CDDL schema is in . "application/sd-cwt" / TBD11, &(alg: 1) ^ => int, ? &(kid: 4) ^ => bstr, ? &(sd_alg: TBD2) ^ => int, ; -16 for sha-256 ? &(sd_aead: TBD7) ^ => uint .size 2, * key => any } sd-unprotected = { ? &(sd_claims: TBD1) ^ => salted-array, ? &(sd_aead_encrypted_claims: TBD6) ^ => aead-encrypted-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) ^ => num, ; 1883000000 ? &(nbf: 5) ^ => num, ; 1683000000 ? &(iat: 6) ^ => num, ; 1683000000 ? &(cti: 7) ^ => bstr, &(cnf: 8) ^ => { * key => any }, ; key confirmation ? &(cnonce: 39) ^ => bstr, ; ? &(redacted_claim_keys: REDACTED_KEYS) ^ => [ * bstr ], * key => any } ]]>

SD-CWT Presentation When issuing an SD-CWT to a Holder, the Issuer includes all the Salted Disclosed Claims in the unprotected header. By contrast, 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 blinded claims, it includes that subset of its Salted Disclosed Claims in the sd_claims header parameter 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 chooses the subset of disclosures included in the sd_claims header parameter.

• Since the unprotected header is not included in the Issuer's signature, the list of disclosed claims can differ without invalidating the corresponding signature.

Finally, the SD-CWT used for presentation to a Verifier is included in a key binding token, as discussed 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 Holder is conceptually both the subject and the Issuer of the Key Binding Token. Therefore, the sub and iss of an SD-KBT are implied from the cnf claim in the included SD-CWT, and MUST NOT be present in the SD-KBT. (Profiles of this specification MAY define additional semantics.) The aud claim MUST be included and MUST correspond to the Verifier. The SD-KBT payload MUST contain the iat (issued at) claim. The protected header of the SD-KBT MUST include the typ header parameter with the value application/kb+cwt or the uint value of TBD12. 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 , 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" / TBD12, &(alg: 1) ^ => int, &(kcwt: 13) ^ => sd-cwt-issued, * key => any } kbt-unprotected = { * key => any } kbt-payload = { &(aud: 3) ^ => tstr, ; "https://verifier.example/app" ? &(exp: 4) ^ => num, ; 1883000000 ? &(nbf: 5) ^ => num, ; 1683000000 &(iat: 6) ^ => num, ; 1683000000 ? &(cnonce: 39) ^ => bstr, * key => any } ]]> The SD-KBT payload MAY include a cnonce claim. If included, the cnonce is a bstr and MUST be treated as opaque to the Holder. All other claims are OPTIONAL in an SD-KBT.

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.

1. First the Verifier must open the protected headers of the SD-KBT and find the Issuer SD-CWT present in the kcwt field.
2. Next, the Verifier must validate the SD-CWT as described in .
3. The Verifier extracts the confirmation key from the cnf claim in the SD-CWT payload.
4. Using the confirmation key, the Verifier validates the SD-KBT as described in .
5. The Verifier MUST extract and decode the disclosed claims from the sd_claims header parameter in the unprotected header of the SD-CWT. Each decoded disclosure is treated as if it is a claim key or claim element at the location corresponding to its Blinded Claim Hash in the payload. If there are any disclosures that do not have a corresponding Blinded Claim Hash, the entire SD-CWT is invalid. If any decoded Redacted Claim Key duplicates another claim key in the same position, the entire SD-CWT is invalid.
   • Note: A Verifier MUST be prepared to process disclosures in any order. When disclosures are nested, a disclosed value could appear before the disclosure of its parent.

6. A Verifier MUST reject the SD-CWT if the audience claim in either the SD-CWT or the SD-KBT contains a value that does not correspond to the intended recipient.
7. Otherwise, the SD-CWT is considered valid, and the Validated Disclosed Claims Set is now a CWT Claims Set with no claims marked for redaction.
8. Further validation logic can be applied to the Validated Disclosed Claims Set, just as it might be applied to a validated CWT Claims Set.

By performing these steps, the recipient can cryptographically verify the integrity of the protected claims and verify they have not been tampered with.

Decoy Digests TODO

Encrypted Disclosures The RATS architecture defines a model where the Verifier is split into separate entities, with an initial verifier called an Attester, and a target entity called a Relying Party. Other protocols have a similar type of internal structure for the Verifier. In some of these use cases, there is existing usage of AES-128 GCM and other Authenticated Encryption with Additional Data (AEAD) algorithms. This section describes how to use AEADs to encrypt disclosures to a target entity, while enabling a initial verifier to confirm the authenticity of the presentation from the Holder. In these systems, an appropriate symmetric key and its context are provided completely out-of-band. The entire SD-CWT is included in the protected header of the SD-KBT, which secures the entire Issuer-signed SD-CWT including its unprotected headers that include its disclosures. When encrypted disclosures are present, they MUST be in the unprotected headers of the Issuer-signed SD-CWT, before the SD-KBT can be generated by the Holder. The initial Verifier of the key binding token might not be able to decrypt encrypted disclosures and MAY decide to forward them to an inner Verifier that can decrypt them.

AEAD Encrypted Disclosures Mechanism This section defines two new COSE Header Parameters. If present in the protected headers, the first header parameter (sd_aead) specifies an Authenticated Encryption with Additional Data (AEAD) algorithm registered in the IANA AEAD Algorithms registry . (Guidance on specific algorithms is discussed in .) The second header parameter (sd_aead_encrypted_claims) contains a list of AEAD encrypted disclosures. Taking the first example disclosure from above: >, ]]> The corresponding bstr is encrypted with an AEAD algorithm . If present, the algorithm of the sd_aead protected header field is used, or AEAD_AES_128_GCM if no algorithm was specified. The bstr is encrypted with a unique, random 16-octet nonce. The AEAD ciphertext consists of its encryption algorithm's ciphertext and its authentication tag. (For example, in AEAD_AES_128_GCM the authentication tag is 16 octets.) The nonce (nonce), the encryption algorithm's ciphertext (ciphertext) and authentication tag (tag) are put in an array. The resulting array is placed in the sd_aead_encrypted_claims header parameter in the unprotected headers of the SD-CWT.

• In the example above, the key in hex is a061c27a3273721e210d031863ad81b6.

The blinded claim hash is still over the unencrypted disclosure. The receiver of an AEAD encrypted disclosure locates the appropriate key by looking up the authentication tag. If the Verifier is able to decrypt and verify an encrypted disclosure, the decrypted disclosure is then processed as if it were in the sd_claims header parameter in the unprotected headers of the SD-CWT. Details of key management are left to profiles of the specific protocols that make use of AEAD encrypted disclosures. The CDDL for AEAD encrypted disclosures is below.

• Note: Because the encryption algorithm is in a registry that contains only AEAD algorithms, an attacker cannot replace the algorithm or the message, without a decryption verification failure.

Credential Types This specification defines the CWT claim vct (for Verifiable Credential Type). The vct value is an identifier for the type of the SD-CWT Claims Set. Like the typ header parameter , its value can be either a string or an integer. For size reasons, it is RECOMMENDED that the numeric representation be used. If its value is a string, it is a case-sensitive StringOrURI, as defined in . In this case, the vct string MUST either be registered in the IANA "Verifiable Credential Type Identifiers" registry established in , or be a Collision-Resistant Name, as defined in Section 2 of . If its value is an integer, it is either a value in the range 0-64999 registered in the IANA "Verifiable Credential Type Identifiers" registry established in or an Experimental Use value in the range 65000-65535, which is not to be used in operational deployments. 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 .

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'bae611067bb823486797da1ebbb52f83', /value/ "ABCD-123456", /claim/ 501 / inspector_license_number / ]>>, <<[ /salt/ h'8de86a012b3043ae6e4457b9e1aaab80', /value/ 1549560720 / inspected 7-Feb-2019 / ]>>, <<[ /salt/ h'ec615c3035d5a4ff2f5ae29ded683c8e', /value/ "ca", /claim/ "region" / region=California / ]>>, ] } / CWT payload / << { / iss / 1 : "https://issuer.example", / sub / 2 : "https://device.example", / exp / 4 : 1725330600, /2024-09-03T02:30:00+00:00Z/ / nbf / 5 : 1725243900, /2024-09-02T02:25:00+00:00Z/ / iat / 6 : 1725244200, /2024-09-02T02:30:00+00:00Z/ / cnf / 8 : { / cose key / 1 : { / kty / 1: 2, / EC2 / / crv / -1: 1, / P-256 / / x / -2: h'8554eb275dcd6fbd1c7ac641aa2c90d9 2022fd0d3024b5af18c7cc61ad527a2d', / y / -3: h'4dc7ae2c677e96d0cc82597655ce92d5 503f54293d87875d1e79ce4770194343' } }, /most_recent_inspection_passed/ 500: true, /inspection_dates/ 502 : [ / redacted inspection date 7-Feb-2019 / 60(h'1b7fc8ecf4b1290712497d226c04b503 b4aa126c603c83b75d2679c3c613f3fd'), / redacted inspection date 4-Feb-2021 / 60(h'64afccd3ad52da405329ad935de1fb36 814ec48fdfd79e3a108ef858e291e146'), 1674004740, / 2023-01-17T17:19:00 / ], / inspection_location / 503 : { "country" : "us", / United States / / redacted_claim_keys / simple(59) : [ / redacted region / h'0d4b8c6123f287a1698ff2db15764564 a976fb742606e8fd00e2140656ba0df3' / redacted postal_code / h'c0b7747f960fc2e201c4d47c64fee141 b78e3ab768ce941863dc8914e8f5815f' ] }, / redacted_claim_keys / simple(59) : [ / redacted inspector_license_number / h'af375dc3fba1d082448642c00be7b2f7 bb05c9d8fb61cfc230ddfdfb4616a693' ] } >>, / CWT signature / h'ed7ff84b27e746199698a94cc19292e4 b72dc4c3eb551f0ef2b9da07980c648c 2bb033c337c6ed13e1bc7c5b7b7c9df9 49a70239f51eca1f6d8e058b8b70bcb3 b5746812a932ffb37a2e6e984957e3f6 b003eb3319fbe21e97f6a3a273307424' ]), / end of issuer SD-CWT / / typ / 16: "application/kb+cwt", } >>, / end of KBT protected header / / KBT unprotected / {}, / KBT payload / << { / aud / 3 : "https://verifier.example/app", / iat / 6 : 1725244237, / 2024-09-02T02:30:37+00:00Z / / cnonce / 39 : h'8c0f5f523b95bea44a9a48c649240803' } >>, / end of KBT payload / / KBT signature / h'dd49379434b25b03cd8756787ab49731 580a04505439ca78ee53300dd49a00b7 0e8715d015a2a6e8d88455f5850e3d93 eade1366c0040c2cee1cc568322a6b93' ]) / end of kbt / ]]>

Nested Example Instead of the structure from the previous example, imagine that the payload contains an inspection history log with the following structure. It could be blinded at multiple levels of the claims set hierarchy. For example, looking at the nested disclosures below, the first disclosure unblinds the entire January 2023 inspection record. However, when the record is disclosed, the inspector license number and inspection location are redacted inside the record. The next disclosure unblinds the inspector_license_number, and the next disclosure unblinds the inspection location record, but the region and postcode claims inside the location record are also individually blinded. The fourth disclosure unblinds the inspection region. The fifth disclosure unblinds the earliest inspection record, and the last disclosure unblinds the inspector_license_number for that record. Verifiers start unblinding claims for which they have blinded claim hashes. They continue descending until there are no blinded claim hashes at any level of the hierarchy for which they have a corresponding disclosure. >, <<[ /salt/ h'bae611067bb823486797da1ebbb52f83', /value/ "ABCD-123456", /claim/ 501 / inspector_license_number / ]>>, <<[ /salt/ h'd5c7494eb16a8ff11fba507cbc7c816b', /value/ { 1: "us", simple(59): [ h'3bf93977377099c66997303ddbce67b4 ca7ee95d2c8cf2b8b45f451362493460', h'231e125d192de099e91bc59e2ae914f0 c891cbc3329b7fea70a3aa636c87a0a4' ] }, /claim/ 503 / San Francisco location / ]>>, <<[ /salt/ h'52da9de5dc61b33775f9348b991d3d78', /value/ "ca", /claim/ 2 / region=California / ]>>, <<[ /salt/ h'9adcf14141f8607a44a130a4b341e162', /value/ { 500: true, 502: 1549560720, simple(59): [ h'94d61c995d4fa25ad4d3cc4752f6ffaf 9e67f7f0b4836c8252a9ad23c20499f5', h'4ff0ecad5f767923582febd69714f3f8 0cb00f58390a0825bc402febfa3548bf' ] } / inspection 7-Feb-2019 / ]>>, <<[ /salt/ h'591eb2081b05be2dcbb6f8459cc0fe51', /value/ "DCBA-101777", /claim/ 501 / inspector_license_number / ]>>, <<[ /salt/ h'95b006410a1b6908997eed7d2a10f958', /value/ { 1: "us", simple(59): [ h'2bc86e391ec9b663de195ae9680bf614 21666bc9073b1ebaf80c77be3adb379f', h'e11c93b44fb150a73212edec5bde46d3 d7db23d0d43bfd6a465f82ee8cf72503' ] }, /claim/ 503 / Denver location / ]>>, ] ]]> After applying the disclosures of the nested structure above, the disclosed Claims Set visible to the Verifier would look like the following:

To Be Redacted Tag Definition In order to indicate specific claims that should be redacted in a Claim Set, this specification defines a new CBOR tag "To be redacted". It can be used by a library to automatically convert a Claim Set with "To be redacted" tags into a) a new Claim Set containing Redacted Claim Keys and Redacted Claim Elements replacing the tagged claim keys or claim elements, and b) a set of corresponding Salted Disclosed Claims.

Privacy Considerations This section describes the privacy considerations in accordance with the recommendations from . Many of the topics discussed in apply to SD-CWT, but are not repeated here.

Correlation Presentations of the same SD-CWT to multiple Verifiers can be correlated by matching on the signature component of the COSE_Sign1. Signature based linkability can be mitigated by leveraging batch issuance of single-use tokens, at a credential management complexity cost. Any Claim Value that pertains to a sufficiently small set of subjects can be used to facilitate tracking the subject. For example, a high precision issuance time might match the issuance of only a few credentials for a given Issuer, and as such, any presentation of a credential issued at that time can be determined to be associated with the set of credentials issued at that time, for those subjects.

Determinism It is possible to encode additional information through the choices made during the serialization stage of producing an SD-CWT, for example, by adjusting the order of CBOR map keys, or by choosing different numeric encodings for certain data elements. provides guidance for constructing application profiles that constrain serialization optionality beyond CBOR Common Deterministic Encoding rulesets (CDE). The construction of such profiles has a significant impact on the privacy properties of a credential type.

Audience If the audience claim is present in both the SD-CWT and the SD-KBT, they are not required to be the same. SD-CWTs with audience claims that do not correspond to the intended recipients MUST be rejected, to protect against accidental disclosure of sensitive data.

Credential Types The privacy implications of selective disclosure vary significantly across different credential types due to their inherent characteristics and intended use cases. The mandatory and optional-to-disclose data elements in an SD-CWT must be carefully chosen based on the specific privacy risks associated with each credential type. For example, a passport credential contains highly sensitive personal information where even partial disclosure can have significant privacy implications: - Revealing citizenship status may expose an individual to discrimination - Date of birth combined with any other attribute enables age-based profiling - Biometric data, even if selectively disclosed, presents irreversible privacy risks - The mere possession of a passport from certain countries can be sensitive information In contrast, a legal entity certificate has fundamentally different privacy considerations: - The entity's legal name and registration number are often public information - Business addresses and contact details may already be in public registries - Authorized signatories' names might be required for legal validity - The primary concern is often business confidentiality rather than personal privacy These differences mean that: - Passport credentials should minimize mandatory disclosures and maximize holder control over optional elements - Legal entity certificates might reasonably require disclosure of more fields to establish business legitimacy - The granularity of selective disclosure should match the credential type's privacy sensitivity - Default disclosure sets must be carefully calibrated to each credential's risk profile Several distinct credential types might be applicable to a given use case, each with unique privacy trade-offs. Issuers MUST perform a comprehensive privacy and confidentiality assessment for each credential type they intend to issue, considering: - The sensitivity spectrum of contained attributes - Likely disclosure scenarios and their privacy impacts - Correlation risks when attributes are combined - Long-term privacy implications of disclosed information - Cultural and jurisdictional privacy expectations

Security Considerations Security considerations from COSE and CWT apply to this specification.

Issuer Key Compromise Verification of an SD-CWT requires that the Verifier have access to a verification key (public key) associated with the Issuer. Compromise of the Issuer's signing key would enable an attacker to forge credentials for any subject, potentially undermining the entire trust model of the credential system. Beyond key compromise, attacks targeting the provisioning and binding between issuer names and their cryptographic key material pose significant risks. An attacker who can manipulate these bindings could substitute their own keys for legitimate issuer keys, enabling credential forgery while appearing to be a trusted issuer. Certificate transparency, as described in , or key transparency, as described in , can help detect and prevent such attacks by: - Enabling public observation of all issued certificates or key bindings - Detecting unauthorized or fraudulent bindings between verification keys and Issuer identifiers - Providing cryptographic proof of inclusion for legitimate keys - Creating an append-only audit trail that makes key substitution attacks discoverable Verifiers SHOULD leverage transparency mechanisms where available to validate that the issuer's keys have not been compromised or fraudulently substituted.

Disclosure Coercion and Over-identification The Security Considerations from apply, with additional attention to disclosure coercion risks. Holders face risks of being coerced into disclosing more claims than necessary. This threat warrants special attention because:

1. Verifier Trust: Holders MUST be able to verify that a Verifier will handle disclosed claims appropriately and only for stated purposes.
2. Elevated Risk: Claims from trusted authorities (e.g., government-issued credentials) carry higher misuse potential due to their inherent legitimacy.
3. Irreversibility: Disclosed claims cannot be withdrawn. This permanent exposure risk MUST be considered in any disclosure decision.

Mitigation Measures: 1. Verifiers SHOULD demonstrate eligibility to receive claims 2. Holders MUST conduct risk assessments when Verifier eligibility cannot be established 3. Trust lists maintained by trusted parties can help identify authorized Verifiers Without proper safeguards (such as Verifier trust lists), Holders remain vulnerable to over-identification and long-term misuse of their disclosed information.

Threat Model Development Guidance This section provides guidance for developing threat models when applying SD-CWT to specific use cases. It is NOT a threat model itself, but rather a framework to help implementers create appropriate threat models for their particular contexts. Each use case will have unique security characteristics that MUST be analyzed before determining the applicability of SD-CWT-based credential types. The following non-exhaustive list of questions and considerations should guide the development of a use-case-specific threat model:

1. Has there been a t-closeness, k-anonymity, and l-diversity assessment (see ) assuming compromise of the one or more Issuers, Verifiers or Holders, for all relevant credential types?
2. Issuer questions:
   1. How many Issuers exist for the credential type?
   2. Is the size of the set of Issuers growing or shrinking over time?
   3. For a given credential type, will subjects be able to hold instances of the same credential type from multiple Issuers, or just a single Issuer?
   4. Does the credential type require or offer the ability to disclose a globally unique identifier?
   5. Does the credential type require high precision time or other claims that have sufficient entropy such that they can serve as a unique fingerprint for a specific subject?
   6. Does the credential type contain Personally Identifiable Information (PII), or other sensitive information that might have value in a market?
3. Holder questions:
   1. What steps has the Holder taken to improve their operation security regarding presenting credentials to verifiers?
   2. How can the Holder be convinced the Verifier that received presentations is legitimate?
   3. How can the Holder be convinced the Verifier will not share, sell, leak, or otherwise disclose the Holder's presentations or Issuer or Holder signed material?
   4. What steps has the Holder taken to understand and confirm the consequences resulting from their support for the aggregate-use of digital credential presentations?
4. Verifier questions:
   1. How many Verifiers exist for the credential type?
   2. Is the size of the set of Verifiers growing or shrinking over time?
   3. Are the Verifiers a superset, subset, or disjoint set of the Issuers or subjects?
   4. Are there any legally required reporting or disclosure requirements associated with the Verifiers?
   5. Is there reason to believe that a Verifier's historic data will be aggregated and analyzed?
   6. Assuming multiple Verifiers are simultaneously compromised, what knowledge regarding subjects can be inferred from analyzing the resulting dataset?
5. Subject questions:
   1. How many subjects exist for the credential type?
   2. Is the size of the set of subjects growing or shrinking over time?
   3. Does the credential type require specific hardware, or algorithms that limit the set of possible subjects to owners of specific devices or subscribers to specific services?

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.

Binding the KBT and the CWT The "iss" claim in the SD-CWT is self-asserted by the Issuer. Because confirmation is mandatory, the subject claim of an SD-CWT, when present, is always related directly to the confirmation claim. There might be many subject claims and many confirmation keys that identify the same entity or that are controlled by the same entity, while the identifiers and keys are distinct values. Reusing an identifier or key enables correlation, but MUST be evaluated in terms of the confidential and privacy constraints associated with the credential type. Conceptually, the Holder is both the Issuer and the subject of the SD-KBT, even if the "iss" or "sub" claims are not present. If they are present, they are self-asserted by the Holder. All three are represented by the confirmation (public) key in the SD-CWT. As with any self-assigned identifiers, Verifiers need to take care to verify that the SD-KBT "iss" and "sub" claims match the subject in the SD-KBT, and are a valid representation of the Holder and correspond to the Holder's confirmation key. Extra care should be taken in case the SD-CWT subject claim is redacted. Likewise, Holders and Verifiers MUST verify that the "iss" claim of the SD-CWT corresponds to the Issuer and the key described in the protected header of the SD-CWT.

Covert Channels Any data element that is supplied by the Issuer, and that appears random to the Holder might be used to produce a covert channel between the Issuer and the Verifier. The ordering of claims, and precision of timestamps can also be used to produce a covert channel. This is more of a concern for SD-CWT than typical CWTs, because the Holder is usually considered to be aware of the Issuer claims they are disclosing to a Verifier.

Nested Disclosure Ordering The Holder has flexibility in determining the order of nested disclosures when making presentations. The order can be sorted, randomized, or optimized for performance based on the Holder's needs. This ordering choice has no security impact on encrypted disclosures. However, the order can affect the runtime of the verification process.

Choice of AEAD algorithms The AEAD encrypted disclosures mechanism discussed in can refer to any AEAD alogithm in the IANA AEAD Algorithms registry . When choosing an AEAD algorithm, the tag length is critical for the integrity of encrypted disclosures in SD-CWT. As such, implementations MUST NOT use any AEAD algorithm with a tag length less than 16 octets. Algorithms using AES-CCM are NOT RECOMMENDED. As of this writing, implementations MUST NOT use algorithms 3 through 14, 18, 19, 21, 22, 24, 25, 27, or 28. Implementations using the AEGIS algorithms containing an X MUST only use the 256-bit tag variant.

IANA Considerations

COSE Header Parameters IANA is requested to add the following entries to the IANA "COSE Header Parameters" registry:

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: of this specification

sd_alg The following completed registration template per RFC8152 is provided:

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

sd_aead_encrypted_claims The following completed registration template per RFC8152 is provided:

• Name: sd_aead_encrypted_claims
• Label: TBD6 (requested assignment 19)
• Value Type: bstr
• Value Registry: (empty)
• Description: A list of AEAD encrypted selectively disclosed claims, which were originally redacted, then later disclosed at the discretion of the sender.
• Reference: of this specification

sd_aead The following completed registration template per RFC8152 is provided:

• Name: sd_aead
• Label: TBD7 (requested assignment 20)
• Value Type: int
• Value Registry: IANA AEAD Algorithm number
• Description: The AEAD algorithm used for encrypting disclosures.
• Reference: of this specification

CBOR Simple Values IANA is requested to add the following entry to the IANA "CBOR Simple Values" registry:

• Value: TBD4 (requested assignment 59)
• Semantics: This value as a map key indicates that the Claim Value is an array of redacted Claim Keys at the same level as the map key.
• Specification Document(s): of this specification

CBOR Tags IANA is requested to add the following entries to the IANA "CBOR Tags" registry:

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): of this specification

Redacted Claim Element Tag The byte 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): of this specification

CBOR Web Token (CWT) Claims IANA is requested to add the following entry to the IANA "CWT Claims" registry:

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): of this specification

Media Types IANA is requested to add the following entries to the IANA "Media Types" registry (https://www.iana.org/assignments/media-types/media-types.xhtml#application):

application/sd-cwt 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: of this specification and
• Interoperability considerations: n/a
• Published specification: of this specification
• 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: SPICE WG mailing list (spice@ietf.org) or IETF Security Area (saag@ietf.org)
• Intended usage: COMMON
• Restrictions on usage: none
• Author: See Author's Addresses section
• Change controller: IETF
• Provisional registration? No

application/kb+cwt 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: of this specification and
• Interoperability considerations: n/a
• Published specification: of this specification
• 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: SPICE WG mailing list (spice@ietf.org) or IETF Security Area (saag@ietf.org)
• Intended usage: COMMON
• Restrictions on usage: none
• Author: See Author's Addresses section
• Change controller: IETF
• Provisional registration? No

Structured Syntax Suffix IANA is requested to add the following entry to the IANA "Structured Syntax Suffix" registry:

• Name: SD-CWT
• +suffix: +sd-cwt
• References: of this specification
• Encoding considerations: binary
• Interoperability considerations: n/a
• Fragment identifier considerations: n/a
• Security considerations: of this specification
• Contact: See Author's Addresses section
• Author/Change controller: IETF

Content-Formats IANA is requested to register the following entries in the IANA "CoAP Content-Formats" registry: New CoAP Content Formats

Content-Type	Content Coding	ID	Reference
application/sd-cwt	-	TBD11	of this specification
application/kb+cwt	-	TBD12	of this specification

If possible, TBD11 and TBD12 should be assigned in the 256..9999 range.

Verifiable Credential Type Identifiers This specification establishes the Verifiable Credential Type Identifiers registry, under the IANA "CBOR Web Token (CWT) Claims" group registry heading. It registers identifiers for the type of the SD-CWT Claims Set. It enables short integers in the range 0-65535 to be used as vct Claim Values, similarly to how CoAP Content-Formats () enable short integers to be used as typ header parameter values. The registration procedures for numbers in specific ranges are as described below:

Range	Registration Procedure
0-9999	Specification Required
10000-64999	First Come First Served
65000-65535	Experimental Use (no operational use)

Values in the Specification Required range are registered after a two-week review period on the spice-ext-review@ietf.org mailing list, on the advice of one or more Designated Experts. To allow for the allocation of values prior to publication of the final version of a specification, the Designated Experts may approve registration once they are satisfied that the specification will be completed and published. However, if the specification is not completed and published in a timely manner, as determined by the Designated Experts, the Designated Experts may request that IANA withdraw the registration. Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register VCT value"). Within the review period, the Designated Experts will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. The IANA escalation process is followed when the Designated Experts are not responsive within 14 days. Criteria that should be applied by the Designated Experts includes determining whether the proposed registration duplicates existing functionality, determining whether it is likely to be of general applicability or whether it is useful only for a single application, and whether the registration makes sense. IANA must only accept registry updates from the Designated Experts and should direct all requests for registration in the Specification Required range to the review mailing list. It is suggested that multiple Designated Experts be appointed who are able to represent the perspectives of different applications using this specification, in order to enable broadly-informed review of registration decisions. In cases where a registration decision could be perceived as creating a conflict of interest for a particular Expert, that Expert should defer to the judgment of the other Experts.

Registration Template

Verifiable Credential Type Identifier String:

String identifier for use as a JWT vct or CWT vct Claim Value. It is a StringOrURI value.

Verifiable Credential Type Identifier Number:

Integer in the range 0-64999 for use as a CWT vct Claim Value. (Integers in the range 65000-65535 are not to be registered.)

Description:

Brief description of the verifiable credential type

Change Controller:

For IETF stream RFCs, use "IETF". For others, give the name of the responsible party. Other details (e.g., postal address, e-mail address, home page URI) may also be included.

Specification Document(s):

Reference to the document or documents that specify the values to be registered, preferably including URLs that can be used to retrieve the documents. An indication of the relevant sections may also be included, but is not required.

Initial Registry Contents No initial values are provided for the registry.

References Normative References 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. 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. 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. 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. Universität Bremen TZI This document formalizes and consolidates the definition of the Extended Diagnostic Notation (EDN) of the Concise Binary Object Representation (CBOR), addressing implementer experience. Replacing EDN's previous informal descriptions, it updates RFC 8949, obsoleting its Section 8, and RFC 8610, obsoleting its Appendix G. It also specifies and uses registry-based extension points, using one to support text representations of epoch-based dates/times and of IP addresses and prefixes. // (This cref will be removed by the RFC editor:) The present -19 // includes the definition of the cri'' application- extension. cri'' // was previously defined in draft-ietf-core-href; however the latter // document overtook the present document in the approval process. // As the definition of cri'' is dependent on the present document // (and conversely has essentially no dependency on the technical // content of draft-ietf-core-href beyond its mere existence), the // text (including IANA considerations) has been moved here. -19 is // intended for use at the CBOR WG meeting at IETF 124. 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). This specification defines a method for computing a hash value over a CBOR Object Signing and Encryption (COSE) Key. It specifies which fields within the COSE Key structure are included in the cryptographic hash computation, the process for creating a canonical representation of these fields, and how to hash the resulting byte sequence. The resulting hash value, referred to as a "thumbprint", can be used to identify or select the corresponding key. This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDS-TRACK] 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. Informative References Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. Authlete Keio University Ping Identity This specification defines a mechanism for the selective disclosure of individual elements of a JSON 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. Universität Bremen TZI CBOR (STD 94, RFC 8949) defines the concept of "Deterministically Encoded CBOR" in its Section 4.2, determining one specific way to encode each particular CBOR value. This definition is instantiated by "core requirements", providing some flexibility for application specific decisions; this makes it harder than necessary to offer Deterministic Encoding as a selectable feature of generic CBOR encoders. The present specification documents the Best Current Practice for CBOR _Common Deterministic Encoding_ (CDE), which can be shared by a large set of applications with potentially diverging detailed application requirements. The document also discusses the desire for partial implementations, which can be another reason for constraining CBOR encoders, and singles out the encoding constraint "definite-length-only" as a likely constraint to be used in application protocol and media type definitions. This specification updates RFC 8949 in that it provides clarifications and definitions of additional terms as well as more examples and explanatory text; it does not make technical changes to RFC 8949. // This revision -13 merges all active pull requests in preparation // for the 2025-cbor-17 interim on 2025-10-15. This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. While there are several established protocols for end-to-end encryption, relatively little attention has been given to securely distributing the end-user public keys for such encryption. As a result, these protocols are often still vulnerable to eavesdropping by active attackers. Key Transparency is a protocol for distributing sensitive cryptographic information, such as public keys, in a way that reliably either prevents interference or detects that it occurred in a timely manner. 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. The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols.

Complete CDDL Schema

A complete CDDL description of SD-CWT "application/sd-cwt" / TBD11, &(alg: 1) ^ => int, ? &(kid: 4) ^ => bstr, ? &(sd_alg: TBD2) ^ => int, ; -16 for sha-256 ? &(sd_aead: TBD7) ^ => uint .size 2, * key => any } kbt-protected = { &(typ: 16) ^ => "application/kb+cwt" / TBD12, &(alg: 1) ^ => int, &(kcwt: 13) ^ => sd-cwt-issued, * key => any } sd-unprotected = { ? &(sd_claims: TBD1) ^ => salted-array, ? &(sd_aead_encrypted_claims: TBD6) ^ => aead-encrypted-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/app" ? &(exp: 4) ^ => num, ; 1883000000 ? &(nbf: 5) ^ => num, ; 1683000000 ? &(iat: 6) ^ => num, ; 1683000000 ? &(cti: 7) ^ => bstr, &(cnf: 8) ^ => { * key => any }, ; key confirmation ? &(cnonce: 39) ^ => bstr, ; ? &(redacted_claim_keys: REDACTED_KEYS) ^ => [ * bstr ], * key => any } kbt-payload = { &(aud: 3) ^ => tstr, ; "https://verifier.example/app" ? &(exp: 4) ^ => num, ; 1883000000 ? &(nbf: 5) ^ => num, ; 1683000000 &(iat: 6) ^ => num, ; 1683000000 ? &(cnonce: 39) ^ => bstr, * key => any } salted-array = [ *bstr-encoded-salted ] bstr-encoded-salted = bstr .cbor salted-entry salted-entry = salted-claim / salted-element / decoy salted-claim = [ bstr .size 16, ; 128-bit salt any, ; claim value (int / text) ; claim name ] salted-element = [ bstr .size 16, ; 128-bit salt any ; claim value ] decoy = [ bstr .size 16 ; 128-bit salt ] aead-encrypted-array = [ *aead-encrypted ] aead-encrypted = [ bstr .size 16, ; 128-bit nonce bstr, ; the encryption ciphertext output of a ; bstr-encoded-salted bstr ; the corresponding authentication tag ] num = int / float key = int / text TBD1 = 17 TBD2 = 18 TBD6 = 19 TBD7 = 20 ;TBD3 = 58; CBOR tag wrapping to-be-redacted keys or elements TBD11 = 298 TBD12 = 299 ; REDACTED_KEYS is to be used in CDDL payloads that are meant to ; convey that a map key is redacted. REDACTED_KEYS = #7.59 ; #7. ;TBD4 = 59 ; for CBOR simple value 59 ; redacted_claim_element is to be used in CDDL payloads that contain ; array elements that are meant to be redacted. ;redacted_claim_element = #6.60( bstr .size 16 ) ; #6.(bstr) ;TBD5 = 60; CBOR tag wrapping redacted_claim_element ]]>

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

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

Redaction Claims The COSE equivalent of _sd is a CBOR Simple Value (requested assignment 59). The following 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. In SD-CWT, the order of the fields in a disclosure is salt, value, key. In SD-JWT the order of fields in a disclosure is salt, key, value. This choice ensures that the second element in the CBOR array is always the value, which makes parsing faster and more efficient in strongly-typed programming languages.

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 COSE key pair in EDN format The fields necessary for the COSE Key Thumbprint in EDN format: The same map in CBOR pretty printing The COSE thumbprint (in hexadecimal)--SHA256 hash of the thumbprint fields: 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 Holder private key in PEM format

Issuer Issuer COSE key pair in Extended Diagnostic Notation (EDN) The fields necessary for the COSE Key Thumbprint in EDN format: The same map in CBOR pretty printing The COSE thumbprint (in hexadecimal)--SHA256 hash of the thumbprint fields: 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

Implementation Status Note to the 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 made 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 specification. Maturity: Prototype Coverage: The current version ('main') implements functionality similar to that described in this specification, 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 a proof of concept, but is not yet production ready. Contact: Orie Steele (orie.steele@tradeverifyd.com)

Rust Prototype Organization: SimpleLogin Name: github.com/beltram/esdicawt Description: An open-source Rust implementation of this specification in Rust. Maturity: Prototype Coverage: The current version is close to the spec with the exception of redacted_claim_keys using a CBOR SimpleValue as label instead of a tagged key. Not all of the verifications have been implemented yet. License: Apache-2.0 Implementation Experience: No interop testing has been done yet. The code works as a proof of concept, but is not yet production ready. Contact: Beltram Maldant (beltram.ietf.spice@pm.me)

Relationship between RATS Architecture and Verifiable Credentials This appendix describes the relationship between the Remote ATtestation procedureS (RATS) architecture defined in and the three-party model used in verifiable credentials.

Three-Party Verifiable Credentials Model The verifiable credentials model involves three distinct parties:

• Issuer: Creates and signs credentials containing claims about a subject
• Holder: Controls the credential and presents it to verifiers (the holder is typically the subject of the credential)
• Verifier: Receives and validates presented credentials to make authorization or access decisions. In this appendix we refer to this role as a Credential Verifier

In SD-CWT, these roles are explicitly represented: the Issuer signs claims using an Assertion Key (), the Holder controls the credential and creates presentations using a Confirmation Key, and the Verifier validates both the Issuer's signature over the credential and the Holder's signature over the presentation (key binding token).

RATS Architecture Roles The RATS architecture defines the following key roles:

• Attester: Produces Evidence about its own trustworthiness and operational state
• Endorser: Provides Endorsements about an Attester (typically a manufacturer)
• Reference Value Provider: Supplies Reference Values used by Verifiers to evaluate Evidence
• Verifier: Appraises Evidence and produces Attestation Results. In this appendix we refer to this role as a RATS Verifier
• Relying Party: Consumes Attestation Results to make authorization decisions

Role Mappings in the Three-Party Model The mapping between RATS roles and verifiable credential roles can be understood as follows:

Verifiable Credential Issuer as RATS Endorser A verifiable credential Issuer functions as a RATS Endorser. The Endorser role in RATS produces Endorsements - secure statements about an Attester's capabilities, identity, or trustworthiness. Similarly, a credential Issuer produces signed credentials containing claims about a subject (the Holder). Both roles:

• Make authoritative statements about another party's attributes or capabilities
• Use cryptographic signatures to ensure integrity and authenticity
• Are typically trusted third parties in their respective ecosystems
• Provide information that enables downstream authorization decisions

The credential issued by the Issuer serves the same function as an Endorsement in RATS: it is a signed assertion about the Holder's attributes that can be used by Credential Verifiers to make trust decisions.

Verifiable Credential Holder as RATS Verifier A verifiable credential Holder functions as a RATS Verifier. The RATS Verifier appraises Evidence and Endorsements and produces Attestation Results. In the credentials model, the Holder:

• Receives credentials (analogous to Endorsements) from Issuers
• Evaluates which credentials to present and which claims to disclose
• Produces presentations (analogous to Attestation Results) that are sent to Credential Verifiers
• Uses their Confirmation Key to create key binding tokens that prove control

The Holder's presentation, which includes the Issuer's credential plus the Holder's signature over selected disclosures, functions as an Attestation Result - a processed, signed assertion derived from the original credential (Endorsement).

Verifiable Credential Verifier as RATS Relying Party A verifiable credential Credential Verifier functions as a RATS Relying Party. The Relying Party:

• Consumes Attestation Results (credential presentations) to make authorization decisions
• Validates the cryptographic integrity of received assertions
• Makes access control or authorization decisions based on the claims received
• Does not directly interact with the original Endorsement source (the Issuer)

The Credential Verifier appraises the Holder's presentation in the same way a Relying Party appraises Attestation Results from a RATS Verifier.

All Parties Can Be Attesters Importantly, any of these parties - Issuer, Holder, or Credential Verifier - can simultaneously function as a RATS Attester. The Attester role in RATS is about producing Evidence about one's own trustworthiness:

• An Issuer may be an Attester when it needs to prove its own integrity, platform state, or authorization to issue certain credential types. For example, an Issuer might provide Evidence about its secure enclave or certified infrastructure when establishing trust with Holders or during credential issuance.
• A Holder may be an Attester when presenting credentials, particularly when the presentation itself requires proof of the Holder's platform integrity. For example, a Holder might provide Evidence about their device's secure boot state, firmware version, or trusted execution environment alongside their credential presentation.
• A Credential Verifier may be an Attester when it needs to prove its own trustworthiness to Holders or to upstream systems. For example, a Credential Verifier might provide Evidence about its data protection capabilities, compliance certifications, or secure processing environment before Holders agree to disclose sensitive claims.

The Attester role is orthogonal to the three primary roles - it represents the ability to produce evidence about one's own state, while the Issuer/Holder/Credential Verifier roles represent the flow of credentials and claims about subjects.

Comparison with RATS Interaction Models RATS defines two interaction models: Passport Model: The Attester sends Evidence to a RATS Verifier, receives Attestation Results, and presents these results to Relying Parties. This maps to the three-party credentials model where the Holder obtains credentials from Issuers and presents them to Credential Verifiers. Background-Check Model: The Attester sends Evidence to a Relying Party, which forwards it to a RATS Verifier. The RATS Verifier returns results directly to the Relying Party. This is a two-party model from the Attester's perspective and does not map well to the three-party credentials model, as it lacks Holder mediation and control over presentations.

Roles That Don't Map to the Three-Party Model The Reference Value Provider role from RATS does not have a direct equivalent in the three-party verifiable credentials model. This role supplies reference values (known-good measurements or configurations) that RATS Verifiers use to appraise Endorsements and Evidence. In credentials systems, equivalent functionality might be provided through:

• Trust registries that list authorized Issuers
• Schema registries, or lists of valid claims that define credential formats
• Governance frameworks that specify validation rules
• Revocation registries

However, these are typically considered part of the trust infrastructure rather than a distinct party in the presentation protocol. The Reference Value Provider role is primarily relevant in scenarios where raw Evidence must be evaluated against known-good values - a pattern more common in the two-party background-check model than in the three-party credentials model where Issuers have already performed evaluation and produced credentials.

Application to SD-CWT When applying RATS concepts to SD-CWT:

• SD-CWT credentials function as Endorsements about the Holder (subject)
• The Holder's key binding token and selective disclosure act as the RATS Verifier's appraisal and production of Attestation Results
• The Credential Verifier consumes these presentations as a Relying Party consumes Attestation Results
• Any party can additionally provide Evidence about their own platform or operational state (act as an Attester)
• The three-party model with selective disclosure maps naturally to the RATS passport model
• Reference Value Provider functionality is addressed through trust infrastructure and out-of-band mechanisms rather than protocol-level roles

Sample Disclosure Matching Algorithm for Verifier The Verifier of an SD-CWT needs to decode disclosed claims match them with their redacted versions. The following example algorithm describes a way to accomplish this.

1. The decoded sd_claims are converted to an intermediate data structure called a Digest To Disclosed Claim Map that is used to transform the Presented Disclosed Claims Set into a Validated Disclosed Claims Set.
2. 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 Claims Set.

• One possible concrete representation of the intermediate data structure for the Digest To Disclosed Claim Map is a CBOR map with the hash of the bstr-encoded-salted data structure (from the CDDL) as the map key and its value as the contents of the corresponding salted-entry data structure.

3. The Verifier constructs an empty CBOR map called the Validated Disclosed Claims Set, and initializes it with all mandatory to disclose claims from the verified Presented Disclosed Claims Set.
4. Next, the Verifier performs a depth-first traversal of the Presented Disclosed Claims Set and Validated Disclosed Claims Set, using the Digest To Disclosed Claim Map to insert claims into the Validated Disclosed Claims Set when they appear in the Presented Disclosed Claims Set.
5. The Verifier repeats the fourth step if the previous iteration resulted in any new Presented Disclosed Claims.
6. If there remain unused claims in the Digest To Disclosed Claim Map at the end of this procedure the SD-CWT MUST be considered invalid. Likewise, if this algorithm results in any duplicate CBOR map keys, the entire SD-CWT MUST be considered invalid.

• Note: If there are remaining digests without corresponding disclosures, this means that either the holder intentionally did not disclose a claim, or that the digest is a decoy digest .

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

draft-ietf-spice-sd-cwt-05

• Added this change log (PR#150)
• Moved non-normative validation algorithm to an appendix (PR#149)
• Added appendix describing mapping to RATS concepts (#147)
• Provided guidance on choice of AEAD algorithm (#148)
• Fixed algorithm in COSE key examples (#145)
• Updated contact information (PR#142, PR #150)
• Removed SPICE from the title of the document (PR#139)
• Made clear extent to which verifiers cannot process unknown claims (PR#138)
• Sorted CBOR map keys in examples to facilitate use as test vectors (PR#135)
• Consistently use term "tag" in context of AEAD algorithms (PR#134)
• Improved AASVG diagram in Terminology section (PR#129)

draft-ietf-spice-sd-cwt-04

• Place value before claim name in disclosures
• Use CBOR simple value 59 for the redacted_key_claims
• Greatly improved text around AEAD encrypted disclosures
• Applied clarifications and corrections suggested by Mike Jones.
• Do not update CWT .
• Use application/sd-cwt media type and define +sd-cwt structured suffix.
• Made SHA-256 be the default sd_alg value.
• Created Verifiable Credential Type Identifiers registry.
• Corrected places where Claim Name was used when what was meant was Claim Key.
• Defined the To Be Redacted CBOR tag
• In the SD-KBT, iss and sub are now forbidden
• Clarified text about aud
• Described Trust Lists
• EDN Examples are now in deterministic order
• Expressed some validation steps as a list
• Clarified handling of nested claims
• Fixed the handling of the to be registered items in the CDDL; made CDDL self consistent
• Fixed some references

draft-ietf-spice-sd-cwt-03

• remove bstr encoding from sd_claims array (but not the individual disclosures)
• clarify which claims are optional/mandatory
• correct that an SD-CWT may have zero redacted claims
• improve the walkthrough of computing a disclosure
• clarify that duplicate map keys are not allowed, and how tagged keys are represented.
• added security considerations section (#42) and text about privacy and linkability risks (#43)
• register SD-CWT and SD-KBT as content formats in CoAP registry (#39)
• updated media types registrations to have more useful contacts (#44)
• build most of the values (signatures/salts/hashes/dates) in the examples automatically using a script that implements SD-CWT
• regenerate all examples with correct signatures
• add nested example
• add optional encrypted disclosures

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
• Rewritten the main normative section
• Made redacted_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 B. Jones. The authors would like to thank the following individuals for their contributions to this specification: Michael B. Jones.

Contributors Self-Issued Consulting

United States michael_b_jones@hotmail.com https://self-issued.info/