idnits 2.17.1 draft-fett-oauth-selective-disclosure-jwt-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 23 instances of too long lines in the document, the longest one being 285 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (23 June 2022) is 670 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Web Authorization Protocol D. Fett 3 Internet-Draft yes.com 4 Intended status: Standards Track K. Yasuda 5 Expires: 25 December 2022 Microsoft 6 23 June 2022 8 Selective Disclosure JWT (SD-JWT) 9 draft-fett-oauth-selective-disclosure-jwt-01 11 Abstract 13 This document specifies conventions for creating JSON Web Token (JWT) 14 documents that support selective disclosure of JWT claim values. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on 25 December 2022. 33 Copyright Notice 35 Copyright (c) 2022 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Revised BSD License text as 44 described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Revised BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 4 51 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 52 3. Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . 4 53 4. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 4.1. Creating an SD-JWT . . . . . . . . . . . . . . . . . . . 5 55 4.2. Creating an SD-JWT Release . . . . . . . . . . . . . . . 6 56 4.3. Optional Holder Binding . . . . . . . . . . . . . . . . . 6 57 4.4. Verifying an SD-JWT Release . . . . . . . . . . . . . . . 7 58 5. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 7 59 5.1. Format of an SD-JWT . . . . . . . . . . . . . . . . . . . 7 60 5.1.1. sd_digests Claim (Digests of Selectively Disclosable 61 Claims) . . . . . . . . . . . . . . . . . . . . . . . 7 62 5.1.2. Hash Function Claim . . . . . . . . . . . . . . . . . 8 63 5.1.3. Holder Public Key Claim . . . . . . . . . . . . . . . 8 64 5.2. Example 1: SD-JWT . . . . . . . . . . . . . . . . . . . . 8 65 5.3. Format of a SD-JWT Salt/Value Container (SVC) . . . . . . 10 66 5.4. Example: SVC for the Flat SD-JWT in Example 1 . . . . . . 10 67 5.5. Sending SD-JWT and SVC during Issuance . . . . . . . . . 11 68 5.6. Format of an SD-JWT Release . . . . . . . . . . . . . . . 12 69 5.7. Example: SD-JWT Release for Example 1 . . . . . . . . . . 13 70 5.8. Sending SD-JWT and SD-JWT-R during Presentation . . . . . 14 71 6. Verification . . . . . . . . . . . . . . . . . . . . . . . . 15 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 73 7.1. Mandatory signing of the SD-JWT . . . . . . . . . . . . . 17 74 7.2. Entropy of the salt . . . . . . . . . . . . . . . . . . . 17 75 7.3. Minimum length of the salt . . . . . . . . . . . . . . . 17 76 7.4. Choice of a hash function . . . . . . . . . . . . . . . . 18 77 7.5. Holder Binding . . . . . . . . . . . . . . . . . . . . . 18 78 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 79 8.1. Claim Names . . . . . . . . . . . . . . . . . . . . . . . 18 80 8.2. Unlinkability . . . . . . . . . . . . . . . . . . . . . . 18 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 82 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 83 11. Normative References . . . . . . . . . . . . . . . . . . . . 18 84 12. Informative References . . . . . . . . . . . . . . . . . . . 19 85 Appendix A. Additional Examples . . . . . . . . . . . . . . . . 19 86 A.1. Example 2 - Structured SD-JWT . . . . . . . . . . . . . . 19 87 A.2. Example 3 - Complex Structured SD-JWT . . . . . . . . . . 21 88 A.3. Example 4 - W3C Verifiable Credentials Data Model . . . . 26 89 Appendix B. Document History . . . . . . . . . . . . . . . . . . 28 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 92 1. Introduction 94 The JSON-based claims in a signed JSON Web Token (JWT) [RFC7519] 95 document are secured against modification using JSON Web Signature 96 (JWS) [RFC7515] digital signatures. A consumer of a signed JWT 97 document that has checked the document's signature can safely assume 98 that the contents of the document have not been modified. However, 99 anyone receiving an unencrypted JWT can read all of the claims and 100 likewise, anyone with the decryption key receiving an encrypted JWT 101 can also read all of the claims. 103 This document describes a format for signed JWTs that support 104 selective disclosure (SD-JWT), enabling sharing only a subset of the 105 claims included in the original signed JWT instead of releasing all 106 the claims to every verifier. During issuance, an SD-JWT is sent 107 from the issuer to the holder alongside an SD-JWT Salt/Value 108 Container (SVC), a JSON object that contains the mapping between raw 109 claim values contained in the SD-JWT and the salts for each claim 110 value. 112 This document also defines a format for SD-JWT Releases (SD-JWT-R), 113 which convey a subset of the claim values of an SD-JWT to the 114 verifier. For presentation, the holder creates an SD-JWT-R and sends 115 it together with the SD-JWT to the verifier. To verify claim values 116 received in SD-JWT-R, the verifier uses the salts values in the SD- 117 JWT-R to compute the hashes of the claim values and compare them to 118 the hashes in the SD-JWT. 120 One of the common use cases of a signed JWT is representing a user's 121 identity created by an issuer. As long as the signed JWT is one-time 122 use, it typically only contains those claims the user has consented 123 to release to a specific verifier. However, when a signed JWT is 124 intended to be multi-use, it needs to contain the superset of all 125 claims the user might want to release to verifiers at some point. 126 The ability to selectively disclose a subset of these claims 127 depending on the verifier becomes crucial to ensure minimum 128 disclosure and prevent verifiers from obtaining claims irrelevant for 129 the transaction at hand. 131 One example of such a multi-use JWT is a verifiable credential, a 132 tamper-evident credential with a cryptographically verifiable 133 authorship that contains claims about a subject. SD-JWTs defined in 134 this document enable such selective disclosure of claims. 136 While JWTs for claims describing natural persons are a common use 137 case, the mechanisms defined in this document can be used for many 138 other use cases as well. 140 This document also describes holder binding, or the concept of 141 binding SD-JWT to key material controlled by the subject of SD-JWT. 142 Holder binding is optional to implement. 144 1.1. Conventions and Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 148 "OPTIONAL" in this document are to be interpreted as described in BCP 149 14 [RFC2119] [RFC8174] when, and only when, they appear in all 150 capitals, as shown here. 152 *base64url* denotes the URL-safe base64 encoding without padding 153 defined in Section 2 of [RFC7515]. 155 2. Terms and Definitions 157 Selective Disclosure JWT (SD-JWT) A JWT [RFC7515] created by the 158 issuer, which is signed as a JWS [RFC7515], that supports 159 selective disclosure as defined in this document. 161 SD-JWT Salt/Value Container (SVC) A JSON object created by the 162 issuer that contains mapping between raw claim values contained in 163 the SD-JWT and the salts for each claim value. 165 SD-JWT Release (SD-JWT-R) A JWT created by the holder that contains 166 a subset of the claim values of an SD-JWT in a verifiable way. 168 Holder binding Ability of the holder to prove legitimate possession 169 of SD-JWT by proving control over the same private key during the 170 issuance and presentation. SD-JWT signed by the issuer contains a 171 public key or a reference to a public key that matches to the 172 private key controlled by the holder. 174 Issuer An entity that creates SD-JWTs (2.1). 176 Holder An entity that received SD-JWTs (2.1) from the issuer and has 177 control over them. 179 Verifier An entity that requests, checks and extracts the claims 180 from SD-JWT-R (2.2) 182 Note: discuss if we want to include Client, Authorization Server for 183 the purpose of ensuring continuity and separating the entity from the 184 actor. 186 3. Flow Diagram 187 +------------+ 188 | | 189 | Issuer | 190 | | 191 +------------+ 192 | 193 Issues 194 SD-JWT and SVC 195 | 196 v 197 +------------+ 198 | | 199 | Holder | 200 | | 201 +------------+ 202 | 203 Presents 204 SD-JWT-R and SD-JWT 205 | 206 v 207 +-------------+ 208 | |+ 209 | Verifiers ||+ 210 | ||| 211 +-------------+|| 212 +-------------+| 213 +-------------+ 215 Figure 1: SD-JWT Issuance and Presentation Flow 217 4. Concepts 219 In the following, the contents of SD-JWTs and SD-JWT Releases are 220 described at a conceptual level, abstracting from the data formats 221 described afterwards. 223 4.1. Creating an SD-JWT 225 An SD-JWT, at its core, is a digitally signed document containing 226 hashes over the claim values with unique salts and other metadata. 227 It MUST be digitally signed using the issuer's private key. 229 SD-JWT-DOC = (METADATA, SD-CLAIMS) 230 SD-JWT = SD-JWT-DOC | SIG(SD-JWT-DOC, ISSUER-PRIV-KEY) 232 SD-CLAIMS can be a simple object with claim names mapped to hashes 233 over the claim values with unique salts: 235 SD-CLAIMS = ( 236 CLAIM-NAME: HASH(SALT | CLAIM-VALUE) 237 )* 239 SD-CLAIMS can also be nested deeper to capture more complex objects, 240 as will be shown later. 242 SD-JWT is sent from the issuer to the holder, together with the 243 mapping of the plain-text claim values, the salt values, and 244 potentially some other information. 246 4.2. Creating an SD-JWT Release 248 To disclose to a verifier a subset of the SD-JWT claim values, a 249 holder creates a JWT such as the following: 251 SD-JWT-RELEASE-DOC = (METADATA, SD-RELEASES) 252 SD-JWT-RELEASE = SD-JWT-RELEASE-DOC 254 SD-RELEASES follows the structure of SD-CLAIMS and can be a simple 255 object with claim names mapped to values and salts: 257 SD-RELEASES = ( 258 CLAIM-NAME: (DISCLOSED-SALT, DISCLOSED-VALUE) 259 ) 261 Just as SD-CLAIMS, SD-RELEASES can be more complex as well. 263 SD-JWT-RELEASE is sent together with SD-JWT from the holder to the 264 verifier. 266 4.3. Optional Holder Binding 268 Some use-cases may require holder binding. 270 If holder binding is desired, SD-JWT must contain information about 271 key material controlled by the holder: 273 SD-JWT-DOC = (METADATA, HOLDER-PUBLIC-KEY, SD-CLAIMS) 275 Note: How the public key is included in SD-JWT is out of scope of 276 this document. It can be passed by value or by reference. Examples 277 in this document use sub_jwt Claim to include raw public key by value 278 in SD-JWT. 280 With holder binding, the SD-JWT-RELEASE is signed by the holder using 281 its private key. It therefore looks as follows: 283 SD-JWT-RELEASE = SD-JWT-RELEASE-DOC | SIG(SD-JWT-RELEASE-DOC, HOLDER-PRIV-KEY) 285 4.4. Verifying an SD-JWT Release 287 A verifier checks that 289 * for each claim in SD-JWT-RELEASE, the hash HASH(DISCLOSED-SALT | 290 DISCLOSED-VALUE) matches the hash under the given claim name in 291 SD-JWT. 293 * if holder binding is desired, the SD-JWT-RELEASE was signed by the 294 private key belonging to HOLDER-PUBLIC-KEY. 296 The detailed algorithm is described below. 298 5. Data Formats 300 This section defines data formats for SD-JWTs (containing hashes of 301 the salted claim values), SD-JWT Salt/Value Containers (containing 302 the mapping of the plain-text claim values and the salt values), and 303 SD-JWT Releases (containing a subset of the same mapping). 305 5.1. Format of an SD-JWT 307 An SD-JWT is a JWT that MUST be signed using the issuer's private 308 key. The payload of an SD-JWT MUST contain the sd_digests and 309 hash_alg claims described in the following, and MAY contain a 310 holder's public key or a reference thereto, as well as further claims 311 such as iss, iat, etc. as defined or required by the application 312 using SD-JWTs. 314 5.1.1. sd_digests Claim (Digests of Selectively Disclosable Claims) 316 An SD-JWT MUST include hashes of the salted claim values that are 317 included by the issuer under the property sd_digests. 319 The issuer MUST choose a unique salt value for each claim value. 320 Each salt value MUST contain at least 128 bits of pseudorandom data, 321 making it hard for an attacker to guess. The salt value MUST then be 322 encoded as a string. It is RECOMMENDED to base64url-encode at least 323 16 pseudorandom bytes. 325 The issuer MUST build the hashes by hashing over a string that is 326 formed by JSON-encoding an ordered array containing the salt and the 327 claim value, e.g.: ["6qMQvRL5haj","Peter"]. The hash value is then 328 base64url-encoded. Note that the precise JSON encoding can vary, and 329 therefore, the JSON encodings MUST be sent to the holder along with 330 the SD-JWT, as described below. 332 5.1.1.1. Flat and Structured sd_digests objects 334 The sd_digests object can be a 'flat' object, directly containing all 335 claim names and hashed claim values without any deeper structure. 336 The sd_digests object can also be a 'structured' object, where some 337 claims and their respective hashes are contained in places deeper in 338 the structure. It is at the issuer's discretion whether to use a 339 'flat' or 'structured' sd_digests SD-JWT object, and how to structure 340 it such that it is suitable for the use case. 342 Example 1 below is a non-normative example of an SD-JWT using a 343 'flat' sd_digests object and Example 2 in the appendix shows a non- 344 normative example of an SD-JWT using a 'structured' sd_digests 345 object. The difference between the examples is how the address claim 346 is disclosed. 348 Appendix 2 shows a more complex example using claims from eKYC (todo: 349 reference). 351 5.1.2. Hash Function Claim 353 The claim hash_alg indicates the hash algorithm used by the Issuer to 354 generate the hashes of the salted claim values. The hash algorithm 355 identifier MUST be a value from the "Hash Name String" column in the 356 IANA "Named Information Hash Algorithm" registry 357 [IANA.Hash.Algorithms]. SD-JWTs with hash algorithm identifiers not 358 found in this registry are not considered valid and MUST NOT be 359 accepted by verifiers. 361 5.1.3. Holder Public Key Claim 363 If the issuer wants to enable holder binding, it MAY include a public 364 key associated with the holder, or a reference thereto. 366 It is out of the scope of this document to describe how the holder 367 key pair is established. For example, the holder MAY provide a key 368 pair to the issuer, the issuer MAY create the key pair for the 369 holder, or holder and issuer MAY use pre-established key material. 371 Note: need to define how holder public key is included, right now 372 examples are using sub_jwk I think. 374 5.2. Example 1: SD-JWT 376 This example and Example 2 in the appendix use the following object 377 as the set of claims that the Issuer is issuing: 379 { 380 "sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c", 381 "given_name": "John", 382 "family_name": "Doe", 383 "email": "johndoe@example.com", 384 "phone_number": "+1-202-555-0101", 385 "address": { 386 "street_address": "123 Main St", 387 "locality": "Anytown", 388 "region": "Anystate", 389 "country": "US" 390 }, 391 "birthdate": "1940-01-01" 392 } 394 The following non-normative example shows the payload of an SD-JWT. 395 The issuer is using a flat structure, i.e., all of the claims the 396 address claim can only be disclosed in full. 398 { 399 "iss": "https://example.com/issuer", 400 "sub_jwk": { 401 "kty": "RSA", 402 "n": "pm4bOHBg-oYhAyPWzR56AWX3rUIXp11_ICDkGgS6W3ZWLts-hzwI3x65659kg4hVo9dbGoCJE3ZGF_eaetE30UhBUEgpGwrDrQiJ9zqprmcFfr3qvvkGjtth8Zgl1eM2bJcOwE7PCBHWTKWYs152R7g6Jg2OVph-a8rq-q79MhKG5QoW_mTz10QT_6H4c7PjWG1fjh8hpWNnbP_pv6d1zSwZfc5fl6yVRL0DV0V3lGHKe2Wqf_eNGjBrBLVklDTk8-stX_MWLcR-EGmXAOv0UBWitS_dXJKJu-vXJyw14nHSGuxTIK2hx1pttMft9CsvqimXKeDTU14qQL1eE7ihcw", 403 "e": "AQAB" 404 }, 405 "hash_alg": "sha-256", 406 "iat": 1516239022, 407 "exp": 1516247022, 408 "sd_digests": { 409 "sub": "LbnhkOr5oS7KjeUrxezAu8TG0CpWz0jSixy6tffuo04", 410 "given_name": "fUMdn88aaoyKTHrvZd6AuLmPraGhPJ0zF5r_JhxCVZs", 411 "family_name": "9h5vgv6TpFV6GmnPtugiMLl5tHetHeb5X_2cKHjN7cw", 412 "email": "fPZ92dtYMCN2Nb-2ac_zSH19p4yakUXrZl_-wSgaazA", 413 "phone_number": "QdSffzNzzd0n60MsSmuiKj6Y6Enk2b-BS-KtEePde5M", 414 "address": "JFu99NUXPq55f6DFBZ22rMkxMNHayCrfPG0FDsqbyDs", 415 "birthdate": "Ia1Tc6_Xnt5CJc2LtKcu6Wvqr42glBGGcjGOye8Zf3U" 416 }, 417 "hash_alg": "sha-256" 418 } 420 The SD-JWT is then signed by the issuer to create a document like the 421 following: 423 eyJhbGciOiAiUlMyNTYifQ.eyJpc3MiOiAiaHR0cHM6Ly9leGFtcGxlLmNvbS9pc3N1ZXI 424 iLCAic3ViX2p3ayI6IHsia3R5IjogIlJTQSIsICJuIjogInBtNGJPSEJnLW9ZaEF5UFd6U 425 jU2QVdYM3JVSVhwMTFfSUNEa0dnUzZXM1pXTHRzLWh6d0kzeDY1NjU5a2c0aFZvOWRiR29 426 DSkUzWkdGX2VhZXRFMzBVaEJVRWdwR3dyRHJRaUo5enFwcm1jRmZyM3F2dmtHanR0aDhaZ 427 2wxZU0yYkpjT3dFN1BDQkhXVEtXWXMxNTJSN2c2SmcyT1ZwaC1hOHJxLXE3OU1oS0c1UW9 428 XX21UejEwUVRfNkg0YzdQaldHMWZqaDhocFdObmJQX3B2NmQxelN3WmZjNWZsNnlWUkwwR 429 FYwVjNsR0hLZTJXcWZfZU5HakJyQkxWa2xEVGs4LXN0WF9NV0xjUi1FR21YQU92MFVCV2l 430 0U19kWEpLSnUtdlhKeXcxNG5IU0d1eFRJSzJoeDFwdHRNZnQ5Q3N2cWltWEtlRFRVMTRxU 431 UwxZUU3aWhjdyIsICJlIjogIkFRQUIifSwgImlhdCI6IDE1MTYyMzkwMjIsICJleHAiOiA 432 xNTE2MjQ3MDIyLCAiX3NkIjogeyJzdWIiOiAiTGJuaGtPcjVvUzdLamVVcnhlekF1OFRHM 433 ENwV3owalNpeHk2dGZmdW8wNCIsICJnaXZlbl9uYW1lIjogImZVTWRuODhhYW95S1RIcnZ 434 aZDZBdUxtUHJhR2hQSjB6RjVyX0poeENWWnMiLCAiZmFtaWx5X25hbWUiOiAiOWg1dmd2N 435 lRwRlY2R21uUHR1Z2lNTGw1dEhldEhlYjVYXzJjS0hqTjdjdyIsICJlbWFpbCI6ICJmUFo 436 5MmR0WU1DTjJOYi0yYWNfelNIMTlwNHlha1VYclpsXy13U2dhYXpBIiwgInBob25lX251b 437 WJlciI6ICJRZFNmZnpOenpkMG42ME1zU211aUtqNlk2RW5rMmItQlMtS3RFZVBkZTVNIiw 438 gImFkZHJlc3MiOiAiSkZ1OTlOVVhQcTU1ZjZERkJaMjJyTWt4TU5IYXlDcmZQRzBGRHNxY 439 nlEcyIsICJiaXJ0aGRhdGUiOiAiSWExVGM2X1hudDVDSmMyTHRLY3U2V3ZxcjQyZ2xCR0d 440 jakdPeWU4WmYzVSJ9LCAiaGFzaF9hbGciOiAic2hhLTI1NiJ9.FfUbeF_py0aTQ6XHamsX 441 PNd0LopmZPXdA3iOaCpK9G11SUrzEo8BrmzsqHCbEIDXUxM_CXjslvBYaFF0J374Xwyuxw 442 t-tLsnXUEglqze_mzEKyvgC9rpHp18Fmcuv3KYYMD6-c6_yBPMS5ocf4v-Hn-VBzJLs81g 443 BP1QiCgHIoFE8OHBBiZK3ynoqWEWskx_4Q1-8cDUprPmWYF0ik7LgnQwgoZKig-_AVqTma 444 ckYaRT1PjLW8ULgKBb6jgmkq-ge_yMGz0SM_i-ZbjPUIJb9WC5jqb7dXyXDALFEDiArv6n 445 a59mbieucYA0wKIWleuww0ci4hOfrnA-dQxPcMKYvw 447 (Line breaks for presentation only.) 449 5.3. Format of a SD-JWT Salt/Value Container (SVC) 451 Besides the SD-JWT itself, the holder needs to learn the raw claim 452 values that are contained in the SD-JWT, along with the precise input 453 to the hash calculation, and the salts. There MAY be other 454 information the issuer needs to communicate to the holder, such as a 455 private key if the issuer selected the holder key pair. 457 A SD-JWT Salt/Value Container (SVC) is a JSON object containing at 458 least the top-level property sd_release. Its structure mirrors the 459 one of sd_digests in the SD-JWT, but the values are the inputs to the 460 hash calculations the issuer used, as strings. 462 The SVC MAY contain further properties, for example, to transport the 463 holder private key. 465 5.4. Example: SVC for the Flat SD-JWT in Example 1 467 The SVC for Example 1 is as follows: 469 { 470 "sd_release": { 471 "sub": "[\"eluV5Og3gSNII8EYnsxA_A\", \"6c5c0a49-b589-431d-bae7-219122a9ec2c\"]", 472 "given_name": "[\"6Ij7tM-a5iVPGboS5tmvVA\", \"John\"]", 473 "family_name": "[\"eI8ZWm9QnKPpNPeNenHdhQ\", \"Doe\"]", 474 "email": "[\"Qg_O64zqAxe412a108iroA\", \"johndoe@example.com\"]", 475 "phone_number": "[\"AJx-095VPrpTtN4QMOqROA\", \"+1-202-555-0101\"]", 476 "address": "[\"Pc33JM2LchcU_lHggv_ufQ\", {\"street_address\": \"123 Main St\", \"locality\": \"Anytown\", \"region\": \"Anystate\", \"country\": \"US\"}]", 477 "birthdate": "[\"G02NSrQfjFXQ7Io09syajA\", \"1940-01-01\"]" 478 } 479 } 481 Important: As described above, hashes are calculated over the string 482 formed by serializing a JSON array containing the salt and the claim 483 value. This ensures that issuer and verifier use the same input to 484 their hash functions and avoids issues with canonicalization of JSON 485 values that would lead to different hash values. The SVC therefore 486 maps claim names to JSON-encoded arrays. 488 5.5. Sending SD-JWT and SVC during Issuance 490 For transporting the SVC together with the SD-JWT from the issuer to 491 the holder, the SVC is base64url-encoded and appended to the SD-JWT 492 using a period character . as the separator. For Example 1, the 493 combined format looks as follows: 495 eyJhbGciOiAiUlMyNTYifQ.eyJpc3MiOiAiaHR0cHM6Ly9leGFtcGxlLmNvbS9pc3N1ZXI 496 iLCAic3ViX2p3ayI6IHsia3R5IjogIlJTQSIsICJuIjogInBtNGJPSEJnLW9ZaEF5UFd6U 497 jU2QVdYM3JVSVhwMTFfSUNEa0dnUzZXM1pXTHRzLWh6d0kzeDY1NjU5a2c0aFZvOWRiR29 498 DSkUzWkdGX2VhZXRFMzBVaEJVRWdwR3dyRHJRaUo5enFwcm1jRmZyM3F2dmtHanR0aDhaZ 499 2wxZU0yYkpjT3dFN1BDQkhXVEtXWXMxNTJSN2c2SmcyT1ZwaC1hOHJxLXE3OU1oS0c1UW9 500 XX21UejEwUVRfNkg0YzdQaldHMWZqaDhocFdObmJQX3B2NmQxelN3WmZjNWZsNnlWUkwwR 501 FYwVjNsR0hLZTJXcWZfZU5HakJyQkxWa2xEVGs4LXN0WF9NV0xjUi1FR21YQU92MFVCV2l 502 0U19kWEpLSnUtdlhKeXcxNG5IU0d1eFRJSzJoeDFwdHRNZnQ5Q3N2cWltWEtlRFRVMTRxU 503 UwxZUU3aWhjdyIsICJlIjogIkFRQUIifSwgImlhdCI6IDE1MTYyMzkwMjIsICJleHAiOiA 504 xNTE2MjQ3MDIyLCAiX3NkIjogeyJzdWIiOiAiTGJuaGtPcjVvUzdLamVVcnhlekF1OFRHM 505 ENwV3owalNpeHk2dGZmdW8wNCIsICJnaXZlbl9uYW1lIjogImZVTWRuODhhYW95S1RIcnZ 506 aZDZBdUxtUHJhR2hQSjB6RjVyX0poeENWWnMiLCAiZmFtaWx5X25hbWUiOiAiOWg1dmd2N 507 lRwRlY2R21uUHR1Z2lNTGw1dEhldEhlYjVYXzJjS0hqTjdjdyIsICJlbWFpbCI6ICJmUFo 508 5MmR0WU1DTjJOYi0yYWNfelNIMTlwNHlha1VYclpsXy13U2dhYXpBIiwgInBob25lX251b 509 WJlciI6ICJRZFNmZnpOenpkMG42ME1zU211aUtqNlk2RW5rMmItQlMtS3RFZVBkZTVNIiw 510 gImFkZHJlc3MiOiAiSkZ1OTlOVVhQcTU1ZjZERkJaMjJyTWt4TU5IYXlDcmZQRzBGRHNxY 511 nlEcyIsICJiaXJ0aGRhdGUiOiAiSWExVGM2X1hudDVDSmMyTHRLY3U2V3ZxcjQyZ2xCR0d 512 jakdPeWU4WmYzVSJ9LCAiaGFzaF9hbGciOiAic2hhLTI1NiJ9.FfUbeF_py0aTQ6XHamsX 513 PNd0LopmZPXdA3iOaCpK9G11SUrzEo8BrmzsqHCbEIDXUxM_CXjslvBYaFF0J374Xwyuxw 514 t-tLsnXUEglqze_mzEKyvgC9rpHp18Fmcuv3KYYMD6-c6_yBPMS5ocf4v-Hn-VBzJLs81g 515 BP1QiCgHIoFE8OHBBiZK3ynoqWEWskx_4Q1-8cDUprPmWYF0ik7LgnQwgoZKig-_AVqTma 516 ckYaRT1PjLW8ULgKBb6jgmkq-ge_yMGz0SM_i-ZbjPUIJb9WC5jqb7dXyXDALFEDiArv6n 517 a59mbieucYA0wKIWleuww0ci4hOfrnA-dQxPcMKYvw.ewogICAgIl9zZCI6IHsKICAgICA 518 gICAic3ViIjogIltcImVsdVY1T2czZ1NOSUk4RVluc3hBX0FcIiwgXCI2YzVjMGE0OS1iN 519 Tg5LTQzMWQtYmFlNy0yMTkxMjJhOWVjMmNcIl0iLAogICAgICAgICJnaXZlbl9uYW1lIjo 520 gIltcIjZJajd0TS1hNWlWUEdib1M1dG12VkFcIiwgXCJKb2huXCJdIiwKICAgICAgICAiZ 521 mFtaWx5X25hbWUiOiAiW1wiZUk4WldtOVFuS1BwTlBlTmVuSGRoUVwiLCBcIkRvZVwiXSI 522 sCiAgICAgICAgImVtYWlsIjogIltcIlFnX082NHpxQXhlNDEyYTEwOGlyb0FcIiwgXCJqb 523 2huZG9lQGV4YW1wbGUuY29tXCJdIiwKICAgICAgICAicGhvbmVfbnVtYmVyIjogIltcIkF 524 KeC0wOTVWUHJwVHRONFFNT3FST0FcIiwgXCIrMS0yMDItNTU1LTAxMDFcIl0iLAogICAgI 525 CAgICJhZGRyZXNzIjogIltcIlBjMzNKTTJMY2hjVV9sSGdndl91ZlFcIiwge1wic3RyZWV 526 0X2FkZHJlc3NcIjogXCIxMjMgTWFpbiBTdFwiLCBcImxvY2FsaXR5XCI6IFwiQW55dG93b 527 lwiLCBcInJlZ2lvblwiOiBcIkFueXN0YXRlXCIsIFwiY291bnRyeVwiOiBcIlVTXCJ9XSI 528 sCiAgICAgICAgImJpcnRoZGF0ZSI6ICJbXCJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBXCIsI 529 FwiMTk0MC0wMS0wMVwiXSIKICAgIH0KfQ 531 (Line breaks for presentation only.) 533 5.6. Format of an SD-JWT Release 535 SD-JWT-R contains claim values and the salts of the claims that the 536 holder has consented to release to the Verifier. This enables the 537 Verifier to verify the claims received from the holder by computing 538 the hash sof the claims values and the salts revealed in the SD-JWT-R 539 using the hashing algorithm specified in SD-JWT and comparing them to 540 the hash valued included in SD-JWT. 542 For each claim, an array of the salt and the claim value is contained 543 in the _sd object. The structure of _sd object in the SD-JWT-R is 544 the same as in SD-JWT. 546 The SD-JWT-R MAY contain further claims, for example, to ensure a 547 binding to a concrete transaction (in the example the nonce and aud 548 claims). 550 When the holder sends the SD-JWT-R to the Verifier, the SD-JWT-R MUST 551 be a JWS represented as the JWS Compact Serialization as described in 552 Section 7.1 of [RFC7515]. 554 If holder binding is desired, the SD-JWT-R is signed by the holder. 555 If no holder binding is to be used, the none algorithm is used, i.e., 556 the document is not signed. TODO: Change to plain base64 to avoid 557 alg=none issues 559 5.7. Example: SD-JWT Release for Example 1 561 The following is a non-normative example of the contents of an SD- 562 JWT-R for Example 1: 564 { 565 "nonce": "2GLC42sKQveCfGfryNRN9w", 566 "aud": "https://example.com/verifier", 567 "sd_release": { 568 "given_name": "[\"6Ij7tM-a5iVPGboS5tmvVA\", \"John\"]", 569 "family_name": "[\"eI8ZWm9QnKPpNPeNenHdhQ\", \"Doe\"]", 570 "address": "[\"Pc33JM2LchcU_lHggv_ufQ\", {\"street_address\": \"123 Main St\", \"locality\": \"Anytown\", \"region\": \"Anystate\", \"country\": \"US\"}]" 571 } 572 } 574 For each claim, an array of the salt and the claim value is contained 575 in the sd_release object. 577 Again, the SD-JWT-R follows the same structure as the sd_digests in 578 the SD-JWT. 580 Below is a non-normative example of a representation of the SD-JWT-R 581 JWS Compact Serialization: 583 eyJhbGciOiAiUlMyNTYifQ.eyJub25jZSI6ICIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3Iiw 584 gImF1ZCI6ICJodHRwczovL2V4YW1wbGUuY29tL3ZlcmlmaWVyIiwgIl9zZCI6IHsiZ2l2Z 585 W5fbmFtZSI6ICJbXCI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBXCIsIFwiSm9oblwiXSIsICJ 586 mYW1pbHlfbmFtZSI6ICJbXCJlSThaV205UW5LUHBOUGVOZW5IZGhRXCIsIFwiRG9lXCJdI 587 iwgImFkZHJlc3MiOiAiW1wiUGMzM0pNMkxjaGNVX2xIZ2d2X3VmUVwiLCB7XCJzdHJlZXR 588 fYWRkcmVzc1wiOiBcIjEyMyBNYWluIFN0XCIsIFwibG9jYWxpdHlcIjogXCJBbnl0b3duX 589 CIsIFwicmVnaW9uXCI6IFwiQW55c3RhdGVcIiwgXCJjb3VudHJ5XCI6IFwiVVNcIn1dIn1 590 9.b0hG3v71rzHvtoDTdroZ9m-lt9tf8nobFKb2YGiyGOjIklfcKc2KWj72oi_tBKcOCqZh 591 dX6IV4BRXIw-aspQfLh-xBrNLuGqiC-Y3rZBBlWw0WWnbbtsy1tj8yZOiXBr8vO6mCgZGA 592 d4MgPYPd-QzOr9ukObYDRB4I24xHrqlAEYPJIzSw9MI_dEmIkNnAuIfLQKiuyTqVVVp6Ly 593 pBIz6fBLm6NOLC4-uVXlOzI91iT4zlkrhP0-vj8TmfB-XL9aD3-xqytvLBHTESct49OSRZ 594 FrwkLUKTM56_6KW3pG7Ucuv8VnpHXHIka0SGRaOh8x6v5-rCQJl_IbM8wb7CSHvQ 596 (Line breaks for presentation only.) 598 5.8. Sending SD-JWT and SD-JWT-R during Presentation 600 The SD-JWT and the SD-JWT-R can be combined into one document using 601 period character . as a separator (here for Example 1): 603 eyJhbGciOiAiUlMyNTYifQ.eyJpc3MiOiAiaHR0cHM6Ly9leGFtcGxlLmNvbS9pc3N1ZXI 604 iLCAic3ViX2p3ayI6IHsia3R5IjogIlJTQSIsICJuIjogInBtNGJPSEJnLW9ZaEF5UFd6U 605 jU2QVdYM3JVSVhwMTFfSUNEa0dnUzZXM1pXTHRzLWh6d0kzeDY1NjU5a2c0aFZvOWRiR29 606 DSkUzWkdGX2VhZXRFMzBVaEJVRWdwR3dyRHJRaUo5enFwcm1jRmZyM3F2dmtHanR0aDhaZ 607 2wxZU0yYkpjT3dFN1BDQkhXVEtXWXMxNTJSN2c2SmcyT1ZwaC1hOHJxLXE3OU1oS0c1UW9 608 XX21UejEwUVRfNkg0YzdQaldHMWZqaDhocFdObmJQX3B2NmQxelN3WmZjNWZsNnlWUkwwR 609 FYwVjNsR0hLZTJXcWZfZU5HakJyQkxWa2xEVGs4LXN0WF9NV0xjUi1FR21YQU92MFVCV2l 610 0U19kWEpLSnUtdlhKeXcxNG5IU0d1eFRJSzJoeDFwdHRNZnQ5Q3N2cWltWEtlRFRVMTRxU 611 UwxZUU3aWhjdyIsICJlIjogIkFRQUIifSwgImlhdCI6IDE1MTYyMzkwMjIsICJleHAiOiA 612 xNTE2MjQ3MDIyLCAiX3NkIjogeyJzdWIiOiAiTGJuaGtPcjVvUzdLamVVcnhlekF1OFRHM 613 ENwV3owalNpeHk2dGZmdW8wNCIsICJnaXZlbl9uYW1lIjogImZVTWRuODhhYW95S1RIcnZ 614 aZDZBdUxtUHJhR2hQSjB6RjVyX0poeENWWnMiLCAiZmFtaWx5X25hbWUiOiAiOWg1dmd2N 615 lRwRlY2R21uUHR1Z2lNTGw1dEhldEhlYjVYXzJjS0hqTjdjdyIsICJlbWFpbCI6ICJmUFo 616 5MmR0WU1DTjJOYi0yYWNfelNIMTlwNHlha1VYclpsXy13U2dhYXpBIiwgInBob25lX251b 617 WJlciI6ICJRZFNmZnpOenpkMG42ME1zU211aUtqNlk2RW5rMmItQlMtS3RFZVBkZTVNIiw 618 gImFkZHJlc3MiOiAiSkZ1OTlOVVhQcTU1ZjZERkJaMjJyTWt4TU5IYXlDcmZQRzBGRHNxY 619 nlEcyIsICJiaXJ0aGRhdGUiOiAiSWExVGM2X1hudDVDSmMyTHRLY3U2V3ZxcjQyZ2xCR0d 620 jakdPeWU4WmYzVSJ9LCAiaGFzaF9hbGciOiAic2hhLTI1NiJ9.FfUbeF_py0aTQ6XHamsX 621 PNd0LopmZPXdA3iOaCpK9G11SUrzEo8BrmzsqHCbEIDXUxM_CXjslvBYaFF0J374Xwyuxw 622 t-tLsnXUEglqze_mzEKyvgC9rpHp18Fmcuv3KYYMD6-c6_yBPMS5ocf4v-Hn-VBzJLs81g 623 BP1QiCgHIoFE8OHBBiZK3ynoqWEWskx_4Q1-8cDUprPmWYF0ik7LgnQwgoZKig-_AVqTma 624 ckYaRT1PjLW8ULgKBb6jgmkq-ge_yMGz0SM_i-ZbjPUIJb9WC5jqb7dXyXDALFEDiArv6n 625 a59mbieucYA0wKIWleuww0ci4hOfrnA-dQxPcMKYvw.eyJhbGciOiAiUlMyNTYifQ.eyJu 626 b25jZSI6ICIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImF1ZCI6ICJodHRwczovL2V4YW 627 1wbGUuY29tL3ZlcmlmaWVyIiwgIl9zZCI6IHsiZ2l2ZW5fbmFtZSI6ICJbXCI2SWo3dE0t 628 YTVpVlBHYm9TNXRtdlZBXCIsIFwiSm9oblwiXSIsICJmYW1pbHlfbmFtZSI6ICJbXCJlST 629 haV205UW5LUHBOUGVOZW5IZGhRXCIsIFwiRG9lXCJdIiwgImFkZHJlc3MiOiAiW1wiUGMz 630 M0pNMkxjaGNVX2xIZ2d2X3VmUVwiLCB7XCJzdHJlZXRfYWRkcmVzc1wiOiBcIjEyMyBNYW 631 luIFN0XCIsIFwibG9jYWxpdHlcIjogXCJBbnl0b3duXCIsIFwicmVnaW9uXCI6IFwiQW55 632 c3RhdGVcIiwgXCJjb3VudHJ5XCI6IFwiVVNcIn1dIn19.b0hG3v71rzHvtoDTdroZ9m-lt 633 9tf8nobFKb2YGiyGOjIklfcKc2KWj72oi_tBKcOCqZhdX6IV4BRXIw-aspQfLh-xBrNLuG 634 qiC-Y3rZBBlWw0WWnbbtsy1tj8yZOiXBr8vO6mCgZGAd4MgPYPd-QzOr9ukObYDRB4I24x 635 HrqlAEYPJIzSw9MI_dEmIkNnAuIfLQKiuyTqVVVp6LypBIz6fBLm6NOLC4-uVXlOzI91iT 636 4zlkrhP0-vj8TmfB-XL9aD3-xqytvLBHTESct49OSRZFrwkLUKTM56_6KW3pG7Ucuv8Vnp 637 HXHIka0SGRaOh8x6v5-rCQJl_IbM8wb7CSHvQ 639 (Line breaks for presentation only.) 641 6. Verification 643 Verifiers MUST follow [RFC8725] for checking the SD-JWT and, if 644 signed, the SD-JWT Release. 646 Verifiers MUST go through (at least) the following steps before 647 trusting/using any of the contents of an SD-JWT: 649 1. Determine if holder binding is to be checked for the SD-JWT. 650 Refer to Section 7.5 for details. 652 2. Check that the presentation consists of six period-separated (.) 653 elements; if holder binding is not required, the last element can 654 be empty. 656 3. Separate the SD-JWT from the SD-JWT Release. 658 4. Validate the SD-JWT: 660 1. Ensure that a signing algorithm was used that was deemed 661 secure for the application. Refer to [RFC8725], Sections 3.1 662 and 3.2 for details. 664 2. Validate the signature over the SD-JWT. 666 3. Validate the issuer of the SD-JWT and that the signing key 667 belongs to this issuer. 669 4. Check that the SD-JWT is valid using nbf, iat, and exp 670 claims, if provided in the SD-JWT. 672 5. Check that the claim sd_digests is present in the SD-JWT. 674 6. Check that the hash_alg claim is present and its value is 675 understand and the hash algorithm deemed secure. 677 5. Validate the SD-JWT Release: 679 1. If holder binding is required, validate the signature over 680 the SD-JWT using the same steps as for the SD-JWT plus the 681 following steps: 683 1. Determine that the public key for the private key that 684 used to sign the SD-JWT-R is bound to the SD-JWT, i.e., 685 the SD-JWT either contains a reference to the public key 686 or contains the public key itself. 688 2. Determine that the SD-JWT-R is bound to the current 689 transaction and was created for this verifier (replay 690 protection). This is usually achieved by a nonce and aud 691 field within the SD-JWT Release. 693 2. For each claim in the SD-JWT Release: 695 1. Ensure that the claim is present as well in sd_release in 696 the SD-JWT. If sd_release is structured, the claim MUST 697 be present at the same place within the structure. 699 2. Compute the base64url-encoded hash of a claim revealed 700 from the Holder using the claim value and the salt 701 included in the SD-JWT-R and the hash_alg in SD-JWT. 703 3. Compare the hah computed in the previous step with the 704 hash of the same claim in SD-JWT. Accept the claim only 705 when the two hashes match. 707 4. Ensure that the claim value in the SD-JWT-R is a JSON- 708 encoded array of exactly two values. 710 5. Store the second of the two values. 712 3. Once all necessary claims have been verified, their values 713 can be validated and used according to the requirements of 714 the application. It MUST be ensured that all claims required 715 for the application have been released. 717 If any step fails, the input is not valid and processing MUST be 718 aborted. 720 7. Security Considerations 722 7.1. Mandatory signing of the SD-JWT 724 The SD-JWT MUST be signed by the issuer to protect integrity of the 725 issued claims. An attacker can modify or add claims if an SD-JWT is 726 not signed (e.g., change the "email" attribute to take over the 727 victim's account or add an attribute indicating a fake academic 728 qualification). 730 The verifier MUST always check the SD-JWT signature to ensure that 731 the SD-JWT has not been tampered with since its issuance. If the 732 signature on the SD-JWT cannot be verified, the SD-JWT MUST be 733 rejected. 735 7.2. Entropy of the salt 737 The security model relies on the fact that the salt is not learned or 738 guessed by the attacker. It is vitally important to adhere to this 739 principle. As such, the salt has to be created in such a manner that 740 it is cryptographically random, long enough and has high entropy that 741 it is not practical for the attacker to guess. 743 7.3. Minimum length of the salt 745 The length of the randomly-generated portion of the salt MUST be at 746 least 128 bits. 748 7.4. Choice of a hash function 750 For the security of this scheme, the hash function is required to 751 have the following property. Given a claim value, a salt, and the 752 resulting hash, it is hard to find a second salt value so that 753 HASH(salt | claim_value) equals the hash. 755 Furthermore the hash algorithms MD2, MD4, MD5, RIPEMD-160, and SHA-1 756 revealed fundamental weaknesses and they MUST NOT be used. 758 7.5. Holder Binding 760 TBD 762 8. Privacy Considerations 764 8.1. Claim Names 766 Claim names are not hashed in the SD-JWT and are used as keys in a 767 key-value pair, where the value is the hash. This is because SD-JWT 768 already reveals information about the issuer and the schema, and 769 revealing the claim names does not provide any additional 770 information. 772 8.2. Unlinkability 774 It is also important to note that this format enables selective 775 disclosure of claims, but in itself it does not achieve unlinkability 776 of the subject of an SD-SWT. 778 9. Acknowledgements 780 We would like to thank ... 782 10. IANA Considerations 784 TBD 786 11. Normative References 788 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 789 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 790 . 792 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 793 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 794 2015, . 796 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 797 Requirement Levels", BCP 14, RFC 2119, 798 DOI 10.17487/RFC2119, March 1997, 799 . 801 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 802 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 803 May 2017, . 805 12. Informative References 807 [RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best 808 Current Practices", BCP 225, RFC 8725, 809 DOI 10.17487/RFC8725, February 2020, 810 . 812 [VC_DATA] Sporny, M., Noble, G., Longley, D., Burnett, D. C., 813 Zundel, B., and D. Chadwick, "Verifiable Credentials Data 814 Model 1.0", 19 November 2019, 815 . 817 Appendix A. Additional Examples 819 A.1. Example 2 - Structured SD-JWT 821 This non-normative example is based on the same claim values as 822 Example 1, but this time the issuer decided to create a structured 823 object for the hashes. This allows for the release of individual 824 members of the address claim separately. 826 { 827 "iss": "https://example.com/issuer", 828 "sub_jwk": { 829 "kty": "RSA", 830 "n": "pcHdUSmbR3A8_eJcxaOWtk8wmrsxP7Fpl1DYVeNJRRYBS2kHLewBLAG4CpZDAB-AuuIkaGRyJdcISfN0Ujk4dBryUtdDvpJ-h4en-Zurrn_aQxF4VApBtgdWjzRksrBnzmp64_S89rsl6h-We-yKsVtmm4IB9Jr-9VlVRg03EXWMAmwUaQkDiKEhXxQH2f8QhNfhTOKAKb58AYwgz-CtzOQjr6p7o9yisDu2LtFi9RkctE1MZ8If3PPs7G53-GBL_7lH9kKuqUsXZQzBvBJl5AYf3beKS6QH1aPnFgZ-2a5lsEuKp44NMIT2h-uQd5eQ0bhQkPVeH7Yi-tGxMnaDdQ", 831 }, 832 "hash_alg": "sha-256", 833 "iat": 1516239022, 834 "exp": 1516247022, 835 "sd_digests": { 836 "sub": "LbnhkOr5oS7KjeUrxezAu8TG0CpWz0jSixy6tffuo04", 837 "given_name": "fUMdn88aaoyKTHrvZd6AuLmPraGhPJ0zF5r_JhxCVZs", 838 "family_name": "9h5vgv6TpFV6GmnPtugiMLl5tHetHeb5X_2cKHjN7cw", 839 "email": "fPZ92dtYMCN2Nb-2ac_zSH19p4yakUXrZl_-wSgaazA", 840 "phone_number": "QdSffzNzzd0n60MsSmuiKj6Y6Enk2b-BS-KtEePde5M", 841 "address": { 842 "street_address": "4FpVpd563Owh9G3HkGNTN9FiSHT0e6y9-Abk_IuG86M", 843 "locality": "Kr0BpdZz6yU8HMhjyYHh1EEgJxeUyLIpJEi47iXhp8Y", 844 "region": "QXxWKvcV4Bc9t3M7MF43W5vdCnWtA9hsYX8ycWLu1LQ", 845 "country": "3itkoMzrDrinn7T0MUbAmrMm1ya1LzbBgif_50WoFOs" 846 }, 847 "birthdate": "fvLCnDm3r4VSYcBF3pIlXP4ulEoHuHOfG_YmFZEuxpQ" 848 }, 849 "hash_alg": "sha-256" 850 } 852 The SVC for this SD-JWT is as follows: 854 { 855 "sd_release": { 856 "sub": "[\"eluV5Og3gSNII8EYnsxA_A\", \"6c5c0a49-b589-431d-bae7-219122a9ec2c\"]", 857 "given_name": "[\"6Ij7tM-a5iVPGboS5tmvVA\", \"John\"]", 858 "family_name": "[\"eI8ZWm9QnKPpNPeNenHdhQ\", \"Doe\"]", 859 "email": "[\"Qg_O64zqAxe412a108iroA\", \"johndoe@example.com\"]", 860 "phone_number": "[\"AJx-095VPrpTtN4QMOqROA\", \"+1-202-555-0101\"]", 861 "address": { 862 "street_address": "[\"Pc33JM2LchcU_lHggv_ufQ\", \"123 Main St\"]", 863 "locality": "[\"G02NSrQfjFXQ7Io09syajA\", \"Anytown\"]", 864 "region": "[\"lklxF5jMYlGTPUovMNIvCA\", \"Anystate\"]", 865 "country": "[\"nPuoQnkRFq3BIeAm7AnXFA\", \"US\"]" 866 }, 867 "birthdate": "[\"5bPs1IquZNa0hkaFzzzZNw\", \"1940-01-01\"]" 868 } 869 } 871 An SD-JWT-R for the SD-JWT above that discloses only region and 872 country of the address property: 874 { 875 "nonce": "2GLC42sKQveCfGfryNRN9w", 876 "aud": "https://example.com/verifier", 877 "sd_release": { 878 "given_name": "[\"6Ij7tM-a5iVPGboS5tmvVA\", \"John\"]", 879 "family_name": "[\"eI8ZWm9QnKPpNPeNenHdhQ\", \"Doe\"]", 880 "birthdate": "[\"5bPs1IquZNa0hkaFzzzZNw\", \"1940-01-01\"]", 881 "address": { 882 "region": "[\"lklxF5jMYlGTPUovMNIvCA\", \"Anystate\"]", 883 "country": "[\"nPuoQnkRFq3BIeAm7AnXFA\", \"US\"]" 884 } 885 } 886 } 888 A.2. Example 3 - Complex Structured SD-JWT 890 In this example, a complex object such as those used for OIDC4IDA 891 (todo reference) is used. 893 In this example, the Issuer is using a following object as a set of 894 claims to issue to the Holder: 896 { 897 "verified_claims": { 898 "verification": { 899 "trust_framework": "de_aml", 900 "time": "2012-04-23T18:25Z", 901 "verification_process": "f24c6f-6d3f-4ec5-973e-b0d8506f3bc7", 902 "evidence": [ 903 { 904 "type": "document", 905 "method": "pipp", 906 "time": "2012-04-22T11:30Z", 907 "document": { 908 "type": "idcard", 909 "issuer": { 910 "name": "Stadt Augsburg", 911 "country": "DE" 912 }, 913 "number": "53554554", 914 "date_of_issuance": "2010-03-23", 915 "date_of_expiry": "2020-03-22" 916 } 917 } 918 ] 919 }, 920 "claims": { 921 "given_name": "Max", 922 "family_name": "Meier", 923 "birthdate": "1956-01-28", 924 "place_of_birth": { 925 "country": "DE", 926 "locality": "Musterstadt" 927 }, 928 "nationalities": [ 929 "DE" 930 ], 931 "address": { 932 "locality": "Maxstadt", 933 "postal_code": "12344", 934 "country": "DE", 935 "street_address": "An der Weide 22" 936 } 937 } 938 }, 939 "birth_middle_name": "Timotheus", 940 "salutation": "Dr.", 941 "msisdn": "49123456789" 942 } 943 The following shows the resulting SD-JWT payload: 945 { 946 "iss": "https://example.com/issuer", 947 "sub_jwk": { 948 "kty": "RSA", 949 "n": "6bh1cbaN-fyTUTfawCabGpTSeHOWmsHuB-VZ0aoAKBAfH6MOeLolLYLMcgP1VCNa1CenudLRzm8ULvinMicmfCOumvyhq8wsgH1jIJDG_TVrupS6iZvthOtXPpkSXxDiiLxgmnLR5AlpWBKjrzXmX1jQ2V1gQlC2S2eN7t_CR-Jfj3yb4rTW20UyvhpOpy649CaYsAo3Ulq2oJpnG6rInX_XzYH86plJmYDUq07SoGIcdYYK6IyudZBh2bVxZ9aBuvkYQy11AFvXk2BP0RbTP1aOwwzS-LWahQJdsK5OiPLRrfTZ399h2I24VW3qXT2Zusq9tUNAlOWvh1K7umnpMw", 950 "e": "AQAB" 951 }, 952 "hash_alg": "sha-256", 953 "iat": 1516239022, 954 "exp": 1516247022, 955 "sd_digests": { 956 "verified_claims": { 957 "verification": { 958 "trust_framework": "UI-SRNlQFy-YEFE46yyHKqc64jmM65q8ma9cq2V_erY", 959 "time": "jI-FYlteydXzsjRIrXBZs9foBSNF1Od1Q-4XnuqpgjI", 960 "verification_process": "F979I7b5ZhADtyYMlYxctdc9-IalD_Td0HpfcFBzVXs", 961 "evidence": [ 962 { 963 "type": "i2w3mrKAQV2nhTa5c2koZ-aQTBDoSaVfvYk7aLQianc", 964 "method": "fEQ0tVPD67GfO30h_SRs8ZPbnZ_vwEt5S8lUOR77va0", 965 "time": "9jueDP5r0gTB64DqdCZbek3yaS5AJJnW8FEkWtPTaOk", 966 "document": { 967 "type": "K-rZQk89w89YBhjUNUho07suLxhG8Sl2JTPAcoAJB34", 968 "issuer": { 969 "name": "BkCULCU-txVGvzNqnWe5DxefFvJE8LMib8GV3I3WO90", 970 "country": "DSyF5TtmYgLk92u4GkDQzSdFbvIbw5rkFjzSsJJsyw4" 971 }, 972 "number": "epH3OuU51TBelOE4PX6ueHwr1ZtoUjzG-7pZjIAsXg8", 973 "date_of_issuance": "cVvqTueVq6OWz-dJj2cdo19A0Ajj859eGDzDfwPYyN4", 974 "date_of_expiry": "nxJBNdtwvb2TKKJNGvF6_1ywEdKrotj66C88WPomLfo" 975 } 976 } 977 ] 978 }, 979 "claims": { 980 "given_name": "y9uFPHAVqNAZ7PJyk1-1yQJZZWZzKGP5FLt9txKM84M", 981 "family_name": "XyUikY8V8MWeBfXUOp8gI7F7-yC28Jr5IyDgvBxXzd4", 982 "birthdate": "7GlieMLJhM78C_uQQp9wUXSZLeqBN1YGQT87BIubyKU", 983 "place_of_birth": { 984 "country": "RN3xcnLYX_GDhVwfPvtisuLPfi0d74zqihFbQrd_UG0", 985 "locality": "iNkpWqJ9kIZQq95dzSyEZjbPJs6Fqu7GFBKouEC3OxE" 986 }, 987 "nationalities": "-tinYGK0GXnkfARxiNIWq0VnzNRl-Kv3KY3m5g5Femg", 988 "address": "63EzPV0yvTpeOgV34yCwweCvO-2wxts2Wqbja_SuwPQ" 989 } 990 }, 991 "birth_middle_name": "vM68I6XnrVlyt1LxK9xxgFycsjtw2vLdGpNgk3E8QQ4", 992 "salutation": "iThfCu2ulLoe5i6gCEq--Y6R-gxHHtIukXb9qnfjH5k", 993 "msisdn": "xUpU-azBYdXeJidc8Yw5MXtfPz4_4kArJhflXcxzkzs" 994 }, 995 "hash_alg": "sha-256" 996 } 998 The SD-JWT is then signed by the issuer to create a document like the 999 following: 1001 eyJhbGciOiAiUlMyNTYifQ.eyJpc3MiOiAiaHR0cHM6Ly9leGFtcGxlLmNvbS9pc3N1ZXI 1002 iLCAic3ViX2p3ayI6IHsia3R5IjogIlJTQSIsICJuIjogIjZiaDFjYmFOLWZ5VFVUZmF3Q 1003 2FiR3BUU2VIT1dtc0h1Qi1WWjBhb0FLQkFmSDZNT2VMb2xMWUxNY2dQMVZDTmExQ2VudWR 1004 MUnptOFVMdmluTWljbWZDT3VtdnlocTh3c2dIMWpJSkRHX1RWcnVwUzZpWnZ0aE90WFBwa 1005 1NYeERpaUx4Z21uTFI1QWxwV0JLanJ6WG1YMWpRMlYxZ1FsQzJTMmVON3RfQ1ItSmZqM3l 1006 iNHJUVzIwVXl2aHBPcHk2NDlDYVlzQW8zVWxxMm9KcG5HNnJJblhfWHpZSDg2cGxKbVlEV 1007 XEwN1NvR0ljZFlZSzZJeXVkWkJoMmJWeFo5YUJ1dmtZUXkxMUFGdlhrMkJQMFJiVFAxYU9 1008 3d3pTLUxXYWhRSmRzSzVPaVBMUnJmVFozOTloMkkyNFZXM3FYVDJadXNxOXRVTkFsT1d2a 1009 DFLN3VtbnBNdyIsICJlIjogIkFRQUIifSwgImlhdCI6IDE1MTYyMzkwMjIsICJleHAiOiA 1010 xNTE2MjQ3MDIyLCAiX3NkIjogeyJ2ZXJpZmllZF9jbGFpbXMiOiB7InZlcmlmaWNhdGlvb 1011 iI6IHsidHJ1c3RfZnJhbWV3b3JrIjogIlVJLVNSTmxRRnktWUVGRTQ2eXlIS3FjNjRqbU0 1012 2NXE4bWE5Y3EyVl9lclkiLCAidGltZSI6ICJqSS1GWWx0ZXlkWHpzalJJclhCWnM5Zm9CU 1013 05GMU9kMVEtNFhudXFwZ2pJIiwgInZlcmlmaWNhdGlvbl9wcm9jZXNzIjogIkY5NzlJN2I 1014 1WmhBRHR5WU1sWXhjdGRjOS1JYWxEX1RkMEhwZmNGQnpWWHMiLCAiZXZpZGVuY2UiOiBbe 1015 yJ0eXBlIjogImkydzNtcktBUVYybmhUYTVjMmtvWi1hUVRCRG9TYVZmdllrN2FMUWlhbmM 1016 iLCAibWV0aG9kIjogImZFUTB0VlBENjdHZk8zMGhfU1JzOFpQYm5aX3Z3RXQ1UzhsVU9SN 1017 zd2YTAiLCAidGltZSI6ICI5anVlRFA1cjBnVEI2NERxZENaYmVrM3lhUzVBSkpuVzhGRWt 1018 XdFBUYU9rIiwgImRvY3VtZW50IjogeyJ0eXBlIjogIkstclpRazg5dzg5WUJoalVOVWhvM 1019 DdzdUx4aEc4U2wySlRQQWNvQUpCMzQiLCAiaXNzdWVyIjogeyJuYW1lIjogIkJrQ1VMQ1U 1020 tdHhWR3Z6TnFuV2U1RHhlZkZ2SkU4TE1pYjhHVjNJM1dPOTAiLCAiY291bnRyeSI6ICJEU 1021 3lGNVR0bVlnTGs5MnU0R2tEUXpTZEZidklidzVya0ZqelNzSkpzeXc0In0sICJudW1iZXI 1022 iOiAiZXBIM091VTUxVEJlbE9FNFBYNnVlSHdyMVp0b1VqekctN3BaaklBc1hnOCIsICJkY 1023 XRlX29mX2lzc3VhbmNlIjogImNWdnFUdWVWcTZPV3otZEpqMmNkbzE5QTBBamo4NTllR0R 1024 6RGZ3UFl5TjQiLCAiZGF0ZV9vZl9leHBpcnkiOiAibnhKQk5kdHd2YjJUS0tKTkd2RjZfM 1025 Xl3RWRLcm90ajY2Qzg4V1BvbUxmbyJ9fV19LCAiY2xhaW1zIjogeyJnaXZlbl9uYW1lIjo 1026 gInk5dUZQSEFWcU5BWjdQSnlrMS0xeVFKWlpXWnpLR1A1Rkx0OXR4S004NE0iLCAiZmFta 1027 Wx5X25hbWUiOiAiWHlVaWtZOFY4TVdlQmZYVU9wOGdJN0Y3LXlDMjhKcjVJeURndkJ4WHp 1028 kNCIsICJiaXJ0aGRhdGUiOiAiN0dsaWVNTEpoTTc4Q191UVFwOXdVWFNaTGVxQk4xWUdRV 1029 Dg3Qkl1YnlLVSIsICJwbGFjZV9vZl9iaXJ0aCI6IHsiY291bnRyeSI6ICJSTjN4Y25MWVh 1030 fR0RoVndmUHZ0aXN1TFBmaTBkNzR6cWloRmJRcmRfVUcwIiwgImxvY2FsaXR5IjogImlOa 1031 3BXcUo5a0laUXE5NWR6U3lFWmpiUEpzNkZxdTdHRkJLb3VFQzNPeEUifSwgIm5hdGlvbmF 1032 saXRpZXMiOiAiLXRpbllHSzBHWG5rZkFSeGlOSVdxMFZuek5SbC1LdjNLWTNtNWc1RmVtZ 1033 yIsICJhZGRyZXNzIjogIjYzRXpQVjB5dlRwZU9nVjM0eUN3d2VDdk8tMnd4dHMyV3FiamF 1034 fU3V3UFEifX0sICJiaXJ0aF9taWRkbGVfbmFtZSI6ICJ2TTY4STZYbnJWbHl0MUx4Szl4e 1035 GdGeWNzanR3MnZMZEdwTmdrM0U4UVE0IiwgInNhbHV0YXRpb24iOiAiaVRoZkN1MnVsTG9 1036 lNWk2Z0NFcS0tWTZSLWd4SEh0SXVrWGI5cW5makg1ayIsICJtc2lzZG4iOiAieFVwVS1he 1037 kJZZFhlSmlkYzhZdzVNWHRmUHo0XzRrQXJKaGZsWGN4emt6cyJ9LCAiaGFzaF9hbGciOiA 1038 ic2hhLTI1NiJ9.Z1w9pHuA1sZoCUonBBOfA93f9AAriL0NM3g2-0x6hT6Syo3t52BOONED 1039 lNuvJhGMEnemR8Up5nAYzmZfVCQWCy8In729hH_A-Pn1YnZ4m3mYhYw65U0Z9-MlF5guBD 1040 GM6X7gcGf-3O2wnIRquFJ4au3pES6oZbXYpIHFojjbW8YUy_ZFDNUTVOk4uzTrIcJFocsY 1041 zWr0QQe4WB5EIv8k5LToW_gCopEVQbQ3db9g-Cxtfi9GaCGFcHeANXwa8Z_mg4weYXc3Fz 1042 z4DFKFpU2WhjXZ6g0wLS0AHHqE3d8FF7iZyFq9sXI9_N07YnU7D1wkWzpkCwEp-bop0SK8 1043 DKGUXA.ewogICAgIl9zZCI6IHsKICAgICAgICAidmVyaWZpZWRfY2xhaW1zIjogewogICA 1044 gICAgICAgICAidmVyaWZpY2F0aW9uIjogewogICAgICAgICAgICAgICAgInRydXN0X2ZyY 1045 W1ld29yayI6ICJbXCJlbHVWNU9nM2dTTklJOEVZbnN4QV9BXCIsIFwiZGVfYW1sXCJdIiw 1046 KICAgICAgICAgICAgICAgICJ0aW1lIjogIltcIjZJajd0TS1hNWlWUEdib1M1dG12VkFcI 1047 iwgXCIyMDEyLTA0LTIzVDE4OjI1WlwiXSIsCiAgICAgICAgICAgICAgICAidmVyaWZpY2F 1048 0aW9uX3Byb2Nlc3MiOiAiW1wiZUk4WldtOVFuS1BwTlBlTmVuSGRoUVwiLCBcImYyNGM2Z 1049 i02ZDNmLTRlYzUtOTczZS1iMGQ4NTA2ZjNiYzdcIl0iLAogICAgICAgICAgICAgICAgImV 1050 2aWRlbmNlIjogWwogICAgICAgICAgICAgICAgICAgIHsKICAgICAgICAgICAgICAgICAgI 1051 CAgICAgInR5cGUiOiAiW1wiUWdfTzY0enFBeGU0MTJhMTA4aXJvQVwiLCBcImRvY3VtZW5 1052 0XCJdIiwKICAgICAgICAgICAgICAgICAgICAgICAgIm1ldGhvZCI6ICJbXCJBSngtMDk1V 1053 lBycFR0TjRRTU9xUk9BXCIsIFwicGlwcFwiXSIsCiAgICAgICAgICAgICAgICAgICAgICA 1054 gICJ0aW1lIjogIltcIlBjMzNKTTJMY2hjVV9sSGdndl91ZlFcIiwgXCIyMDEyLTA0LTIyV 1055 DExOjMwWlwiXSIsCiAgICAgICAgICAgICAgICAgICAgICAgICJkb2N1bWVudCI6IHsKICA 1056 gICAgICAgICAgICAgICAgICAgICAgICAgICJ0eXBlIjogIltcIkcwMk5TclFmakZYUTdJb 1057 zA5c3lhakFcIiwgXCJpZGNhcmRcIl0iLAogICAgICAgICAgICAgICAgICAgICAgICAgICA 1058 gImlzc3VlciI6IHsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAibmFtZSI6I 1059 CJbXCJsa2x4RjVqTVlsR1RQVW92TU5JdkNBXCIsIFwiU3RhZHQgQXVnc2J1cmdcIl0iLAo 1060 gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICJjb3VudHJ5IjogIltcIm5QdW9Rb 1061 mtSRnEzQkllQW03QW5YRkFcIiwgXCJERVwiXSIKICAgICAgICAgICAgICAgICAgICAgICA 1062 gICAgIH0sCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAibnVtYmVyIjogIltcIjViU 1063 HMxSXF1Wk5hMGhrYUZ6enpaTndcIiwgXCI1MzU1NDU1NFwiXSIsCiAgICAgICAgICAgICA 1064 gICAgICAgICAgICAgICAiZGF0ZV9vZl9pc3N1YW5jZSI6ICJbXCI1YTJXMF9OcmxFWnpmc 1065 W1rXzdQcS13XCIsIFwiMjAxMC0wMy0yM1wiXSIsCiAgICAgICAgICAgICAgICAgICAgICA 1066 gICAgICAiZGF0ZV9vZl9leHBpcnkiOiAiW1wieTFzVlU1d2RmSmFoVmRnd1BnUzdSUVwiL 1067 CBcIjIwMjAtMDMtMjJcIl0iCiAgICAgICAgICAgICAgICAgICAgICAgIH0KICAgICAgICA 1068 gICAgICAgICAgICB9CiAgICAgICAgICAgICAgICBdCiAgICAgICAgICAgIH0sCiAgICAgI 1069 CAgICAgICJjbGFpbXMiOiB7CiAgICAgICAgICAgICAgICAiZ2l2ZW5fbmFtZSI6ICJbXCJ 1070 IYlE0WDhzclZXM1FEeG5JSmRxeU9BXCIsIFwiTWF4XCJdIiwKICAgICAgICAgICAgICAgI 1071 CJmYW1pbHlfbmFtZSI6ICJbXCJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBXCIsIFwiTWVpZXJ 1072 cIl0iLAogICAgICAgICAgICAgICAgImJpcnRoZGF0ZSI6ICJbXCJreDVrRjE3Vi14MEptd 1073 1V4OXZndnR3XCIsIFwiMTk1Ni0wMS0yOFwiXSIsCiAgICAgICAgICAgICAgICAicGxhY2V 1074 fb2ZfYmlydGgiOiB7CiAgICAgICAgICAgICAgICAgICAgImNvdW50cnkiOiAiW1wiSDNvM 1075 XVzd1A3NjBGaTJ5ZUdkVkNFUVwiLCBcIkRFXCJdIiwKICAgICAgICAgICAgICAgICAgICA 1076 ibG9jYWxpdHkiOiAiW1wiT0JLbFRWbHZMZy1BZHdxWUdiUDhaQVwiLCBcIk11c3RlcnN0Y 1077 WR0XCJdIgogICAgICAgICAgICAgICAgfSwKICAgICAgICAgICAgICAgICJuYXRpb25hbGl 1078 0aWVzIjogIltcIk0wSmI1N3Q0MXVicmtTdXlyRFQzeEFcIiwgW1wiREVcIl1dIiwKICAgI 1079 CAgICAgICAgICAgICJhZGRyZXNzIjogIltcIkRzbXRLTmdwVjRkQUhwanJjYW9zQXdcIiw 1080 ge1wibG9jYWxpdHlcIjogXCJNYXhzdGFkdFwiLCBcInBvc3RhbF9jb2RlXCI6IFwiMTIzN 1081 DRcIiwgXCJjb3VudHJ5XCI6IFwiREVcIiwgXCJzdHJlZXRfYWRkcmVzc1wiOiBcIkFuIGR 1082 lciBXZWlkZSAyMlwifV0iCiAgICAgICAgICAgIH0KICAgICAgICB9LAogICAgICAgICJia 1083 XJ0aF9taWRkbGVfbmFtZSI6ICJbXCJlSzVvNXBIZmd1cFBwbHRqMXFoQUp3XCIsIFwiVGl 1084 tb3RoZXVzXCJdIiwKICAgICAgICAic2FsdXRhdGlvbiI6ICJbXCJqN0FEZGIwVVZiMExpM 1085 GNpUGNQMGV3XCIsIFwiRHIuXCJdIiwKICAgICAgICAibXNpc2RuIjogIltcIldweEpyRnV 1086 YOHVTaTJwNGh0MDlqdndcIiwgXCI0OTEyMzQ1Njc4OVwiXSIKICAgIH0KfQ 1087 (Line breaks for presentation only.) 1089 A SD-JWT-R for some of the claims: 1091 { 1092 "nonce": "2GLC42sKQveCfGfryNRN9w", 1093 "aud": "https://example.com/verifier", 1094 "sd_release": { 1095 "verified_claims": { 1096 "verification": { 1097 "trust_framework": "[\"eluV5Og3gSNII8EYnsxA_A\", \"de_aml\"]", 1098 "time": "[\"6Ij7tM-a5iVPGboS5tmvVA\", \"2012-04-23T18:25Z\"]", 1099 "evidence": [ 1100 { 1101 "type": "[\"Qg_O64zqAxe412a108iroA\", \"document\"]" 1102 } 1103 ] 1104 }, 1105 "claims": { 1106 "given_name": "[\"HbQ4X8srVW3QDxnIJdqyOA\", \"Max\"]", 1107 "family_name": "[\"C9GSoujviJquEgYfojCb1A\", \"Meier\"]", 1108 "birthdate": "[\"kx5kF17V-x0JmwUx9vgvtw\", \"1956-01-28\"]", 1109 "place_of_birth": { 1110 "country": "[\"H3o1uswP760Fi2yeGdVCEQ\", \"DE\"]" 1111 } 1112 } 1113 } 1114 } 1115 } 1117 A.3. Example 4 - W3C Verifiable Credentials Data Model 1119 This example illustrates how the artifacts defined in this 1120 specification can be represented using W3C Verifiable Credentials 1121 Data Model as defined in [VC_DATA]. 1123 Below is a non-normative example of an SD-JWT represented as a 1124 verifiable credential encoded as JSON and signed as JWS compliant to 1125 [VC_DATA]. 1127 SVC sent alongside this SD-JWT as a JWT-VC is same as in Example 1. 1129 { 1130 "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21", 1131 "jti": "http://example.edu/credentials/3732", 1132 "iss": "https://example.com/keys/foo.jwk", 1133 "nbf": 1541493724, 1134 "iat": 1541493724, 1135 "exp": 1573029723, 1136 "vc": { 1137 "@context": [ 1138 "https://www.w3.org/2018/credentials/v1", 1139 "https://www.w3.org/2018/credentials/examples/v1" 1140 ], 1141 "type": [ 1142 "VerifiableCredential", 1143 "UniversityDegreeCredential" 1144 ] 1145 }, 1146 "sd_digests": { 1147 "given_name": "fUMdn88aaoyKTHrvZd6AuLmPraGhPJ0zF5r_JhxCVZs", 1148 "family_name": "9h5vgv6TpFV6GmnPtugiMLl5tHetHeb5X_2cKHjN7cw", 1149 "birthdate": "fvLCnDm3r4VSYcBF3pIlXP4ulEoHuHOfG_YmFZEuxpQ" 1150 } 1151 } 1153 Below is a non-normative example of an SD-JWT-R represented as a 1154 verifiable presentation encoded as JSON and signed as a JWS compliant 1155 to [VC_DATA]. 1157 { 1158 "iss": "did:example:ebfeb1f712ebc6f1c276e12ec21", 1159 "aud": "s6BhdRkqt3", 1160 "nbf": 1560415047, 1161 "iat": 1560415047, 1162 "exp": 1573029723, 1163 "nonce": "660!6345FSer", 1164 "vp": { 1165 "@context": [ 1166 "https://www.w3.org/2018/credentials/v1" 1167 ], 1168 "type": [ 1169 "VerifiablePresentation" 1170 ], 1171 "verifiableCredential": ["eyJhb...npyXw"] 1172 }, 1173 "sd_release": { 1174 "given_name": "[\"6Ij7tM-a5iVPGboS5tmvVA\", \"John\"]", 1175 "family_name": "[\"eI8ZWm9QnKPpNPeNenHdhQ\", \"Doe\"]", 1176 "birthdate": "[\"5bPs1IquZNa0hkaFzzzZNw\", \"1940-01-01\"]" 1177 } 1178 } 1180 Appendix B. Document History 1182 [[ To be removed from the final specification ]] 1184 -01 1186 * Editorial fixes 1188 * Added hash_alg claim 1190 * Renamed _sd to sd_digests and sd_release 1192 * Added descriptions on holder binding - more work to do 1194 * Clarify that signing the SD-JWT is mandatory 1196 -00 1198 * Renamed to SD-JWT (focus on JWT instead of JWS since signature is 1199 optional) 1201 * Make holder binding optional 1203 * Rename proof to release, since when there is no signature, the 1204 term "proof" can be misleading 1206 * Improved the structure of the description 1208 * Described verification steps 1210 * All examples generated from python demo implementation 1212 * Examples for structured objects 1214 Authors' Addresses 1216 Daniel Fett 1217 yes.com 1218 Email: mail@danielfett.de 1219 URI: https://danielfett.de/ 1221 Kristina Yasuda 1222 Microsoft 1223 Email: Kristina.Yasuda@microsoft.com