SPICE SD-CWT

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 7 June 2025.¶

Copyright Notice

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

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

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document uses terms from CWT [RFC8392], and COSE [RFC9052] [RFC9053].¶

The terms Claim Name, Claim Key and Claim Value are defined in [RFC8392].¶

This document defines the following new terms:¶

Selective Disclosure CBOR Web Token (SD-CWT):

A CWT with claims enabling selective disclosure with key binding.¶

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

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

Issuer:

An entity that produces a Selective Disclosure CBOR Web Token.¶

Holder:

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

Verifier:

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

Partial Disclosure:

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

Full Disclosure:

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

Salted Disclosed Claim:

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

Digested Salted Disclosed Claim / Blinded Claim Hash:

A hash digest of a Salted Disclosed Claim.¶

Blinded Claim:

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

Redacted Claim Key:

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

Redacted Claim Element:

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

Presented Disclosed Claims Set:

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

Validated Disclosed Claims Set:

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

3. Overview of Selective Disclosure CWT

{
    / iss / 1  : "https://issuer.example",
    / sub / 2  : "WRQ2RbY5RYJCIxfDQL9agl9fFSCYVu4Xocqb6zerc1M",
    / exp / 4  : 1725330600, /2024-09-02T19:30:00Z/
    / nbf / 5  : 1725243840, /2024-09-01T19:25:00Z/
    / iat / 6  : 1725244200, /2024-09-01T19:30:00Z/
    / cnf / 8  : {
      / cose key / 1 : {
        / alg: ES256 /  3: -7,
        / kty: EC2   /  1: 2,
        / crv: P-256 / -1: 1,
        / x / -2: b64'hVTrJ13Nb70cesZBqiyQ2SAi_Q0wJLWvGMfMYa1Sei0',
        / y / -3: b64'TceuLGd-ltDMgll2Vc6S1VA_VCk9h4ddHnnOR3AZQ0M'
      }
    },
    /most_recent_inspection_passed/ 500: true,
    /inspector_license_number/ 501: "ABCD-123456",
    /inspection_dates/ 502 : [
        1549560720,   / 2019-02-07T17:32:00 /
        1612498440,   / 2021-02-04T20:14:00 /
        1674004740,   / 2023-01-17T17:19:00 /
    ],
    /inspection_location/ 503: {
        "country": "us",            / United States /
        "region": "ca",             / California /
        "postal_code": "94188"
    }
}

/ cose-sign1 / 18([
  / protected / << {
    / alg /    1  : -35, / ES384 /
    / typ /    16 : "application/sd+cwt",
    / kid /    4  : 'https://issuer.example/cwk3.cbor',
    / sd_alg / 18 : -16  / SHA256 /
  } >>,
  / unprotected / {
    / sd_claims / 17 : / these are all the disclosures /
    <<[
        <<[
            /salt/   h'8d5c15fa86265d8ff77a0e92720ca837',
            /claim/  501,  / inspector_license_number /
            /value/  "ABCD-123456"
        ]>>,
        <<[
            /salt/   h'86c84b9c3614ba27073c7e5a475a2a13',
            /value/  1549560720  / inspected 7-Feb-2019 /
        ]>>,
        <<[
            /salt/   h'86c84b9c3614ba27073c7e5a475a2a13',
            /value/  1612498440  / inspected 4-Feb-2021 /
        ]>>,
        <<[
            /salt/   h'30eef86edeaa197df7bd3d17dd89cd87',
            /claim/  "region",
            /value/  "ca" /California/
        ]>>,
        <<[
            /salt/   h'284538c4a1881fac49b2edc550c1913e',
            /claim/  "postal_code",
            /value/  "94188"
        ]>>
    ]>>
  },
  / payload / << {
    / iss / 1  : "https://issuer.example",
    / sub / 2  : "WRQ2RbY5RYJCIxfDQL9agl9fFSCYVu4Xocqb6zerc1M",
    / exp / 4  : 1725330600, /2024-09-02T19:30:00Z/
    / nbf / 5  : 1725243840, /2024-09-01T19:25:00Z/
    / iat / 6  : 1725244200, /2024-09-01T19:30:00Z/
    / cnf / 8  : {
      / cose key / 1 : {
        / alg: ES256 /  3: -7,
        / kty: EC2   /  1: 2,
        / crv: P-256 / -1: 1,
        / x / -2: h'hVTrJ13Nb70cesZBqiyQ2SAi_Q0wJLWvGMfMYa1Sei0',
        / y / -3: h'TceuLGd-ltDMgll2Vc6S1VA_VCk9h4ddHnnOR3AZQ0M'
      }
    },
    /most_recent_inspection_passed/ 500: true,
    / redacted_claim_keys / 59(0) : [
        / redacted inspector_license_number /
        h'7e6e350907d0ba3aa7ae114f8da5b360' +
        h'601c0bb7995cd40049b98e4f58fb6ec0'
    ],
    /inspection_dates/ 502 : [
        / redacted inspection date 7-Feb-2019 /
        60(h'a0f74264a8c97655c958aff3687f1390' +
           h'ed0ab6f64cd78ba43c3fefee0de7b835')
        / redacted inspection date 4-Feb-2021 /
        60(h'1e7275bcda9bc183079cd4515c5c0282' +
           h'a2a0e9105b660933e2e68f9a3f40974b')
        1674004740,   / 2023-01-17T17:19:00 /
    ],
    / inspection_location / 503 : {
        "country" : "us",            / United States /
        / redacted_claim_keys / 59(0) : [
            / redacted region /
            h'c47e3b047c1cd6d9d1e1e01514bc2ec9' +
            h'ed010ac9ae1c93403ec72572bb1e00e7',
            / redacted postal_code /
            h'0b616e522a05d8d134a834979710120d' +
            h'41ac1522b056d5f9509cf7e850047302'
        ]
    }
  } >>,
  / signature / h'3337af2e66959614' /TODO: fix /
])

<<[
    /salt/   h'8d5c15fa86265d8ff77a0e92720ca837',
    /claim/  501,  / inspector_license_number /
    /value/  "ABCD-123456"
]>>

7e6e350907d0ba3aa7ae114f8da5b360601c0bb7995cd40049b98e4f58fb6ec0

4. Holder prepares an SD-CWT for a Verifier

When the Holder wants to send an SD-CWT and disclose none, some, or all of the redacted values, it makes a list of the values to disclose and puts them in sd_claims in the unprotected header.¶

For example, Alice decides to disclose to a verifier the inspector_license_number claim (ABCD-123456), the region claim (California), and the earliest date element in the inspection_dates array (7-Feb-2019).¶

/ sd_claims / 17 : /just the disclosures chosen by the Holder/
<<[
    <<[
        /salt/   h'8d5c15fa86265d8ff77a0e92720ca837',
        /claim/  501,  / inspector_license_number /
        /value/  "ABCD-123456"
    ]>>,
    <<[
        /salt/   h'86c84b9c3614ba27073c7e5a475a2a13',
        /value/  1549560720  / inspected 7-Feb-2019 /
    ]>>,
    <<[
        /salt/   h'30eef86edeaa197df7bd3d17dd89cd87',
        /claim/  "region",
        /value/  "ca" /California/
    ]>>
]>>

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 [I-D.ietf-httpbis-unprompted-auth].¶

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 [RFC9528]).¶

/ sd_kbt    / 18 : << 18([
  / protected / << {
      / alg /  1 : -7 / ES256 /,
      / typ /  16 : "application/kb+cwt",
      / kcwt / 13 :
        / *** SD-CWT from Issuer goes here       /
        /  with Holder's choice of disclosures   /
        /  in the SD-CWT unprotected header  *** /
        h'0123456789abcdef...0123'
  } >>,
  / unprotected / {},
  / payload / << {
    / cnonce / 39    : h'8c0f5f523b95bea44a9a48c649240803',
    / aud     / 3    : "https://verifier.example/app",
    / iat     / 6    : 1725283443, / 2024-09-02T06:24:03Z /
  } >>,
  / signature / h'1237af2e678945'  / TODO: fix /
]) >>

Together the digests in protected parts of the issued SD-CWT, and the disclosures hashed in unprotected header of the issuer_sd_cwt are used by the Verifier to confirm the disclosed claims. Since the unprotected header of the included SD-CWT is covered by the signature in the SW-KBT, the Verifier has assurance the Holder included the sent list of disclosures.¶

5. Update to the CBOR Web Token Specification

The CBOR Web Token Specification (Section 1.1 of [RFC8392]), uses strings, negative integers, and unsigned integers as map keys. This specification relaxes that requirement, by also allowing CBOR tagged integers and text strings as map keys.¶

Note that holders presenting to a verifier that does not support this specification would need to present a CWT without tagged map keys.¶

Tagged keys are not registered in the CBOR Web Token Claims IANA registry. Instead the tag provides additional information about the tagged claim key and the corresponding (untagged) value. Multiple levels of tags in a key are not permitted.¶

6. SD-CWT definition

SD-CWT is modeled after SD-JWT, with adjustments to align with conventions in CBOR and COSE. An SD-CWT MUST include the protected header parameter typ [RFC9596] with the value "application/sd-cwt" in the SD-CWT.¶

An SD-CWT is a CWT containing the "blinded claim hash" of at least one blinded claim in the CWT payload. Optionally the salted claim values (and often claim names) for the corresponding Blinded Claim Hash are actually disclosed in the sd_claims claim in the unprotected header of the CWT (the disclosures).¶

Any party with a Salted Disclosed Claim can generate its hash, find that hash in the CWT payload, and unblind the content. However a Verifier with the hash cannot reconstruct the corresponding blinded claim without disclosure of the Salted Disclosed Claim.¶

salted = salted-claim / salted-element / decoy
salted-claim = [
  bstr .size 16,     ; 128-bit salt
  (int / text),      ; claim name
  any                ; claim value
]
salted-element = [
  bstr .size 16,     ; 128-bit salt
  any                ; claim value
]
decoy = [
  bstr .size 16,     ; 128-bit salt
]

; a collection of Salted Disclosed Claims
salted-array = [ +bstr .cbor salted ]

redacted_claim_element = #6.60( bstr .size 16 )

7. SD-CWT Issuance

How the Holder communicates to the Issuer to request a CWT or an SD-CWT is out-of-scope of this specification. Likewise, how the Holder determines which claims to blind or to always disclose is a policy matter which is not discussed in this specification. This specification defines the format of an SD-CWT communicated between an Issuer and a Holder in this section, and describes the format of a Key Binding Token containing that SD-CWT communicated between a Holder and a Verifier in Section 8.¶

The protected header MUST contain the sd_alg field identifying the algorithm (from the COSE Algorithms registry) used to hash the Salted Disclosed Claims. The unprotected header MUST contain an sd_claims section with a Salted Disclosed Claim for every blinded claim hash present anywhere in the payload, and any decoys (see Section 10). If there are no disclosures sd_claims is an empty array. The payload MUST also include a key confirmation element (cnf) [RFC8747] for the Holder's public key.¶

sd-cwt-issued = #6.18([
   protected: bstr .cbor sd-protected,
   sd-unprotected,
   payload: bstr .cbor sd-payload,
   signature: bstr
])

sd-protected = {
   &(typ: 16) ^ => "application/sd+cwt",
   &(alg: 1) ^ => int,
   &(sd_alg: 18) ^= int,             ; -16 for sha-256
   * key => any
}

sd-unprotected = {
   ? &(sd_claims: 17) ^ => bstr .cbor salted-array,
   * key => any
}

sd-payload = {
    ; standard claims
      &(iss: 1) ^ => tstr, ; "https://issuer.example"
    ? &(sub: 2) ^ => tstr, ; "https://device.example"
    ? &(aud: 3) ^ => tstr, ; "https://verifier.example/app"
    ? &(exp: 4) ^ => int,  ; 1883000000
    ? &(nbf: 5) ^ => int,  ; 1683000000
    ? &(iat: 6) ^ => int,  ; 1683000000
      &(cnf: 8) ^ => { * key => any }, ; key confirmation
    ? &(cnonce: 39) ^ => bstr,
    ;
    ? &(redacted_keys: #6.59(0)) ^ => [ * bstr ],
    * key => any
}

8. SD-CWT Presentation

When a Holder presents an SD-CWT to a Verifier, it can disclose none, some, or all of its blinded claims. If the Holder wishes to disclose any claims, it includes that subset of its Salted Disclosed Claims in the sd_claims claim of the unprotected header.¶

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

kbt-cwt = #6.18([
   protected: bstr .cbor kbt-protected,
   kbt-unprotected,
   payload: bstr .cbor kbt-payload,
   signature: bstr
])

kbt-protected = {
   &(typ: 16) ^ => "application/kb+cwt",
   &(alg: 1) ^ => int,
   &(kcwt: 13) ^ => bstr .cbor sd-cwt-issued,
   * key => any
}

kbt-unprotected = {
   * key => any
}

kbt-payload = {
      &(aud: 3) ^ => tstr, ; "https://verifier.example"
    ? &(exp: 4) ^ => int,  ; 1883000000
    ? &(nbf: 5) ^ => int,  ; 1683000000
      &(iat: 6) ^ => int,  ; 1683000000
    ? &(cnonce: 39) ^ => bstr,
    * key => any
}

9. SD-KBT and SD-CWT Verifier Validation

The exact order of the following steps MAY be changed, as long as all checks are performed before deciding if an SD-CWT is valid. First the Verifier must open the protected headers of the SD-KBT and find the issuer SD-CWT present in the kcwt field. Next the Verifier must validate the SD-CWT as described in Section 7.2 of [RFC8392]. The Verifier extract the confirmation key from the cnf claim in the SD-CWT payload. Using the confirmation key, the Verifier validates the SD-KBT as described in Section 7.2 of [RFC8392].¶

Finally, the Verifier MUST extract and decode the disclosed claims from the sd_claims in the unprotected header of the SD-CWT. The decoded sd_claims are converted to an intermediate data structure called a Digest To Disclosed Claim Map which is used to transform the Presented Disclosed Claimset, into a Validated Disclosed Claimset. The Verifier MUST compute the hash of each Salted Disclosed Claim (salted), in order to match each disclosed value to each entry of the Presented Disclosed Claimset.¶

One possible concrete representation of the intermediate data structure for the Digest To Disclosed Claim Map could be:¶

{
  &(digested-salted-disclosed-claim) => salted
}

The Verifier constructs an empty cbor map called the Validated Disclosed Claimset, and initializes it with all mandatory to disclose claims from the verified Presented Disclosed Claimset. Next the Verifier performs a breadth first or depth first traversal of the Presented Disclosed Claimset, Validated Disclosed Claimset, using the Digest To Disclosed Claim Map to insert claims into the Validated Disclosed Claimset when they appear in the Presented Disclosed Claimset. By performing these steps, the recipient can cryptographically verify the integrity of the protected claims and verify they have not been tampered with. If there remain unused Digest To Disclosed Claim Map at the end of this procedure the SD-CWT MUST be considered invalid, as if the signature had failed to verify.¶

Otherwise the SD-CWT is considered valid, and the Validated Disclosed Claimset is now a CWT Claimset with no claims marked for redaction. Further validation logic can be applied to the Validated Disclosed Claimset, as it might normally be applied to a validated CWT claimset.¶

10. Decoy Digests

TODO¶

11. Credential Types

This specification defines the CWT claim vct (for verifiable credential type). The vct value MUST be a case-sensitive StringOrURI (see [RFC7519]) value serving as an identifier for the type of the SD-CWT claimset. The vct value MUST be a Collision-Resistant Name as defined in Section 2 of [RFC7515].¶

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 [I-D.draft-ietf-oauth-sd-jwt-vc].¶

Profiles built on this specification are also encouraged to use more specific media types, as described in [RFC9596].¶

12. Examples

TODO - Provide more examples¶

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

13. Implementation Status

Note to RFC Editor: Please remove this section as well as references to [BCP205] 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 [BCP205]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.¶

According to [BCP205], "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".¶

14. Security Considerations

Security considerations from COSE {(RFC9052)} and CWT [RFC8392] apply to this specification.¶

15. IANA Considerations

16. References

Appendix A. Complete CDDL Schema

sd-cwt-types = sd-cwt-issued / kbt-cwt

sd-cwt-issued = #6.18([
   protected: bstr .cbor sd-protected,
   sd-unprotected,
   payload: bstr .cbor sd-payload,
   signature: bstr
])

kbt-cwt = #6.18([
   protected: bstr .cbor kbt-protected,
   kbt-unprotected,
   payload: bstr .cbor kbt-payload,
   signature: bstr
])

sd-protected = {
   &(typ: 16) ^ => "application/sd+cwt",
   &(alg: 1) ^ => int,
   &(sd_alg: TBD2) ^= int,             ; -16 for sha-256
   * key => any
}

kbt-protected = {
   &(typ: 16) ^ => "application/kb+cwt",
   &(alg: 1) ^ => int,
   &(kcwt: 13) ^ => bstr .cbor sd-cwt-issued,
   * key => any
}

sd-unprotected = {
   ? &(sd_claims: TBD1) ^ => bstr .cbor salted-array,
   * key => any
}

kbt-unprotected = {
   * key => any
}

sd-payload = {
    ; standard claims
      &(iss: 1) ^ => tstr, ; "https://issuer.example"
    ? &(sub: 2) ^ => tstr, ; "https://device.example"
    ? &(aud: 3) ^ => tstr, ; "https://verifier.example"
    ? &(exp: 4) ^ => int,  ; 1883000000
    ? &(nbf: 5) ^ => int,  ; 1683000000
    ? &(iat: 6) ^ => int,  ; 1683000000
      &(cnf: 8) ^ => { * key => any }, ; key confirmation
    ;
    ? &(redacted_claim_keys: TBD3) ^ => [ * bstr ],
    * key => any
}

kbt-payload = {
      &(aud: 3) ^ => tstr, ; "https://verifier.example"
    ? &(exp: 4) ^ => int,  ; 1883000000
    ? &(nbf: 5) ^ => int,  ; 1683000000
      &(iat: 6) ^ => int,  ; 1683000000
    ? &(cnonce: 39) ^ => bstr,
    * key => any
}

salted-array = [ +bstr .cbor salted ]
salted = salted-claim / salted-element / decoy
salted-claim = [
  bstr .size 16,     ; 128-bit salt
  (int / text),      ; claim name
  any                ; claim value
]
salted-element = [
  bstr .size 16,     ; 128-bit salt
  any                ; claim value
]
decoy = [
  bstr .size 16      ; 128-bit salt
]

key = int / text
TBD1 = 17
TBD2 = 18
;TBD3 = #6.58(any)      ; CBOR tag wrapping to-be-redacted keys or elements
TBD4 = #6.59(0)  ; CBOR tag 59 wrapping reserved integer claim key 0
;TBD5 = #6.60( bstr ) ;redacted_claim_element

Appendix B. Comparison to SD-JWT

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

Appendix C. Keys used in the examples

{
  "kty": "EC",
  "alg": "ES256",
  "kid": "WRQ2RbY5RYJCIxfDQL9agl9fFSCYVu4Xocqb6zerc1M",
  "crv": "P-256",
  "x": "hVTrJ13Nb70cesZBqiyQ2SAi_Q0wJLWvGMfMYa1Sei0",
  "y": "TceuLGd-ltDMgll2Vc6S1VA_VCk9h4ddHnnOR3AZQ0M",
  "d": "V1moblm7OwAt3kZ9pLUvPQbmws1DlFbPBIW5uGQpTOU"
}

{"crv":"P-256","kty":"EC","x":"hVTrJ13Nb70cesZBqiyQ2SAi_Q0wJLWvGMfMYa1S
ei0","y":"TceuLGd-ltDMgll2Vc6S1VA_VCk9h4ddHnnOR3AZQ0M"}

59143645b6394582422317c340bf5a825f5f15209856ee17a1ca9beb37ab7353

WRQ2RbY5RYJCIxfDQL9agl9fFSCYVu4Xocqb6zerc1M

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEhVTrJ13Nb70cesZBqiyQ2SAi/Q0w
JLWvGMfMYa1Sei1Nx64sZ36W0MyCWXZVzpLVUD9UKT2Hh10eec5HcBlDQw==
-----END PUBLIC KEY-----

-----BEGIN PRIVATE KEY-----
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgV1moblm7OwAt3kZ9
pLUvPQbmws1DlFbPBIW5uGQpTOWhRANCAASFVOsnXc1vvRx6xkGqLJDZICL9DTAk
ta8Yx8xhrVJ6LU3HrixnfpbQzIJZdlXOktVQP1QpPYeHXR55zkdwGUND
-----END PRIVATE KEY-----

{
"kty": "EC",
"alg": "ES384",
"kid": "https://issuer.example/cwk3.cbor",
"crv": "P-384",
"x":"wxeYsMeIX6NSj7-HfltMOm3GelpdxrMHtyjDclkm8qvl-0lkzZHjlIpUk_brtsu_",
"y":"j2x-x2FpHK03TE2qk4dFPxgFjs5Y6wqOhKBVox-3-SFLJ1CVIsFZ52T4cR4RYJVU",
"d":"ccVNIiGTfqYS2xIh8NPd93HJOBxOO-QdWqConWhfCc_vdMS78QR4P9V-h6sifQdM"
}

{"crv":"P-384","kty":"EC","x":"wxeYsMeIX6NSj7-HfltMOm3GelpdxrMHtyjDclkm
8qvl-0lkzZHjlIpUk_brtsu_","y":"j2x-x2FpHK03TE2qk4dFPxgFjs5Y6wqOhKBVox-3
-SFLJ1CVIsFZ52T4cR4RYJVU"}

18d4ddb7065d945357e3972dee76af4eddc7c285fb42efcfa900c6a4f8437850

GNTdtwZdlFNX45ct7navTt3HwoX7Qu_PqQDGpPhDeFA

-----BEGIN PUBLIC KEY-----
MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEwxeYsMeIX6NSj7+HfltMOm3GelpdxrMH
tyjDclkm8qvl+0lkzZHjlIpUk/brtsu/j2x+x2FpHK03TE2qk4dFPxgFjs5Y6wqO
hKBVox+3+SFLJ1CVIsFZ52T4cR4RYJVU
-----END PUBLIC KEY-----

-----BEGIN PRIVATE KEY-----
MIG2AgEAMBAGByqGSM49AgEGBSuBBAAiBIGeMIGbAgEBBDBxxU0iIZN+phLbEiHw
0933cck4HE475B1aoKidaF8Jz+90xLvxBHg/1X6HqyJ9B0yhZANiAATDF5iwx4hf
o1KPv4d+W0w6bcZ6Wl3Gswe3KMNyWSbyq+X7SWTNkeOUilST9uu2y7+PbH7HYWkc
rTdMTaqTh0U/GAWOzljrCo6EoFWjH7f5IUsnUJUiwVnnZPhxHhFglVQ=
-----END PRIVATE KEY-----

Appendix D. Document History

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

Acknowledgments

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

Authors' Addresses