SPICE SD-CWT
draft-ietf-spice-sd-cwt-00
| Document | Type | Active Internet-Draft (spice WG) | |
|---|---|---|---|
| Authors | Michael Prorock , Orie Steele , Henk Birkholz | ||
| Last updated | 2024-08-22 | ||
| Replaces | draft-prorock-spice-cose-sd-cwt | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
Mailing list discussion |
||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-spice-sd-cwt-00
Secure Patterns for Internet CrEdentials M. Prorock
Internet-Draft mesur.io
Intended status: Informational O. Steele
Expires: 23 February 2025 Transmute
H. Birkholz
Fraunhofer SIT
22 August 2024
SPICE SD-CWT
draft-ietf-spice-sd-cwt-00
Abstract
This document describes a data minimization technique for use with
CBOR Web Token (CWT) [RFC8392]. The approach is based on SD-JWT
[I-D.ietf-oauth-selective-disclosure-jwt], with changes to align with
CBOR Object Signing and Encryption (COSE). This document updates
[RFC8392].
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at https://ietf-wg-
spice.github.io/draft-ietf-spice-sd-cwt/draft-ietf-spice-sd-cwt.html.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-spice-sd-cwt/.
Discussion of this document takes place on the Secure Patterns for
Internet CrEdentials Working Group mailing list
(mailto:spice@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/spice/. Subscribe at
https://www.ietf.org/mailman/listinfo/spice/.
Source for this draft and an issue tracker can be found at
https://github.com/ietf-wg-spice/draft-ietf-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/.
Prorock, et al. Expires 23 February 2025 [Page 1]
Internet-Draft SPICE SD-CWT August 2024
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 23 February 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. SD-CWT Issuance . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Creating a Key Binding Token . . . . . . . . . . . . . . 8
4. SD-CWT Presentation . . . . . . . . . . . . . . . . . . . . . 9
5. SD-CWT Validation . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Credential Types . . . . . . . . . . . . . . . . . . . . 12
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Minimal spanning example . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7.1. Random Numbers . . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8.1. COSE Header Parameters . . . . . . . . . . . . . . . . . 14
8.1.1. sd_claims . . . . . . . . . . . . . . . . . . . . . . 14
8.1.2. sd_kbt . . . . . . . . . . . . . . . . . . . . . . . 15
8.2. CBOR Web Token (CWT) Claims . . . . . . . . . . . . . . . 15
8.2.1. sd_alg . . . . . . . . . . . . . . . . . . . . . . . 15
8.2.2. sd_hash . . . . . . . . . . . . . . . . . . . . . . . 15
8.2.3. redacted_values . . . . . . . . . . . . . . . . . . . 15
8.2.4. redacted_element . . . . . . . . . . . . . . . . . . 15
8.2.5. vct . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 16
8.3.1. application/sd+cwt . . . . . . . . . . . . . . . . . 16
8.3.2. application/kb+cwt . . . . . . . . . . . . . . . . . 17
Prorock, et al. Expires 23 February 2025 [Page 2]
Internet-Draft SPICE SD-CWT August 2024
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Complete CDDL Schema . . . . . . . . . . . . . . . . 19
Appendix B. Comparison to SD-JWT . . . . . . . . . . . . . . . . 21
B.1. Media Types . . . . . . . . . . . . . . . . . . . . . . . 21
B.2. Redaction Claims . . . . . . . . . . . . . . . . . . . . 21
B.3. Issuance . . . . . . . . . . . . . . . . . . . . . . . . 21
B.4. Presentation . . . . . . . . . . . . . . . . . . . . . . 21
B.5. Validation . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix C. Implementation Status . . . . . . . . . . . . . . . 22
C.1. Transmute Prototype . . . . . . . . . . . . . . . . . . . 22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction
This document updates 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, with changes to align
with conventions from CBOR Object Signing and Encryption (COSE). The
ability to minimize disclosure of sensitive identity attributes,
while demonstrating possession of key material and enabling a
verifier to confirm the attributes have been unaltered by the issuer,
is an important building block for many digital credential use cases.
This specification brings selective disclosure capabilities to CWT,
enabling application profiles to impose additional security criteria
beyond the minimum security requirements this specification requires.
Specific use cases are out of scope for this document. However,
feedback has been gathered from a wide range of stakeholders, some of
which is reflected in the examples provided in the appendix.
1.1. Overview
Figure 1: High level SD-CWT Issuance and Presentation Flow
Prorock, et al. Expires 23 February 2025 [Page 3]
Internet-Draft SPICE SD-CWT August 2024
Issuer Holder Verifier
| | |
| +---+ |
| | | Key Gen |
| Request SD-CWT |<--+ |
|<-------------------------------| |
| | |
+------------------------------->| Request Nonce |
| Receive SD-CWT +-------------------------------->|
| | |
| |<--------------------------------+
| | Receive Nonce |
| +---+ |
| | | Redact Claims |
| |<--+ |
| | |
| +---+ |
| | | Demonstrate |
| |<--+ Posession |
| | |
| | Present SD-CWT |
| +-------------------------------->|
| | |
This diagram captures the essential details necessary to issue and
present an SD-CWT. The parameters necessary to support these
processes can be obtained using transports or protocols which are out
of scope for this specification. However the following guidance is
generally recommended, regardless of protocol or transport.
1. The issuer SHOULD confirm the holder controls all confirmation
material before issuing credentials using the cnf claim.
2. To protect against replay attacks, the verifier SHOULD provide a
nonce, and reject requests that do not include an acceptable an
nonce (cnonce). This guidance can be ignored in cases where
replay attacks are mitigated at another layer.
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.
The terminology used in this document is inherited from RFC8392,
RFC9052 and RFC9053.
Prorock, et al. Expires 23 February 2025 [Page 4]
Internet-Draft SPICE SD-CWT August 2024
This document defines the following new terms related to concepts
originally described in SD-JWT.
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.
Salted Disclosed Claims The salted claims disclosed via an SD-CWT.
Digested Salted Disclosed Claim A hash digest of a Salted Disclosed
Claims.
Redacted keys The hashes of claims redacted from a map data
structure.
Redacted elements The hashes of elements redacted from an array data
structure.
Presented Disclosed Claimset The CBOR map containing zero or more
Redacted keys or Redacted elements.
Validated Disclosed Claimset The CBOR map containing all mandatory
to disclose claims signed by the issuer, all selectively disclosed
claims presented by the holder, and ommiting all instances of
redacted_keys and redacted_element claims that are present in the
original 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.
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.
Verifier An entity that validates a Partial or Full Disclosure by a
holder.
Prorock, et al. Expires 23 February 2025 [Page 5]
Internet-Draft SPICE SD-CWT August 2024
3. SD-CWT Issuance
SD-CWT is modeled after SD-JWT, with adjustments to align with
conventions in CBOR and COSE.
An SD-CWT is a CWT containing the hash digest (the "blinded claim
hash") of each blinded claim in redacted_values in the payload, and
optionally the salted claim values (and often claim names) for the
values that are actually disclosed in the sd_claims claim in the
unprotected header. When blinding an individual item in an array,
the value of the item is replaced with a dict containing only the
special key "...".
redacted_element = { "...": bstr }
A Holder key binding CWT (#kbt) MUST be present in a sd_kbt claim in
the unprotected header when presenting an SD-CWT to a Verifier. The
sd_kbt claim can only be absent when the Issuer is providing the SD-
CWT to the Holder.
An SD-CWT is a CWT containing zero or more Digested Salted Disclosed
Claim, and zero or more Salted Disclosed Claims. The salt acts as a
blinding factor, preventing a Verifier of an SD-CWT from learning
claims that were not intentionally disclosed by a Holder.
The following informative CDDL is provided to explain the syntax for
an SD-CWT presentation. A complete CDDL schema is in (#cddl).
Please note this example contains claims for demonstration of the
disclosure syntax, such as swversion, address, and ``.
Prorock, et al. Expires 23 February 2025 [Page 6]
Internet-Draft SPICE SD-CWT August 2024
sd-cwt-presentation = #6.18([
protected: bstr .cbor sd-protected,
unprotected-presentation,
payload: bstr .cbor sd-payload,
signature: bstr
])
sd-protected = {
&(typ: 16) ^ => "application/sd+cwt",
&(alg: 1) ^ => int,
* key => any
}
unprotected-presentation = {
&(sd_kbt: TBD2) ^ => bstr .cbor kbt-cwt,
? &(sd_claims: TBD1) ^ => bstr .cbor [ + bstr .cbor salted ],
* key => any
}
sd-payload = {
; standard claims
&(iss: 1) ^ => tstr, ; "https://issuer.example"
&(sub: 2) ^ => tstr, ; "https://device.example"
&(aud: 3) ^ => tstr, ; "https://verifier.example"
? &(exp: 4) ^ => int, ; 1883000000
? &(nbf: 5) ^ => int, ; 1683000000
&(iat: 6) ^ => int, ; 1683000000
&(cnf: 8) ^ => { * key => any }, ; key confirmation
? &(cnonce: 39) ^ => bstr,
;
; sd-cwt new claims
&(sd_alg: TBD4) ^ => int, ; -16 for sha-256
? &(redacted_values: TBD5) ^ => [ * bstr ],
* key => any
}
Disclosures for named claims are structured as a 32 bit salt, the
name of the redacted element, and the disclosed value. For
disclosures of items in an array, the name is ommitted.
Prorock, et al. Expires 23 February 2025 [Page 7]
Internet-Draft SPICE SD-CWT August 2024
salted = salted-claim / salted-element
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
]
3.1. Creating a Key Binding Token
digested-salted-disclosed-claim = bstr;
salted-disclosed-claim = salted-claim / salted-element
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
]
sd-cwt-cnf = COSE_Key / Encrypted_COSE_Key / kid
sd-cwt = [
protected,
unprotected: {
?(sd_claims: TBD1): bstr .cbor [ + salted-disclosed-claim ],
?(sd_kbt: TBD2): bstr .cbor sd-cwt-kbt,
},
payload : bstr .cbor {
?(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) => sd-cwt-cnf, ; 1683000000
?(sd_alg: TBD4) => int, ; -16 for sha-256
?(redacted_keys: TBD5) => [ ; redacted map keys
digested-salted-disclosed-claim
],
; redaction in an example map value that is an array
&(example-array-key: -65537) => [
123,
Prorock, et al. Expires 23 February 2025 [Page 8]
Internet-Draft SPICE SD-CWT August 2024
{ ; redacted array element
&(redacted_element: TBD6) =>
digested-salted-disclosed-claim
},
789,
{ ; redacted array element
&(redacted_element: TBD6) =>
digested-salted-disclosed-claim
},
]
}
signature : bstr,
]
As described above, an SD-CWT is a CWT with claims that require
confirmation and support selective disclosure. Confirmation
mitigates risks associated with bearer token theft. Note that new
confirmation methods might be registered and used after this document
is published. Selective disclosure enables data minimization. The
mechanism through which map keys and array elements are disclosed is
different, see SD-CWT Validation for details. CWT Claims which are
not explictly marked redactable by the Issuer are mandatory to
disclose by the Holder. A detailed privacy and security analysis of
all mandatory and optionally disclosed claims SHOULD be performed
prior to issuance.
4. SD-CWT Presentation
Presentations of an SD-CWT by a Holder to a Verifier require the
Holder to issue an SD-CWT-KBT.
The SD-CWT-KBT is essential to assuring the Verifier:
* a) the Holder of the SD-CWT controls the confirmation method
chosen by the Issuer.
* b) the Holder's disclosures have not been tampered with since
confirmation occured.
The SD-CWT-KBT prevents an attacker from copying and pasting
disclosures, or from adding or removing disclosures without
detection. Confirmation is established according to RFC 8747, using
the cnf claim in the payload of the SD-CWT. The Digested Salted
Disclosed Claim are included in the sd_hash claim in the payload of
the SD-CWT-KBT.
Prorock, et al. Expires 23 February 2025 [Page 9]
Internet-Draft SPICE SD-CWT August 2024
The proof of possession associated with the confirmation claim in an
SD-CWT is called the SD-CWT-KBT. As noted above, SD-CWT Issuance,
sd_kbt SHALL be present in every presentation of an SD-CWT by a
Holder to a Verifier.
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,
* 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,
; matches the hash of sd_claims in the presentation token
&(sd_hash: TBD3) ^ => bstr,
* key => any
}
Note that sd_hash is the digest using sd_alg of the sd_claims which
are either Partially or Fully Redacted in the Presented SD-CWT.
The cnonce and audience are essential to assure the Verifier that the
Holder is currently in control of the associated confirmation method,
and that the holder intended to disclose the SD-CWT to the Verifier.
Note that cnonce is a bstr and MUST be treated as opaque to the
Holder.
The details associated with these protocol parameters are out of
scope for this document.
Prorock, et al. Expires 23 February 2025 [Page 10]
Internet-Draft SPICE SD-CWT August 2024
5. SD-CWT 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 validate the SD-CWT as described in
Section 7.2 of [RFC8392].
After validation, the SD-CWT-KBT MUST be extracted from the
unprotected header, and validated as described in Section 7.2 of
[RFC8392].
The Verifier MUST confirm the sd_hash claim of the validated SD-CWT-
KBT matches the hash of the sd_claims member of the unprotected
header, using the hash algorithm obtained from the validated sd_alg
claim of the SD-CWT.
Next, the Verifier MUST extract and decode the disclosed claims from
the sd_claims in the unprotected header.
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, 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-disclosed-claim
}
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 siganture had failed to verify.
Prorock, et al. Expires 23 February 2025 [Page 11]
Internet-Draft SPICE SD-CWT August 2024
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.
5.1. 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 COSE based verifiable credentials, similar to
the JOSE based verifiable credentials described in Section 3.2.2.1.1
of SD-JWT-VC.
Profiles built on this specifiation are also encouraged to use more
specific media types, as described in draft-ietf-cose-typ-header-
parameter (https://datatracker.ietf.org/doc/draft-ietf-cose-typ-
header-parameter/).
6. Examples
TBD - Provide more examples
6.1. Minimal spanning example
The following example contains claims needed to demonstrate redaction
of key-value pairs and array elements.
/ cose-sign1 / 18([
/ protected / << {
/ alg / 1 : -35, / ES384 /
/ typ / 16 : "application/sd+cwt",
/ kid / 4 : 'https://issuer.example/cwt-key3'
} >>,
/ unprotected / {
/ sd_claims / 17 : <<[ /these are the three disclosures/
<<[
/salt/ h'c93c7ff572c71e26',
/claim/ "age_over_18",
/value/ true
]>>,
<<[
/salt/ h'399c641e2aa18c1e',
/claim/ "region",
Prorock, et al. Expires 23 February 2025 [Page 12]
Internet-Draft SPICE SD-CWT August 2024
/value/ "ca" /California/
]>>,
<<[
/salt/ h'82501bb46c655f32',
/value/ "4.1.7"
]>>
]>>,
/ sd_kbt / 18 : << 18([
/ protected / << {
/ alg / 1 : -35 / ES384 /,
/ typ / 16 : "application/kb+cwt"
} >>,
/ unprotected / {},
/ payload / << {
/ cnonce / 39 : h'e0a156bb3f',
/ aud / 3 : "https://verifier.example",
/ iat / 6 : 1783000000,
/ sd_alg / 12 : -16, /SHA-256/
/ sd_hash / 11 : h'c341bb4a5f3f' /hash of sd_claims /
/using hash in sd_alg/
} >>,
/ signature / h'1237af2e678945'
]) >>
},
/ 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'
}
},
/ cnonce / 39 : h'12345678',
/ sd_hash / 11 : h'abcdef12',
/ sd_alg / 12 : -16, / SHA-256 /
/ redacted_keys / 13 : [
h'abbdefef', / redacted age_over_18 /
h'132d75e7' / redacted age_over_21 /
],
/ swversion / 271 : [
"3.5.5",
Prorock, et al. Expires 23 February 2025 [Page 13]
Internet-Draft SPICE SD-CWT August 2024
{ "...": h'45dd87af' /redacted version element/ }
],
"address": {
"country" : "us", / United States /
/redacted_keys/ 13 : [
h'adb7060403da225b', / redacted region /
h'e04bdfc44d3d40bc' / redacted post_code /
]
}
} >>,
/ signature / h'3337af2e66959614'
])
Figure 1: An EDN Example
7. Security Considerations
Security considerations from COSE {RFC9052} and CWT {RFC8392} apply
to this specificaton.
7.1. 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.
8. IANA Considerations
8.1. COSE Header Parameters
IANA is requested to add the following entries to the CWT claims
registry (https://www.iana.org/assignments/cose/cose.xhtml#header-
parameters).
8.1.1. sd_claims
The following completed registration template per RFC8152 is
provided:
Name: sd_claims Label: TBD1 (requested assignment 17) Value Type:
bstr Value Registry: (empty) Description: A list of selectively
disclosed claims, which were originally redacted, then later
disclosed at the discretion of the sender. Reference: RFC XXXX
Prorock, et al. Expires 23 February 2025 [Page 14]
Internet-Draft SPICE SD-CWT August 2024
8.1.2. sd_kbt
The following completed registration template per RFC8152 is
provided:
Name: sd_kbt Label: TBD2 (requested assignment 18) Value Type: bstr
Value Registry: (empty) Description: Key binding token for disclosed
claims Reference: RFC XXXX
8.2. CBOR Web Token (CWT) Claims
IANA is requested to add the following entries to the CWT claims
registry (https://www.iana.org/assignments/cwt/cwt.xhtml).
8.2.1. sd_alg
The following completed registration template per RFC8392 is
provided:
Claim Name: sd_alg Claim Description: Hash algorithm used for
selective disclosure JWT Claim Name: sd_alg Claim Key: TBD4 (request
assignment 12) Claim Value Type(s): integer Change Controller: IETF
Specification Document(s): RFC XXXX
8.2.2. sd_hash
The following completed registration template per RFC8392 is
provided:
Claim Name: sd_hash Claim Description: Hash of encoded disclosed
claims JWT Claim Name: sd_hash Claim Key: TBD3 (request assignment
11) Claim Value Type(s): bstr Change Controller: IETF Specification
Document(s): RFC XXXX
8.2.3. redacted_values
The following completed registration template per RFC8392 is
provided:
Claim Name: redacted_values Claim Description: Redacted claims in a
map. JWT Claim Name: redacted_keys Claim Key: TBD5 (request
assignment 13) Claim Value Type(s): array of bstr Change Controller:
IETF Specification Document(s): RFC XXXX
8.2.4. redacted_element
The following completed registration template per RFC8392 is
provided:
Prorock, et al. Expires 23 February 2025 [Page 15]
Internet-Draft SPICE SD-CWT August 2024
Claim Name: redacted_element Claim Description: Redacted element of
an array JWT Claim Name: redacted_element Claim Key: TBD (request
assignment TBD6) Claim Value Type(s): array of bstr Change
Controller: IETF Specification Document(s): RFC XXXX
8.2.5. vct
The following completed registration template per RFC8392 is
provided:
Claim Name: vct Claim Description: Verifiable credential type JWT
Claim Name: vct Claim Key: TBD (request assignment TBD7) Claim Value
Type(s): bstr Change Controller: IETF Specification Document(s): RFC
XXXX
8.3. Media Types
This section requests the registration of new media types in
https://www.iana.org/assignments/media-types/media-types.xhtml.
8.3.1. application/sd+cwt
IANA is requested to add the following entry to the media types
registry in accordance with RFC6838, RFC4289, and RFC6657.
The following completed registration template is provided:
* Type name: application
* Subtype name: sd+cwt
* Required parameters: n/a
* Optional parameters: n/a
* Encoding considerations: binary
* Security considerations: See the Security Considerations section
of RFC XXXX, and [RFC8392]
* Interoperability considerations: n/a
* Published specification: RFC XXXX
* Applications that use this media type: TBD
* Fragment identifier considerations: n/a
Prorock, et al. Expires 23 February 2025 [Page 16]
Internet-Draft SPICE SD-CWT August 2024
* Additional information: Magic number(s): n/a File extension(s): n/
a Macintosh file type code(s): n/a
* Person & email address to contact for further information: Michael
Prorock, mprorock@mesur.io
* Intended usage: COMMON
* Restrictions on usage: none
* Author: Michael Prorock, mprorock@mesur.io
* Change controller: IETF
* Provisional registration? No
8.3.2. application/kb+cwt
IANA is requested to add the following entry to the media types
registry in accordance with RFC6838, RFC4289, and RFC6657.
The following completed registration template is provided:
* Type name: application
* Subtype name: kb+cwt
* Required parameters: n/a
* Optional parameters: n/a
* Encoding considerations: binary
* Security considerations: See the Security Considerations section
of RFC XXXX, and [RFC8392]
* Interoperability considerations: n/a
* Published specification: RFC XXXX
* Applications that use this media type: TBD
* Fragment identifier considerations: n/a
* Additional information: Magic number(s): n/a File extension(s): n/
a Macintosh file type code(s): n/a
Prorock, et al. Expires 23 February 2025 [Page 17]
Internet-Draft SPICE SD-CWT August 2024
* Person & email address to contact for further information: Orie
Steele, orie@transmute.industries
* Intended usage: COMMON
* Restrictions on usage: none
* Author: Orie Steele, orie@transmute.industries
* Change controller: IETF
* Provisional registration? No
9. References
9.1. Normative References
[BCP205] Best Current Practice 205,
<https://www.rfc-editor.org/info/bcp205>.
At the time of writing, this BCP comprises the following:
Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/rfc/rfc7515>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.
9.2. Informative References
Prorock, et al. Expires 23 February 2025 [Page 18]
Internet-Draft SPICE SD-CWT August 2024
[I-D.ietf-oauth-selective-disclosure-jwt]
Fett, D., Yasuda, K., and B. Campbell, "Selective
Disclosure for JWTs (SD-JWT)", Work in Progress, Internet-
Draft, draft-ietf-oauth-selective-disclosure-jwt-11, 22
August 2024, <https://datatracker.ietf.org/doc/html/draft-
ietf-oauth-selective-disclosure-jwt-11>.
Appendix A. Complete CDDL Schema
sd-cwt-types = sd-cwt-presentation / sd-cwt-issued / kbt-cwt
sd-cwt-presentation = #6.18([
protected: bstr .cbor sd-protected,
unprotected-presentation,
payload: bstr .cbor sd-payload,
signature: bstr
])
sd-cwt-issued = #6.18([
protected: bstr .cbor sd-protected,
unprotected-issued,
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,
* key => any
}
kbt-protected = {
&(typ: 16)^ => "application/kb+cwt",
&(alg: 1)^ => int,
* key => any
}
unprotected-presentation = {
&(sd_kbt: TBD2) ^ => bstr .cbor kbt-cwt,
? &(sd_claims: TBD1) ^ => [ +bstr .cbor salted ],
* key => any
Prorock, et al. Expires 23 February 2025 [Page 19]
Internet-Draft SPICE SD-CWT August 2024
}
unprotected-issued = {
? &(sd_claims: TBD1) ^ => [ +bstr .cbor salted ],
* 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
? &(cnonce: 39) ^ => bstr,
;
; sd-cwt new claims
&(sd_hash: TBD3) ^ => bstr,
&(sd_alg: TBD4) ^ => int, ; -16 for sha-256
? &(redacted_keys: TBD5) ^ => [ * 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,
&(sd_hash: TBD3) ^ => bstr,
* key => any
}
;redacted_element = { "...": bstr }
salted = salted-claim / salted-element
salted-claim = [
bstr ;.size 16, ; 128-bit salt
(int / text), ; claim name
any ; claim value
]
salted-element = [
bstr ;.size 16, ; 128-bit salt
Prorock, et al. Expires 23 February 2025 [Page 20]
Internet-Draft SPICE SD-CWT August 2024
any ; claim value
]
key = int / text
TBD1 = 17
TBD2 = 18
TBD3 = 11
TBD4 = 12
TBD5 = 13
Figure 2: A complete CDDL description of SD-CWT
Appendix B. Comparison to SD-JWT
SD-CWT is modeled after SD-JWT, with adjustments to align with
conventions in CBOR and COSE.
B.1. Media Types
The COSE equivalent of application/sd-jwt is application/sd+cwt.
THe COSE equivalent of application/kb+jwt is application/kb+cwt.
B.2. Redaction Claims
The COSE equivalent of _sd is TBD5.
The COSE equivalent of ... is TBD6.
B.3. Issuance
The issuance process for SD-CWT is similar to SD-JWT, with the
exception that a confirmation claim is REQUIRED.
B.4. Presentation
The presentation process for SD-CWT is similar to SD-JWT, with the
exception that a Key Binding Token is REQUIRED.
B.5. Validation
The validation process for SD-JWT is similar to SD-JWT, however, JSON
Objects are replaced with CBOR Maps which can contain integer keys
and CBOR Tags.
Prorock, et al. Expires 23 February 2025 [Page 21]
Internet-Draft SPICE SD-CWT August 2024
Appendix C. 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".
C.1. Transmute Prototype
Organization: Transmute Industries Inc
Name: https://github.com/transmute-industries/sd-cwt
Description: An open source implementation of this draft.
Maturity: Prototype
Coverage: The current version ('main') implements functionality
similar to that described in this document, and will be revised, with
breaking changes to support the generation of example data to support
this specification.
License: Apache-2.0
Implementation Experience: No interop testing has been done yet. The
code works as proof of concept, but is not yet production ready.
Contact: Orie Steele (orie@transmute.industries)
Prorock, et al. Expires 23 February 2025 [Page 22]
Internet-Draft SPICE SD-CWT August 2024
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, Oliver Terbu, and Michael Jones.
Authors' Addresses
Michael Prorock
mesur.io
Email: mprorock@mesur.io
Orie Steele
Transmute
Email: orie@transmute.industries
Henk Birkholz
Fraunhofer SIT
Rheinstrasse 75
64295 Darmstadt
Germany
Email: henk.birkholz@ietf.contact
Prorock, et al. Expires 23 February 2025 [Page 23]