Internet DRAFT - draft-ietf-oauth-selective-disclosure-jwt

draft-ietf-oauth-selective-disclosure-jwt







Web Authorization Protocol                                       D. Fett
Internet-Draft                                                  Authlete
Intended status: Standards Track                               K. Yasuda
Expires: 5 September 2024                                      Microsoft
                                                             B. Campbell
                                                           Ping Identity
                                                            4 March 2024


                 Selective Disclosure for JWTs (SD-JWT)
              draft-ietf-oauth-selective-disclosure-jwt-08

Abstract

   This specification defines a mechanism for selective disclosure of
   individual elements of a JSON object used as the payload of a JSON
   Web Signature (JWS) structure.  It encompasses various applications,
   including but not limited to the selective disclosure of JSON Web
   Token (JWT) claims.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Discussion of this document takes place on the Web Authorization
   Protocol Working Group mailing list (oauth@ietf.org), which is
   archived at https://mailarchive.ietf.org/arch/browse/oauth/.

   Source for this draft and an issue tracker can be found at
   https://github.com/oauth-wg/oauth-selective-disclosure-jwt.

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 5 September 2024.




Fett, et al.            Expires 5 September 2024                [Page 1]

Internet-Draft                   SD-JWT                       March 2024


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  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Feature Summary . . . . . . . . . . . . . . . . . . . . .   5
     1.2.  Conventions and Terminology . . . . . . . . . . . . . . .   6
   2.  Terms and Definitions . . . . . . . . . . . . . . . . . . . .   6
   3.  Flow Diagram  . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Concepts  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  SD-JWT and Disclosures  . . . . . . . . . . . . . . . . .   7
     4.2.  Disclosing to a Verifier  . . . . . . . . . . . . . . . .   8
     4.3.  Optional Key Binding  . . . . . . . . . . . . . . . . . .   8
     4.4.  Verification  . . . . . . . . . . . . . . . . . . . . . .   8
   5.  SD-JWT Data Formats . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  Issuer-signed JWT . . . . . . . . . . . . . . . . . . . .  10
       5.1.1.  Hash Function Claim . . . . . . . . . . . . . . . . .  11
       5.1.2.  Key Binding . . . . . . . . . . . . . . . . . . . . .  11
     5.2.  Disclosures . . . . . . . . . . . . . . . . . . . . . . .  12
       5.2.1.  Disclosures for Object Properties . . . . . . . . . .  12
       5.2.2.  Disclosures for Array Elements  . . . . . . . . . . .  13
       5.2.3.  Hashing Disclosures . . . . . . . . . . . . . . . . .  14
       5.2.4.  Embedding Disclosure Digests in SD-JWTs . . . . . . .  14
       5.2.5.  Decoy Digests . . . . . . . . . . . . . . . . . . . .  16
     5.3.  Key Binding JWT . . . . . . . . . . . . . . . . . . . . .  16
       5.3.1.  Integrity Protection of the Presentation  . . . . . .  17
       5.3.2.  Validating the Key Binding JWT  . . . . . . . . . . .  17
   6.  Example 1: SD-JWT . . . . . . . . . . . . . . . . . . . . . .  17
     6.1.  Issuance  . . . . . . . . . . . . . . . . . . . . . . . .  18
     6.2.  Presentation  . . . . . . . . . . . . . . . . . . . . . .  22
   7.  Considerations on Nested Data in SD-JWTs  . . . . . . . . . .  23
     7.1.  Example: Flat SD-JWT  . . . . . . . . . . . . . . . . . .  24
     7.2.  Example: Structured SD-JWT  . . . . . . . . . . . . . . .  25
     7.3.  Example: SD-JWT with Recursive Disclosures  . . . . . . .  26
   8.  Verification and Processing . . . . . . . . . . . . . . . . .  28
     8.1.  Verification of the SD-JWT  . . . . . . . . . . . . . . .  28



Fett, et al.            Expires 5 September 2024                [Page 2]

Internet-Draft                   SD-JWT                       March 2024


     8.2.  Processing by the Holder  . . . . . . . . . . . . . . . .  30
     8.3.  Verification by the Verifier  . . . . . . . . . . . . . .  30
   9.  JWS JSON Serialization  . . . . . . . . . . . . . . . . . . .  31
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  33
     10.1.  Mandatory Signing of the Issuer-signed JWT . . . . . . .  34
     10.2.  Manipulation of Disclosures  . . . . . . . . . . . . . .  34
     10.3.  Entropy of the salt  . . . . . . . . . . . . . . . . . .  34
     10.4.  Minimum length of the salt . . . . . . . . . . . . . . .  35
     10.5.  Choice of a Hash Algorithm . . . . . . . . . . . . . . .  35
     10.6.  Key Binding  . . . . . . . . . . . . . . . . . . . . . .  36
     10.7.  Blinding Claim Names . . . . . . . . . . . . . . . . . .  37
     10.8.  Selectively-Disclosable Validity Claims  . . . . . . . .  37
     10.9.  Issuer Signature Key Distribution and Rotation . . . . .  38
     10.10. Forwarding Credentials . . . . . . . . . . . . . . . . .  38
     10.11. Integrity of Presentation  . . . . . . . . . . . . . . .  38
     10.12. Explicit Typing  . . . . . . . . . . . . . . . . . . . .  38
   11. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  39
     11.1.  Storage of Signed User Data  . . . . . . . . . . . . . .  39
     11.2.  Confidentiality during Transport . . . . . . . . . . . .  40
     11.3.  Decoy Digests  . . . . . . . . . . . . . . . . . . . . .  40
     11.4.  Unlinkability  . . . . . . . . . . . . . . . . . . . . .  41
     11.5.  Issuer Identifier  . . . . . . . . . . . . . . . . . . .  42
   12. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  43
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  43
     13.1.  JSON Web Token Claims Registration . . . . . . . . . . .  43
     13.2.  Media Type Registration  . . . . . . . . . . . . . . . .  44
     13.3.  Structured Syntax Suffix Registration  . . . . . . . . .  46
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  46
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  46
     14.2.  Informative References . . . . . . . . . . . . . . . . .  47
   Appendix A.  Additional Examples  . . . . . . . . . . . . . . . .  49
     A.1.  Example 2: Handling Structured Claims . . . . . . . . . .  49
     A.2.  Example 3 - Complex Structured SD-JWT . . . . . . . . . .  53
     A.3.  Example 4a - SD-JWT-based Verifiable Credentials (SD-JWT
           VC) . . . . . . . . . . . . . . . . . . . . . . . . . . .  60
     A.4.  Example 4b - W3C Verifiable Credentials Data Model
           v2.0  . . . . . . . . . . . . . . . . . . . . . . . . . .  69
     A.5.  Elliptic Curve Key Used in the Examples . . . . . . . . .  77
   Appendix B.  Disclosure Format Considerations . . . . . . . . . .  78
   Appendix C.  Document History . . . . . . . . . . . . . . . . . .  80
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  84










Fett, et al.            Expires 5 September 2024                [Page 3]

Internet-Draft                   SD-JWT                       March 2024


1.  Introduction

   This document specifies conventions for creating JSON Web Signature
   (JWS) [RFC7515] structures with JSON [RFC8259] objects as the payload
   while supporting selective disclosure of individual elements of that
   JSON.  Because JSON Web Token (JWT) [RFC7519] is a very prevalent
   application of JWS with a JSON payload, the selective disclosure of
   JWT claims receives primary treatment herein.  However, that does not
   preclude the mechanism's applicability to other or more general
   applications of JWS with JSON payloads.

   The JSON-based representation of claims in a signed JWT is secured
   against modification using JWS digital signatures.  A consumer of a
   signed JWT that has checked the signature can safely assume that the
   contents of the token have not been modified.  However, anyone
   receiving an unencrypted JWT can read all the claims.  Likewise,
   anyone with the decryption key receiving encrypted JWT can also read
   all the claims.

   One of the common use cases of a signed JWT is representing a user's
   identity.  As long as the signed JWT is one-time use, it typically
   only contains those claims the user has consented to disclose to a
   specific Verifier.  However, there is an increasing number of use
   cases where a signed JWT is created once and then used a number of
   times by the user (the "Holder" of the JWT).  In such use cases, the
   signed JWT needs to contain the superset of all claims the user of
   the signed JWT might want to disclose to Verifiers at some point.
   The ability to selectively disclose a subset of these claims
   depending on the Verifier becomes crucial to ensure minimum
   disclosure and prevent Verifiers from obtaining claims irrelevant for
   the transaction at hand.  SD-JWTs defined in this document enable
   such selective disclosure of JWT claims.

   One example of a multi-use JWT is a verifiable credential, an Issuer-
   signed credential that contains the claims about a subject, and whose
   authenticity can be cryptographically verified.

   Similar to the JWT specification on which it builds, this document is
   a product of the Web Authorization Protocol (oauth) working group.
   However, while both JWT and SD-JWT have potential OAuth 2.0
   applications, their utility and application is certainly not
   constrained to OAuth 2.0.  JWT was developed as a general-purpose
   token format and has seen widespread usage in a variety of
   applications.  SD-JWT is a selective disclosure mechanism for JWT and
   is similarly intended to be general-purpose specification.






Fett, et al.            Expires 5 September 2024                [Page 4]

Internet-Draft                   SD-JWT                       March 2024


   While JWTs with claims describing natural persons are a common use
   case, the mechanisms defined in this document can be used for other
   use cases as well.

   In an SD-JWT, claims can be hidden, but cryptographically protected
   against undetected modification.  "Claims" here refers to both object
   properties (name-value pairs) as well as array elements.  When
   issuing the SD-JWT to the Holder, the Issuer includes the cleartext
   counterparts of all hidden claims, the so-called Disclosures, outside
   the signed part of the SD-JWT.

   The Holder decides which claims to disclose to a particular Verifier
   and includes the respective Disclosures in the SD-JWT to that
   Verifier.  The Verifier has to verify that all disclosed claim values
   were part of the original Issuer-signed JWT.  The Verifier will not,
   however, learn any claim values not disclosed in the Disclosures.

   This document also specifies an optional mechanism for Key Binding,
   which is the concept of binding an SD-JWT to a Holder's public key
   and requiring that the Holder prove possession of the corresponding
   private key when presenting the SD-JWT.  The strength of the binding
   is conditional upon the trust in the protection of the private key of
   the key pair an SD-JWT is bound to.

   SD-JWT can be used with any JSON-based representation of claims,
   including JSON-LD.

   This specification aims to be easy to implement and to leverage
   established and widely used data formats and cryptographic algorithms
   wherever possible.

1.1.  Feature Summary

   *  This specification defines
      -  a format for the payload of an Issuer-signed JWT containing
         selectively disclosable claims that include object properties
         (name-value pairs), array elements, and nested data structures
         built from these,
      -  a format for data associated with the JWT that enables
         selectively disclosing those claims,
      -  facilities for binding the JWT to a key and associated data to
         prove possession thereof, and
      -  a format, extending the JWS Compact Serialization, for the
         combined transport of the JWT and associated data that is
         suitable for both issuance and presentation.
   *  An alternate format utilizing the JWS JSON Serialization is also
      specified.




Fett, et al.            Expires 5 September 2024                [Page 5]

Internet-Draft                   SD-JWT                       March 2024


   *  This specification enables combining selectively disclosable
      claims with clear-text claims that are always disclosed.
   *  For selectively disclosable claims that are object properties,
      both the key and value are always blinded.

1.2.  Conventions and 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.

   *base64url* denotes the URL-safe base64 encoding without padding
   defined in Section 2 of [RFC7515].

2.  Terms and Definitions

   Selective disclosure:  Process of a Holder disclosing to a Verifier a
      subset of claims contained in a claim set issued by an Issuer.
   Selectively Disclosable JWT (SD-JWT):  A composite structure,
      consisting of an Issuer-signed JWT (JWS, [RFC7515]), Disclosures,
      and optionally a Key Binding JWT that supports selective
      disclosure as defined in this document.  It can contain both
      regular claims and digests of selectively-disclosable claims.
   Disclosure:  A JSON array containing a combination of a salt, a
      cleartext claim name (present when the claim is a name-value pair
      and absent when the claim is an array element), and a cleartext
      claim value, which is base64url-encoded and used to calculate a
      digest for the respective claim.  The term Disclosure refers to
      the whole base64url-encoded string.
   Key Binding:  Ability of the Holder to prove legitimate possession of
      an SD-JWT by proving control over the same private key during the
      issuance and presentation.  An SD-JWT with Key Binding contains a
      public key, or a reference to a public key, that matches to the
      private key controlled by the Holder.
   Key Binding JWT:  A JWT for proving Key Binding as defined in
      Section 5.3.
   Issuer:  An entity that creates SD-JWTs.
   Holder:  An entity that received SD-JWTs from the Issuer and has
      control over them.
   Verifier:  An entity that requests, checks, and extracts the claims
      from an SD-JWT with its respective Disclosures.

3.  Flow Diagram






Fett, et al.            Expires 5 September 2024                [Page 6]

Internet-Draft                   SD-JWT                       March 2024


              +------------+
              |            |
              |   Issuer   |
              |            |
              +------------+
                    |
               Issues SD-JWT
         including all Disclosures
                    |
                    v
              +------------+
              |            |
              |   Holder   |
              |            |
              +------------+
                    |
              Presents SD-JWT
       including selected Disclosures
                    |
                    v
              +-------------+
              |             |+
              |  Verifiers  ||+
              |             |||
              +-------------+||
               +-------------+|
                +-------------+

              Figure 1: SD-JWT Issuance and Presentation Flow

4.  Concepts

   This section describes SD-JWTs with their respective Disclosures and
   Key Binding at a conceptual level, abstracting from the data formats
   described in Section 5.

4.1.  SD-JWT and Disclosures

   An SD-JWT, at its core, is a digitally signed JSON document
   containing digests over the selectively disclosable claims with the
   Disclosures outside the document.  Disclosures can be omitted without
   breaking the signature, and modifying them can be detected.
   Selectively disclosable claims can be individual object properties
   (name-value pairs) or array elements.

   Each digest value ensures the integrity of, and maps to, the
   respective Disclosure.  Digest values are calculated using a hash
   function over the Disclosures, each of which contains a



Fett, et al.            Expires 5 September 2024                [Page 7]

Internet-Draft                   SD-JWT                       March 2024


   cryptographically secure random salt, the claim name (only when the
   claim is an object property), and the claim value.  The Disclosures
   are sent to the Holder as part of the SD-JWT in the format defined in
   Section 5.  When presenting an SD-JWT to a Verifier, the Holder only
   includes the Disclosures for the claims that it wants to reveal to
   that Verifier.

   An SD-JWT MAY also contain clear-text claims that are always
   disclosed to the Verifier.

4.2.  Disclosing to a Verifier

   To disclose to a Verifier a subset of the SD-JWT claim values, a
   Holder sends only the Disclosures of those selectively released
   claims to the Verifier as part of the SD-JWT.

4.3.  Optional Key Binding

   Key Binding is an optional feature.  When Key Binding is required by
   the use-case, the SD-JWT MUST contain information about the key
   material controlled by the Holder.

   Note: How the public key is included in SD-JWT is out of scope of
   this document.  It can be passed by value or by reference.

   For presenting an SD-JWT to a Verifier that enforces Key Binding, the
   Holder creates a signed document, the Key Binding JWT as defined in
   Section 5.3, using its private key.  This document contains a nonce
   to ensure the freshness of the signature, an audience value to
   indicate the intended audience for the document, and a hash that
   ensures the integrity of the data sent from the Holder to the
   Verifier.  Details of the format of Key Binding JWTs are described in
   Section 5.3.

4.4.  Verification

   At a high level, the Verifier

   *  receives the SD-JWT from the Holder and verifies its signature
      using the Issuer's public key,
   *  verifies the Key Binding JWT, if Key Binding is required by the
      Verifier's policy, using the public key included in the SD-JWT,
   *  calculates the digests over the Holder-Selected Disclosures and
      verifies that each digest is contained in the SD-JWT.

   The detailed algorithm is described in Section 8.3.





Fett, et al.            Expires 5 September 2024                [Page 8]

Internet-Draft                   SD-JWT                       March 2024


5.  SD-JWT Data Formats

   An SD-JWT is composed of the following:

   *  an Issuer-signed JWT,
   *  zero or more Disclosures, and
   *  optionally a Key Binding JWT.

   The Issuer-signed JWT, Disclosures, and Key Binding JWT are explained
   in Section 5.1, Section 5.2, and Section 5.3 respectively.

   The serialized format for the SD-JWT is the concatenation of each
   part delineated with a single tilde ('~') character as follows:

<Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclosure N>~<optional KB-JWT>

   The order of the concatenated parts MUST be the Issuer-signed JWT, a
   tilde character, zero or more Disclosures each followed by a tilde
   character, and lastly the optional Key Binding JWT.  In the case that
   there is no Key Binding JWT, the last element MUST be an empty string
   and the last separating tilde character MUST NOT be omitted.

   The Disclosures are linked to the Issuer-signed JWT through the
   digest values included therein.

   When issuing to a Holder, the Issuer includes all the relevant
   Disclosures in the SD-JWT.

   When presenting to a Verifier, the Holder sends only the selected set
   of the Disclosures in the SD-JWT.

   The Holder MAY send any subset of the Disclosures to the Verifier,
   i.e., none, some, or all Disclosures.  For data that the Holder does
   not want to reveal to the Verifier, the Holder MUST NOT send
   Disclosures or reveal the salt values in any other way.  A Holder
   MUST NOT send a Disclosure that was not included in the issued SD-JWT
   or send a Disclosure more than once.

   To further illustrate the SD-JWT format, the following example shows
   a few different SD-JWT permutations, both with and without various
   constituent parts.










Fett, et al.            Expires 5 September 2024                [Page 9]

Internet-Draft                   SD-JWT                       March 2024


   An SD-JWT without Disclosures and without a KB-JWT:
   <Issuer-signed JWT>~

   An SD-JWT without Disclosures and with a KB-JWT:
   <Issuer-signed JWT>~<KB-JWT>

   An SD-JWT with Disclosures and without a KB-JWT:
   <Issuer-signed JWT>~<Disclosure 1>~<Disclosure N>~

   An SD-JWT with Disclosures and with a KB-JWT:
   <Issuer-signed JWT>~<Disclosure 1>~<Disclosure N>~<KB-JWT>

5.1.  Issuer-signed JWT

   An SD-JWT has a JWT component that MUST be signed using the Issuer's
   private key.  It MUST NOT use the none algorithm.

   The payload of an SD-JWT is a JSON object according to the following
   rules:

   1.  The payload MAY contain the _sd_alg key described in
       Section 5.1.1.
   2.  The payload MAY contain one or more digests of Disclosures to
       enable selective disclosure of the respective claims, created and
       formatted as described in Section 5.2.
   3.  The payload MAY contain one or more decoy digests to obscure the
       actual number of claims in the SD-JWT, created and formatted as
       described in Section 5.2.5.
   4.  The payload MAY contain one or more non-selectively disclosable
       claims.
   5.  The payload MAY contain the Holder's public key(s) or
       reference(s) thereto, as explained in Section 5.1.2.
   6.  The payload MAY contain further claims such as iss, iat, etc. as
       defined or required by the application using SD-JWTs.
   7.  The payload MUST NOT contain the reserved claims _sd or ...
       except for the purpose of transporting digests as described
       below.

   The same digest value MUST NOT appear more than once in the SD-JWT.

   Applications of SD-JWT SHOULD be explicitly typed using the typ
   header parameter.  See Section 10.12 for more details.









Fett, et al.            Expires 5 September 2024               [Page 10]

Internet-Draft                   SD-JWT                       March 2024


   It is the Issuer who decides which claims are selectively disclosable
   and which are not.  End-User claims MAY be included as plaintext as
   well, e.g., if hiding the particular claims from the Verifier is not
   required in the intended use case.  See Section 10.8 for
   considerations on making validity-controlling claims such as exp
   selectively disclosable.

   Claims that are not selectively disclosable are included in the SD-
   JWT in plaintext just as they would be in any other JSON structure.

5.1.1.  Hash Function Claim

   The claim _sd_alg indicates the hash algorithm used by the Issuer to
   generate the digests as described in Section 5.2.  When used, this
   claim MUST appear at the top level of the SD-JWT payload.  It MUST
   NOT be used in any object nested within the payload.  If the _sd_alg
   claim is not present at the top level, a default value of sha-256
   MUST be used.

   The hash algorithm identifier MUST be a hash algorithm value from the
   "Hash Name String" column in the IANA "Named Information Hash
   Algorithm" registry [IANA.Hash.Algorithms] or a value defined in
   another specification and/or profile of this specification.

   To promote interoperability, implementations MUST support the sha-256
   hash algorithm.

   See Section 10 for requirements regarding entropy of the salt,
   minimum length of the salt, and choice of a hash algorithm.

5.1.2.  Key Binding

   If the Issuer wants to enable Key Binding, it includes a public key
   associated with the Holder, or a reference thereto.  The jwk member
   of the cnf claim as defined in Section 3.2 of [RFC7800] is suggested
   for doing so, however, other means can be used.

   It is out of the scope of this document to describe how the Holder
   key pair is established.  For example, the Holder MAY create a key
   pair and provide a public key to the Issuer, the Issuer MAY create
   the key pair for the Holder, or Holder and Issuer MAY use pre-
   established key material.

   Note: The examples throughout this document use the cnf claim to
   include the raw public key by value in SD-JWT.






Fett, et al.            Expires 5 September 2024               [Page 11]

Internet-Draft                   SD-JWT                       March 2024


5.2.  Disclosures

   Disclosures are created differently depending on whether a claim is
   an object property (name-value pair) or an array element.

   *  For a claim that is an object property, the Issuer creates a
      Disclosure as described in Section 5.2.1.
   *  For a claim that is an array element, the Issuer creates a
      Disclosure as described in Section 5.2.2.

5.2.1.  Disclosures for Object Properties

   For each claim that is an object property and that is to be made
   selectively disclosable, the Issuer MUST create a Disclosure as
   follows:

   *  Create an array of three elements in this order:
      1.  A salt value.  MUST be a string.  See Section 10.3 and
          Section 10.4 for security considerations.  It is RECOMMENDED
          to base64url-encode minimum 128 bits of cryptographically
          secure random data, producing a string.  The salt value MUST
          be unique for each claim that is to be selectively disclosed.
          The Issuer MUST NOT reveal the salt value to any party other
          than the Holder.
      2.  The claim name, or key, as it would be used in a regular JWT
          payload.  It MUST be a string and MUST NOT be _sd, ..., or a
          claim name existing in the object as a non-selectively
          disclosable claim.
      3.  The claim value, as it would be used in a regular JWT payload.
          The value MAY be of any type that is allowed in JSON,
          including numbers, strings, booleans, arrays, and objects.
   *  JSON-encode the array, producing an UTF-8 string.
   *  base64url-encode the byte representation of the UTF-8 string,
      producing a US-ASCII [RFC0020] string.  This string is the
      Disclosure.

   The order is decided based on the readability considerations: salts
   would have a constant length within the SD-JWT, claim names would be
   around the same length all the time, and claim values would vary in
   size, potentially being large objects.

   The following example illustrates the steps described above.

   The array is created as follows:

   ["_26bc4LT-ac6q2KI6cBW5es", "family_name", "Möbius"]





Fett, et al.            Expires 5 September 2024               [Page 12]

Internet-Draft                   SD-JWT                       March 2024


   The resulting Disclosure would be: WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcy
   IsICJmYW1pbHlfbmFtZSIsICJNw7ZiaXVzIl0

   Note that variations in whitespace, encoding of Unicode characters,
   ordering of object properties, etc., are allowed in the JSON
   representation and no canonicalization needs be performed before
   base64url-encoding.  For example, the following strings are all valid
   and encode the same claim value "Möbius":

   *  A different way to encode the unicode umlaut:
      WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNX
      HUwMGY2Yml1cyJd
   *  No white space:
      WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsImZhbWlseV9uYW1lIiwiTcO2Y
      ml1cyJd
   *  Newline characters between elements:
      WwoiXzI2YmM0TFQtYWM2cTJLSTZjQlc1ZXMiLAoiZmFtaWx5X25hbWUiLAoiT
      cO2Yml1cyIKXQ

   See Appendix B for some further considerations on the Disclosure
   format approach.

5.2.2.  Disclosures for Array Elements

   For each claim that is an array element and that is to be made
   selectively disclosable, the Issuer MUST create a Disclosure as
   follows:

   *  The array MUST contain two elements in this order:
      1.  The salt value as described in Section 5.2.1.
      2.  The array element that is to be hidden.  This value MAY be of
          any type that is allowed in JSON, including numbers, strings,
          booleans, arrays, and objects.

   The Disclosure string is created by JSON-encoding this array and
   base64url-encoding the byte representation of the resulting string as
   described in Section 5.2.1.  The same considerations regarding
   variations in the result of the JSON encoding apply.

   For example, a Disclosure for the second element of the nationalities
   array in the following claim set:

   {
     "nationalities": ["DE", "FR"]
   }

   could be created by first creating the following array:




Fett, et al.            Expires 5 September 2024               [Page 13]

Internet-Draft                   SD-JWT                       March 2024


   ["lklxF5jMYlGTPUovMNIvCA", "FR"]

   The resulting Disclosure would be:
   WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIkZSIl0

5.2.3.  Hashing Disclosures

   For embedding references to the Disclosures in the SD-JWT, each
   Disclosure is hashed using the hash algorithm specified in the
   _sd_alg claim described in Section 5.1.1.  The resulting digest is
   then included in the SD-JWT payload instead of the original claim
   value, as described next.

   The digest MUST be taken over the US-ASCII bytes of the base64url-
   encoded value that is the Disclosure.  This follows the convention in
   JWS [RFC7515] and JWE [RFC7516].  The bytes of the digest MUST then
   be base64url-encoded.

   It is important to note that:

   *  The input to the hash function MUST be the base64url-encoded
      Disclosure, not the bytes encoded by the base64url string.
   *  The bytes of the output of the hash function MUST be base64url-
      encoded, and are not the bytes making up the (often used) hex
      representation of the bytes of the digest.

   For example, the SHA-256 digest of the Disclosure
   WyI2cU1RdlJMNWhhaiIsICJmYW1pbHlfbmFtZSIsICJNw7ZiaXVzIl0 would be
   uutlBuYeMDyjLLTpf6Jxi7yNkEF35jdyWMn9U7b_RYY.

   The SHA-256 digest of the Disclosure
   WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIkZSIl0 would be
   w0I8EKcdCtUPkGCNUrfwVp2xEgNjtoIDlOxc9-PlOhs.

5.2.4.  Embedding Disclosure Digests in SD-JWTs

   For selectively disclosable claims, the digests of the Disclosures
   are embedded into the Issuer-signed JWT instead of the claims
   themselves.  The precise way of embedding depends on whether a claim
   is an object property (name-value pair) or an array element.

   *  For a claim that is an object property, the Issuer embeds a
      Disclosure digest as described in Section 5.2.4.1.
   *  For a claim that is an array element, the Issuer creates a
      Disclosure digest as described in Section 5.2.4.2.






Fett, et al.            Expires 5 September 2024               [Page 14]

Internet-Draft                   SD-JWT                       March 2024


5.2.4.1.  Object Properties

   Digests of Disclosures for object properties are added to an array
   under the new key _sd in the object.  The _sd key MUST refer to an
   array of strings, each string being a digest of a Disclosure or a
   decoy digest as described in Section 5.2.5.

   The array MAY be empty in case the Issuer decided not to selectively
   disclose any of the claims at that level.  However, it is RECOMMENDED
   to omit the _sd key in this case to save space.

   The Issuer MUST hide the original order of the claims in the array.
   To ensure this, it is RECOMMENDED to shuffle the array of hashes,
   e.g., by sorting it alphanumerically or randomly, after potentially
   adding decoy digests as described in Section 5.2.5.  The precise
   method does not matter as long as it does not depend on the original
   order of elements.

   For example, using the digest of the object property Disclosure
   created above, the Issuer could create the following SD-JWT payload
   to make family_name selectively disclosable:

   {
     "given_name": "Alice",
     "_sd": ["uutlBuYeMDyjLLTpf6Jxi7yNkEF35jdyWMn9U7b_RYY"]
   }

5.2.4.2.  Array Elements

   Digests of Disclosures for array elements are added to the array in
   the same position as the original claim value in the array.  For each
   digest, an object of the form {"...": "<digest>"} is added to the
   array.  The key MUST always be the string ... (three dots).  The
   value MUST be the digest of the Disclosure created as described in
   Section 5.2.3.  There MUST NOT be any other keys in the object.

   For example, using the digest of the array element Disclosure created
   above, the Issuer could create the following SD-JWT payload to make
   the second element of the nationalities array selectively
   disclosable:

   {
     "nationalities":
       ["DE", {"...": "w0I8EKcdCtUPkGCNUrfwVp2xEgNjtoIDlOxc9-PlOhs"}]
   }






Fett, et al.            Expires 5 September 2024               [Page 15]

Internet-Draft                   SD-JWT                       March 2024


   As described in Section 8.3, Verifiers ignore all selectively
   disclosable array elements for which they did not receive a
   Disclosure.  In the example above, the verification process would
   output an array with only one element unless a matching Disclosure
   for the second element is received.

5.2.5.  Decoy Digests

   An Issuer MAY add additional digests to the SD-JWT payload that are
   not associated with any claim.  The purpose of such "decoy" digests
   is to make it more difficult for an attacker to see the original
   number of claims contained in the SD-JWT.  Decoy digests MAY be added
   both to the _sd array for objects as well as in arrays.

   It is RECOMMENDED to create the decoy digests by hashing over a
   cryptographically secure random number.  The bytes of the digest MUST
   then be base64url-encoded as above.  The same digest function as for
   the Disclosures MUST be used.

   For decoy digests, no Disclosure is sent to the Holder, i.e., the
   Holder will see digests that do not correspond to any Disclosure.
   See Section 11.3 for additional privacy considerations.

   To ensure readability and replicability, the examples in this
   specification do not contain decoy digests unless explicitly stated.
   For an example with decoy digests, see Appendix A.1.

5.3.  Key Binding JWT

   This section defines the contents of the optional Key Binding JWT,
   which the Holder MAY include in the SD-JWT to prove the Key Binding
   to the Verifier.

   The JWT MUST contain the following elements:

   *  in the JOSE header,
      -  typ: REQUIRED.  MUST be kb+jwt, which explicitly types the Key
         Binding JWT as recommended in Section 3.11 of [RFC8725].
      -  alg: REQUIRED.  A digital signature algorithm identifier such
         as per IANA "JSON Web Signature and Encryption Algorithms"
         registry.  MUST NOT be none.
   *  in the JWT payload,
      -  iat: REQUIRED.  The value of this claim MUST be the time at
         which the Key Binding JWT was issued using the syntax defined
         in [RFC7519].
      -  aud: REQUIRED.  The intended receiver of the Key Binding JWT.
         How the value is represented is up to the protocol used and out
         of scope of this specification.



Fett, et al.            Expires 5 September 2024               [Page 16]

Internet-Draft                   SD-JWT                       March 2024


      -  nonce: REQUIRED.  Ensures the freshness of the signature.  The
         value type of this claim MUST be a string.  How this value is
         obtained is up to the protocol used and out of scope of this
         specification.
      -  sd_hash: REQUIRED.  The base64url-encoded hash digest over the
         Issuer-signed JWT and the selected Disclosures as defined
         below.

5.3.1.  Integrity Protection of the Presentation

   The hash digest in sd_hash ensures the integrity of the Presentation.
   It MUST be taken over the US-ASCII bytes preceding the KB-JWT in the
   Presentation, i.e., the Issuer-signed JWT, a tilde character, and
   zero or more Disclosures selected for presentation to the Verifier,
   each followed by a tilde character:

   <Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclosure N>~

   The bytes of the digest MUST then be base64url-encoded.

   The same hash algorithm as for the Disclosures MUST be used (defined
   by the _sd_alg element in the Issuer-signed JWT or the default value,
   as defined in Section 5.1.1).

5.3.2.  Validating the Key Binding JWT

   To validate the signature on the Key Binding JWT, the Verifier MUST
   use the key material in the SD-JWT.  If it is not clear from the SD-
   JWT, the Key Binding JWT MUST specify which key material the Verifier
   needs to use to validate the Key Binding JWT signature using JOSE
   header parameters such as kid and x5c.

   Whether to require Key Binding is up to the Verifier's policy, based
   on the set of trust requirements such as trust frameworks it belongs
   to.  See Section 10.6 for security considerations.

6.  Example 1: SD-JWT

   In this example, a simple SD-JWT is demonstrated.  This example is
   split into issuance and presentation.

   Note: Throughout the examples in this document, line breaks had to be
   added to JSON strings and base64-encoded strings to adhere to the 72
   character limit for lines in RFCs and for readability.  JSON does not
   allow line breaks within strings.






Fett, et al.            Expires 5 September 2024               [Page 17]

Internet-Draft                   SD-JWT                       March 2024


6.1.  Issuance

   The Issuer is using the following input claim set:

   {
     "sub": "user_42",
     "given_name": "John",
     "family_name": "Doe",
     "email": "johndoe@example.com",
     "phone_number": "+1-202-555-0101",
     "phone_number_verified": true,
     "address": {
       "street_address": "123 Main St",
       "locality": "Anytown",
       "region": "Anystate",
       "country": "US"
     },
     "birthdate": "1940-01-01",
     "updated_at": 1570000000,
     "nationalities": [
       "US",
       "DE"
     ]
   }

   The Issuer in this case made the following decisions:

   *  The nationalities array is always visible, but its contents are
      selectively disclosable.
   *  The sub element and essential verification data (iss, iat, cnf,
      etc.) are always visible.
   *  All other End-User claims are selectively disclosable.
   *  For address, the Issuer is using a flat structure, i.e., all of
      the claims in the address claim can only be disclosed in full.
      Other options are discussed in Section 7.

   The following payload is used for the SD-JWT:














Fett, et al.            Expires 5 September 2024               [Page 18]

Internet-Draft                   SD-JWT                       March 2024


   {
     "_sd": [
       "CrQe7S5kqBAHt-nMYXgc6bdt2SH5aTY1sU_M-PgkjPI",
       "JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYlSE",
       "PorFbpKuVu6xymJagvkFsFXAbRoc2JGlAUA2BA4o7cI",
       "TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo",
       "XQ_3kPKt1XyX7KANkqVR6yZ2Va5NrPIvPYbyMvRKBMM",
       "XzFrzwscM6Gn6CJDc6vVK8BkMnfG8vOSKfpPIZdAfdE",
       "gbOsI4Edq2x2Kw-w5wPEzakob9hV1cRD0ATN3oQL9JM",
       "jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4"
     ],
     "iss": "https://issuer.example.com",
     "iat": 1683000000,
     "exp": 1883000000,
     "sub": "user_42",
     "nationalities": [
       {
         "...": "pFndjkZ_VCzmyTa6UjlZo3dh-ko8aIKQc9DlGzhaVYo"
       },
       {
         "...": "7Cf6JkPudry3lcbwHgeZ8khAv1U1OSlerP0VkBJrWZ0"
       }
     ],
     "_sd_alg": "sha-256",
     "cnf": {
       "jwk": {
         "kty": "EC",
         "crv": "P-256",
         "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
         "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
       }
     }
   }

   The following Disclosures are created by the Issuer:

   *Claim given_name*:

   *  SHA-256 Hash: jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4
   *  Disclosure:
      WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9o
      biJd
   *  Contents: ["2GLC42sKQveCfGfryNRN9w", "given_name", "John"]

   *Claim family_name*:

   *  SHA-256 Hash: TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo




Fett, et al.            Expires 5 September 2024               [Page 19]

Internet-Draft                   SD-JWT                       March 2024


   *  Disclosure:
      WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIkRv
      ZSJd
   *  Contents: ["eluV5Og3gSNII8EYnsxA_A", "family_name", "Doe"]

   *Claim email*:

   *  SHA-256 Hash: JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYlSE
   *  Disclosure:
      WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImVtYWlsIiwgImpvaG5kb2VA
      ZXhhbXBsZS5jb20iXQ
   *  Contents: ["6Ij7tM-a5iVPGboS5tmvVA", "email",
      "johndoe@example.com"]

   *Claim phone_number*:

   *  SHA-256 Hash: PorFbpKuVu6xymJagvkFsFXAbRoc2JGlAUA2BA4o7cI
   *  Disclosure:
      WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInBob25lX251bWJlciIsICIr
      MS0yMDItNTU1LTAxMDEiXQ
   *  Contents: ["eI8ZWm9QnKPpNPeNenHdhQ", "phone_number",
      "+1-202-555-0101"]

   *Claim phone_number_verified*:

   *  SHA-256 Hash: XQ_3kPKt1XyX7KANkqVR6yZ2Va5NrPIvPYbyMvRKBMM
   *  Disclosure:
      WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJlcl92ZXJp
      ZmllZCIsIHRydWVd
   *  Contents: ["Qg_O64zqAxe412a108iroA", "phone_number_verified",
      true]

   *Claim address*:

   *  SHA-256 Hash: XzFrzwscM6Gn6CJDc6vVK8BkMnfG8vOSKfpPIZdAfdE
   *  Disclosure:
      WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImFkZHJlc3MiLCB7InN0cmVl
      dF9hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRv
      d24iLCAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0
   *  Contents: ["AJx-095VPrpTtN4QMOqROA", "address", {"street_address":
      "123 Main St", "locality": "Anytown", "region": "Anystate",
      "country": "US"}]

   *Claim birthdate*:

   *  SHA-256 Hash: gbOsI4Edq2x2Kw-w5wPEzakob9hV1cRD0ATN3oQL9JM





Fett, et al.            Expires 5 September 2024               [Page 20]

Internet-Draft                   SD-JWT                       March 2024


   *  Disclosure:
      WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImJpcnRoZGF0ZSIsICIxOTQw
      LTAxLTAxIl0
   *  Contents: ["Pc33JM2LchcU_lHggv_ufQ", "birthdate", "1940-01-01"]

   *Claim updated_at*:

   *  SHA-256 Hash: CrQe7S5kqBAHt-nMYXgc6bdt2SH5aTY1sU_M-PgkjPI
   *  Disclosure:
      WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInVwZGF0ZWRfYXQiLCAxNTcw
      MDAwMDAwXQ
   *  Contents: ["G02NSrQfjFXQ7Io09syajA", "updated_at", 1570000000]

   *Array Entry*:

   *  SHA-256 Hash: pFndjkZ_VCzmyTa6UjlZo3dh-ko8aIKQc9DlGzhaVYo
   *  Disclosure:
      WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIlVTIl0
   *  Contents: ["lklxF5jMYlGTPUovMNIvCA", "US"]

   *Array Entry*:

   *  SHA-256 Hash: 7Cf6JkPudry3lcbwHgeZ8khAv1U1OSlerP0VkBJrWZ0
   *  Disclosure:
      WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIkRFIl0
   *  Contents: ["nPuoQnkRFq3BIeAm7AnXFA", "DE"]

   The payload is then signed by the Issuer to create a JWT like the
   following:

   eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb
   IkNyUWU3UzVrcUJBSHQtbk1ZWGdjNmJkdDJTSDVhVFkxc1VfTS1QZ2tqUEkiLCAiSnpZ
   akg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQWWxTRSIsICJQb3JGYnBL
   dVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1
   SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAiWFFfM2tQS3QxWHlYN0tB
   TmtxVlI2eVoyVmE1TnJQSXZQWWJ5TXZSS0JNTSIsICJYekZyendzY002R242Q0pEYzZ2
   Vks4QmtNbmZHOHZPU0tmcFBJWmRBZmRFIiwgImdiT3NJNEVkcTJ4Mkt3LXc1d1BFemFr
   b2I5aFYxY1JEMEFUTjNvUUw5Sk0iLCAianN1OXlWdWx3UVFsaEZsTV8zSmx6TWFTRnpn
   bGhRRzBEcGZheVF3TFVLNCJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu
   Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAic3ViIjog
   InVzZXJfNDIiLCAibmF0aW9uYWxpdGllcyI6IFt7Ii4uLiI6ICJwRm5kamtaX1ZDem15
   VGE2VWpsWm8zZGgta284YUlLUWM5RGxHemhhVllvIn0sIHsiLi4uIjogIjdDZjZKa1B1
   ZHJ5M2xjYndIZ2VaOGtoQXYxVTFPU2xlclAwVmtCSnJXWjAifV0sICJfc2RfYWxnIjog
   InNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0y
   NTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VH
   ZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlG
   MkhaUSJ9fX0.RIOaMsGF0sU1W7vmSHgN6P_70Ziz0c0p1GKgJt2-T23YRDLVulwWMScb
   xLoIno6Aae3i7KuCjCP3hIlI2sVpKw



Fett, et al.            Expires 5 September 2024               [Page 21]

Internet-Draft                   SD-JWT                       March 2024


   The issued SD-JWT might look as follows:

   eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb
   IkNyUWU3UzVrcUJBSHQtbk1ZWGdjNmJkdDJTSDVhVFkxc1VfTS1QZ2tqUEkiLCAiSnpZ
   akg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQWWxTRSIsICJQb3JGYnBL
   dVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1
   SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAiWFFfM2tQS3QxWHlYN0tB
   TmtxVlI2eVoyVmE1TnJQSXZQWWJ5TXZSS0JNTSIsICJYekZyendzY002R242Q0pEYzZ2
   Vks4QmtNbmZHOHZPU0tmcFBJWmRBZmRFIiwgImdiT3NJNEVkcTJ4Mkt3LXc1d1BFemFr
   b2I5aFYxY1JEMEFUTjNvUUw5Sk0iLCAianN1OXlWdWx3UVFsaEZsTV8zSmx6TWFTRnpn
   bGhRRzBEcGZheVF3TFVLNCJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu
   Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAic3ViIjog
   InVzZXJfNDIiLCAibmF0aW9uYWxpdGllcyI6IFt7Ii4uLiI6ICJwRm5kamtaX1ZDem15
   VGE2VWpsWm8zZGgta284YUlLUWM5RGxHemhhVllvIn0sIHsiLi4uIjogIjdDZjZKa1B1
   ZHJ5M2xjYndIZ2VaOGtoQXYxVTFPU2xlclAwVmtCSnJXWjAifV0sICJfc2RfYWxnIjog
   InNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0y
   NTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VH
   ZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlG
   MkhaUSJ9fX0.RIOaMsGF0sU1W7vmSHgN6P_70Ziz0c0p1GKgJt2-T23YRDLVulwWMScb
   xLoIno6Aae3i7KuCjCP3hIlI2sVpKw~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgI
   mdpdmVuX25hbWUiLCAiSm9obiJd~WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZh
   bWlseV9uYW1lIiwgIkRvZSJd~WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImVtYWl
   sIiwgImpvaG5kb2VAZXhhbXBsZS5jb20iXQ~WyJlSThaV205UW5LUHBOUGVOZW5IZGhR
   IiwgInBob25lX251bWJlciIsICIrMS0yMDItNTU1LTAxMDEiXQ~WyJRZ19PNjR6cUF4Z
   TQxMmExMDhpcm9BIiwgInBob25lX251bWJlcl92ZXJpZmllZCIsIHRydWVd~WyJBSngt
   MDk1VlBycFR0TjRRTU9xUk9BIiwgImFkZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjog
   IjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRvd24iLCAicmVnaW9uIjogIkFu
   eXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0~WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZR
   IiwgImJpcnRoZGF0ZSIsICIxOTQwLTAxLTAxIl0~WyJHMDJOU3JRZmpGWFE3SW8wOXN5
   YWpBIiwgInVwZGF0ZWRfYXQiLCAxNTcwMDAwMDAwXQ~WyJsa2x4RjVqTVlsR1RQVW92T
   U5JdkNBIiwgIlVTIl0~WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIkRFIl0~

6.2.  Presentation

   The following non-normative example shows an associated SD-JWT
   Presentation as it would be sent from the Holder to the Verifier.
   Note that it consists of six ~-separated parts, with the Issuer-
   signed JWT as shown above in the beginning, four Disclosures (for the
   claims given_name, family_name, address, and nationalities) in the
   middle, and the Key Binding JWT as the last element.











Fett, et al.            Expires 5 September 2024               [Page 22]

Internet-Draft                   SD-JWT                       March 2024


   eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb
   IkNyUWU3UzVrcUJBSHQtbk1ZWGdjNmJkdDJTSDVhVFkxc1VfTS1QZ2tqUEkiLCAiSnpZ
   akg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQWWxTRSIsICJQb3JGYnBL
   dVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1
   SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAiWFFfM2tQS3QxWHlYN0tB
   TmtxVlI2eVoyVmE1TnJQSXZQWWJ5TXZSS0JNTSIsICJYekZyendzY002R242Q0pEYzZ2
   Vks4QmtNbmZHOHZPU0tmcFBJWmRBZmRFIiwgImdiT3NJNEVkcTJ4Mkt3LXc1d1BFemFr
   b2I5aFYxY1JEMEFUTjNvUUw5Sk0iLCAianN1OXlWdWx3UVFsaEZsTV8zSmx6TWFTRnpn
   bGhRRzBEcGZheVF3TFVLNCJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu
   Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAic3ViIjog
   InVzZXJfNDIiLCAibmF0aW9uYWxpdGllcyI6IFt7Ii4uLiI6ICJwRm5kamtaX1ZDem15
   VGE2VWpsWm8zZGgta284YUlLUWM5RGxHemhhVllvIn0sIHsiLi4uIjogIjdDZjZKa1B1
   ZHJ5M2xjYndIZ2VaOGtoQXYxVTFPU2xlclAwVmtCSnJXWjAifV0sICJfc2RfYWxnIjog
   InNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0y
   NTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VH
   ZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlG
   MkhaUSJ9fX0.RIOaMsGF0sU1W7vmSHgN6P_70Ziz0c0p1GKgJt2-T23YRDLVulwWMScb
   xLoIno6Aae3i7KuCjCP3hIlI2sVpKw~WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgI
   mZhbWlseV9uYW1lIiwgIkRvZSJd~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImFk
   ZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5
   IjogIkFueXRvd24iLCAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMi
   fV0~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9obiJd
   ~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIlVTIl0~eyJhbGciOiAiRVMyNTYiLCA
   idHlwIjogImtiK2p3dCJ9.eyJub25jZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodH
   RwczovL3ZlcmlmaWVyLmV4YW1wbGUub3JnIiwgImlhdCI6IDE3MDk1NzI1NzgsICJzZF
   9oYXNoIjogInR3OGFlVndkVEpsY0ZvcGNwZm55UkhqdzcwaFdBal84MERyRUFJNHlTMk
   kifQ.syLVaDTFhKezoXddzLPL9iasGciHdIM96vc-h5aGxjjwA7r793QPO4RRUsSzRck
   c8leNQ5fK_ZvI3m3bm0GdPQ

   The following Key Binding JWT payload was created and signed for this
   presentation by the Holder:

   {
     "nonce": "1234567890",
     "aud": "https://verifier.example.org",
     "iat": 1709572578,
     "sd_hash": "tw8aeVwdTJlcFopcpfnyRHjw70hWAj_80DrEAI4yS2I"
   }

7.  Considerations on Nested Data in SD-JWTs

   Being JSON, an object in an SD-JWT payload MAY contain name-value
   pairs where the value is another object or objects MAY be elements in
   arrays.  In SD-JWT, the Issuer decides for each claim individually,
   on each level of the JSON, whether the claim should be selectively
   disclosable or not.  This choice can be made on each level
   independent from whether keys higher in the hierarchy are selectively
   disclosable.



Fett, et al.            Expires 5 September 2024               [Page 23]

Internet-Draft                   SD-JWT                       March 2024


   From this it follows that the _sd key containing digests MAY appear
   multiple times in an SD-JWT, and likewise, there MAY be multiple
   arrays within the hierarchy with each having selectively disclosable
   elements.  Digests of selectively disclosable claims MAY even appear
   within other Disclosures.

   The following examples illustrate some of the options an Issuer has.
   It is up to the Issuer to decide which structure to use, depending
   on, for example, the expected use cases for the SD-JWT, requirements
   for privacy, size considerations, or ecosystem requirements.  For
   more examples with nested structures, see Appendix A.1 and
   Appendix A.2.

   The following input claim set is used as an example throughout this
   section:

   {
     "sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c",
     "address": {
       "street_address": "Schulstr. 12",
       "locality": "Schulpforta",
       "region": "Sachsen-Anhalt",
       "country": "DE"
     }
   }

   Important: The following examples of the structures are non-normative
   and are not intended to represent all possible options.  They are
   also not meant to define or restrict how address can be represented
   in an SD-JWT.

7.1.  Example: Flat SD-JWT

   The Issuer can decide to treat the address claim as a block that can
   either be disclosed completely or not at all.  The following example
   shows that in this case, the entire address claim is treated as an
   object in the Disclosure.

   {
     "_sd": [
       "fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do"
     ],
     "iss": "https://issuer.example.com",
     "iat": 1683000000,
     "exp": 1883000000,
     "sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c",
     "_sd_alg": "sha-256"
   }



Fett, et al.            Expires 5 September 2024               [Page 24]

Internet-Draft                   SD-JWT                       March 2024


   The Issuer would create the following Disclosure:

   *Claim address*:

   *  SHA-256 Hash: fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do
   *  Disclosure:
      WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImFkZHJlc3MiLCB7InN0cmVl
      dF9hZGRyZXNzIjogIlNjaHVsc3RyLiAxMiIsICJsb2NhbGl0eSI6ICJTY2h1
      bHBmb3J0YSIsICJyZWdpb24iOiAiU2FjaHNlbi1BbmhhbHQiLCAiY291bnRy
      eSI6ICJERSJ9XQ
   *  Contents: ["2GLC42sKQveCfGfryNRN9w", "address", {"street_address":
      "Schulstr. 12", "locality": "Schulpforta", "region":
      "Sachsen-Anhalt", "country": "DE"}]

7.2.  Example: Structured SD-JWT

   The Issuer may instead decide to make the address claim contents
   selectively disclosable individually:

   {
     "iss": "https://issuer.example.com",
     "iat": 1683000000,
     "exp": 1883000000,
     "sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c",
     "address": {
       "_sd": [
         "6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0",
         "9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM",
         "KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88",
         "WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM"
       ]
     },
     "_sd_alg": "sha-256"
   }

   In this case, the Issuer would use the following data in the
   Disclosures for the address sub-claims:

   *Claim street_address*:

   *  SHA-256 Hash: 9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM
   *  Disclosure:
      WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN0cmVldF9hZGRyZXNzIiwg
      IlNjaHVsc3RyLiAxMiJd
   *  Contents: ["2GLC42sKQveCfGfryNRN9w", "street_address", "Schulstr.
      12"]

   *Claim locality*:



Fett, et al.            Expires 5 September 2024               [Page 25]

Internet-Draft                   SD-JWT                       March 2024


   *  SHA-256 Hash: 6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0
   *  Disclosure:
      WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImxvY2FsaXR5IiwgIlNjaHVs
      cGZvcnRhIl0
   *  Contents: ["eluV5Og3gSNII8EYnsxA_A", "locality", "Schulpforta"]

   *Claim region*:

   *  SHA-256 Hash: KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88
   *  Disclosure:
      WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInJlZ2lvbiIsICJTYWNoc2Vu
      LUFuaGFsdCJd
   *  Contents: ["6Ij7tM-a5iVPGboS5tmvVA", "region", "Sachsen-Anhalt"]

   *Claim country*:

   *  SHA-256 Hash: WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM
   *  Disclosure:
      WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImNvdW50cnkiLCAiREUiXQ
   *  Contents: ["eI8ZWm9QnKPpNPeNenHdhQ", "country", "DE"]

   The Issuer may also make one sub-claim of address non-selectively
   disclosable and hide only the other sub-claims:

   {
     "iss": "https://issuer.example.com",
     "iat": 1683000000,
     "exp": 1883000000,
     "sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c",
     "address": {
       "_sd": [
         "6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0",
         "9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM",
         "KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88"
       ],
       "country": "DE"
     },
     "_sd_alg": "sha-256"
   }

   In this case there would be no Disclosure for country since it is
   provided in the clear.

7.3.  Example: SD-JWT with Recursive Disclosures

   The Issuer may also decide to make the address claim contents
   selectively disclosable recursively, i.e., the address claim is made
   selectively disclosable as well as its sub-claims:



Fett, et al.            Expires 5 September 2024               [Page 26]

Internet-Draft                   SD-JWT                       March 2024


   {
     "_sd": [
       "HvrKX6fPV0v9K_yCVFBiLFHsMaxcD_114Em6VT8x1lg"
     ],
     "iss": "https://issuer.example.com",
     "iat": 1683000000,
     "exp": 1883000000,
     "sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c",
     "_sd_alg": "sha-256"
   }

   The Issuer creates Disclosures first for the sub-claims and then
   includes their digests in the Disclosure for the address claim:

   *Claim street_address*:

   *  SHA-256 Hash: 9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM
   *  Disclosure:
      WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN0cmVldF9hZGRyZXNzIiwg
      IlNjaHVsc3RyLiAxMiJd
   *  Contents: ["2GLC42sKQveCfGfryNRN9w", "street_address", "Schulstr.
      12"]

   *Claim locality*:

   *  SHA-256 Hash: 6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0
   *  Disclosure:
      WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImxvY2FsaXR5IiwgIlNjaHVs
      cGZvcnRhIl0
   *  Contents: ["eluV5Og3gSNII8EYnsxA_A", "locality", "Schulpforta"]

   *Claim region*:

   *  SHA-256 Hash: KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88
   *  Disclosure:
      WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInJlZ2lvbiIsICJTYWNoc2Vu
      LUFuaGFsdCJd
   *  Contents: ["6Ij7tM-a5iVPGboS5tmvVA", "region", "Sachsen-Anhalt"]

   *Claim country*:

   *  SHA-256 Hash: WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM
   *  Disclosure:
      WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImNvdW50cnkiLCAiREUiXQ
   *  Contents: ["eI8ZWm9QnKPpNPeNenHdhQ", "country", "DE"]

   *Claim address*:




Fett, et al.            Expires 5 September 2024               [Page 27]

Internet-Draft                   SD-JWT                       March 2024


   *  SHA-256 Hash: HvrKX6fPV0v9K_yCVFBiLFHsMaxcD_114Em6VT8x1lg
   *  Disclosure:
      WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImFkZHJlc3MiLCB7Il9zZCI6
      IFsiNnZoOWJxLXpTNEdLTV83R3BnZ1ZiWXp6dTZvT0dYcm1OVkdQSFA3NVVk
      MCIsICI5Z2pWdVh0ZEZST0NnUnJ0TmNHVVhtRjY1cmRlemlfNkVyX2o3Nmtt
      WXlNIiwgIktVUkRQaDRaQzE5LTN0aXotRGYzOVY4ZWlkeTFvVjNhM0gxRGEy
      TjBnODgiLCAiV045cjlkQ0JKOEhUQ3NTMmpLQVN4VGpFeVc1bTV4NjVfWl8y
      cm8yamZYTSJdfV0
   *  Contents: ["Qg_O64zqAxe412a108iroA", "address", {"_sd":
      ["6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0",
      "9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM",
      "KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88",
      "WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM"]}]

8.  Verification and Processing

8.1.  Verification of the SD-JWT

   Upon receiving an SD-JWT, a Holder or a Verifier needs to ensure that

   *  the Issuer-signed JWT is valid, i.e., it is signed by the Issuer
      and the signature is valid, and
   *  all Disclosures are valid and correspond to a respective digest
      value in the Issuer-signed JWT (directly in the payload or
      recursively included in the contents of other Disclosures).

   The Holder or the Verifier MUST perform the following (or equivalent)
   steps when receiving an SD-JWT:

   1.  Separate the SD-JWT into the Issuer-signed JWT, the Disclosures
       (if any), and the Key Binding JWT (if present).
   2.  Validate the Issuer-signed JWT:
       1.  Ensure that a signing algorithm was used that was deemed
           secure for the application.  Refer to [RFC8725], Sections 3.1
           and 3.2 for details.  The none algorithm MUST NOT be
           accepted.
       2.  Validate the signature over the Issuer-signed JWT per
           Section 5.2 of [RFC7515].
       3.  Validate the Issuer and that the signing key belongs to this
           Issuer.
       4.  Check that the _sd_alg claim value is understood and the hash
           algorithm is deemed secure (see Section 5.1.1).
   3.  Process the Disclosures and embedded digests in the Issuer-signed
       JWT as follows:
       1.  For each Disclosure provided:
           1.  Calculate the digest over the base64url-encoded string as
               described in Section 5.2.3.




Fett, et al.            Expires 5 September 2024               [Page 28]

Internet-Draft                   SD-JWT                       March 2024


       2.  (*) Identify all embedded digests in the Issuer-signed JWT as
           follows:
           1.  Find all objects having an _sd key that refers to an
               array of strings.
           2.  Find all array elements that are objects with one key,
               that key being ... and referring to a string.
       3.  (**) For each embedded digest found in the previous step:
           1.  Compare the value with the digests calculated previously
               and find the matching Disclosure.  If no such Disclosure
               can be found, the digest MUST be ignored.
           2.  If the digest was found in an object's _sd key:
               1.  If the contents of the respective Disclosure is not a
                   JSON-encoded array of three elements (salt, claim
                   name, claim value), the SD-JWT MUST be rejected.
               2.  If the claim name is _sd or ..., the SD-JWT MUST be
                   rejected.
               3.  If the claim name already exists at the level of the
                   _sd key, the SD-JWT MUST be rejected.
               4.  Insert, at the level of the _sd key, a new claim
                   using the claim name and claim value from the
                   Disclosure.
               5.  Recursively process the value using the steps
                   described in (*) and (**).
           3.  If the digest was found in an array element:
               1.  If the contents of the respective Disclosure is not a
                   JSON-encoded array of two elements (salt, value), the
                   SD-JWT MUST be rejected.
               2.  Replace the array element with the value from the
                   Disclosure.
               3.  Recursively process the value using the steps
                   described in (*) and (**).
       4.  Remove all array elements for which the digest was not found
           in the previous step.
       5.  Remove all _sd keys and their contents from the Issuer-signed
           JWT payload.
       6.  Remove the claim _sd_alg from the SD-JWT payload.
   4.  If any digest value is encountered more than once in the Issuer-
       signed JWT payload (directly or recursively via other
       Disclosures), the SD-JWT MUST be rejected.
   5.  If any Disclosure was not referenced by digest value in the
       Issuer-signed JWT (directly or recursively via other
       Disclosures), the SD-JWT MUST be rejected.
   6.  Check that the SD-JWT is valid using claims such as nbf, iat, and
       exp in the processed payload.  If a required validity-controlling
       claim is missing (see Section 10.8), the SD-JWT MUST be rejected.

   If any step fails, the SD-JWT is not valid and processing MUST be
   aborted.



Fett, et al.            Expires 5 September 2024               [Page 29]

Internet-Draft                   SD-JWT                       March 2024


   It is up to the Holder how to maintain the mapping between the
   Disclosures and the plaintext claim values to be able to display them
   to the End-User when needed.

8.2.  Processing by the Holder

   If a Key Binding JWT is received by a Holder, the SD-JWT SHOULD be
   rejected.

   For presentation to a Verifier, the Holder MUST perform the following
   (or equivalent) steps:

   1.  Decide which Disclosures to release to the Verifier, obtaining
       proper End-User consent if necessary.
   2.  Assemble the SD-JWT for presentation, including the Issuer-signed
       JWT and the selected Disclosures (see Section 5 for the format).
   3.  If Key Binding is required, create a Key Binding JWT
       (Section 5.3) and add it to the SD-JWT for presentation.
   4.  Send the SD-JWT for presentation to the Verifier.

8.3.  Verification by the Verifier

   Upon receiving a Presentation, in addition to the checks outlined in
   Section 8.1, Verifiers need to ensure that

   *  if Key Binding is required, the Key Binding JWT is signed by the
      Holder and valid.

   To this end, Verifiers MUST follow the following steps (or
   equivalent):

   1.  Determine if Key Binding is to be checked according to the
       Verifier's policy for the use case at hand.  This decision MUST
       NOT be based on whether a Key Binding JWT is provided by the
       Holder or not.  Refer to Section 10.6 for details.
   2.  Process the SD-JWT as defined in Section 8.1.
   3.  If Key Binding is required:
       1.  If a Key Binding JWT is not provided, the Verifier MUST
           reject the Presentation.
       2.  Determine the public key for the Holder from the SD-JWT (see
           Section 5.1.2).
       3.  Ensure that a signing algorithm was used that was deemed
           secure for the application.  Refer to [RFC8725], Sections 3.1
           and 3.2 for details.  The none algorithm MUST NOT be
           accepted.
       4.  Validate the signature over the Key Binding JWT per
           Section 5.2 of [RFC7515].




Fett, et al.            Expires 5 September 2024               [Page 30]

Internet-Draft                   SD-JWT                       March 2024


       5.  Check that the typ of the Key Binding JWT is kb+jwt (see
           Section 5.3).
       6.  Check that the creation time of the Key Binding JWT, as
           determined by the iat claim, is within an acceptable window.
       7.  Determine that the Key Binding JWT is bound to the current
           transaction and was created for this Verifier (replay
           protection) by validating nonce and aud claims.
       8.  Calculate the digest over the Issuer-signed JWT and
           Disclosures as defined in Section 5.3.1 and verify that it
           matches the value of the sd_hash claim in the Key Binding
           JWT.
       9.  Check that the Key Binding JWT is a valid JWT in all other
           respects, per [RFC7519] and [RFC8725].

   If any step fails, the Presentation is not valid and processing MUST
   be aborted.

   Otherwise, the processed SD-JWT payload can be passed to the
   application to be used for the intended purpose.

9.  JWS JSON Serialization

   This section describes an optional alternate format for SD-JWT using
   the JWS JSON Serialization from [RFC7515].

   For both the General and Flattened JSON Serialization, the SD-JWT is
   represented as a JSON object according to Section 7.2 of [RFC7515].
   The Disclosures (both for issuance and presentation) SHOULD be
   included in the serialized JWS using the member name disclosures at
   the top-level of the JSON object (the same level as the payload
   member).  The value of the disclosures member is an array of strings
   where each element is an individual Disclosure as described in
   Section 5.2.  The Issuer includes a Disclosure for each selectively
   disclosable claim of the SD-JWT payload, whereas the Holder includes
   only the Disclosures selected for the given presentation.

   Alternative methods for conveying the Disclosures MAY be used (such
   as including them in a disclosures member of an outer JSON structure
   also containing the JSON Serialized SD-JWT) as dictated by a specific
   application or transport protocol.  However, the details of such
   approaches fall outside the scope of this specification.

   Verification of the JWS JSON serialized SD-JWT follows the same rules
   defined in Section 4.4, except that the SD-JWT does not need to be
   split into component parts and the Disclosures can be found in the
   respective member of the JSON object (or elsewhere).





Fett, et al.            Expires 5 September 2024               [Page 31]

Internet-Draft                   SD-JWT                       March 2024


   Using a payload similar to that from Example 1 (#example-1), the
   following is a non-normative example of a JWS JSON serialized SD-JWT
   from an Issuer with all the respective Disclosures.

   {
     "payload": "eyJfc2QiOiBbIjRIQm42YUlZM1d0dUdHV1R4LXFVajZjZGs2V0JwWn
       lnbHRkRmF2UGE3TFkiLCAiOHNtMVFDZjAyMXBObkhBQ0k1c1A0bTRLWmd5Tk9PQV
       ljVGo5SE5hQzF3WSIsICJTRE43OU5McEFuSFBta3JkZVlkRWE4OVhaZHNrME04RE
       tZU1FPVTJaeFFjIiwgIlh6RnJ6d3NjTTZHbjZDSkRjNnZWSzhCa01uZkc4dk9TS2
       ZwUElaZEFmZEUiLCAiZ2JPc0k0RWRxMngyS3ctdzV3UEV6YWtvYjloVjFjUkQwQV
       ROM29RTDlKTSIsICJqTUNYVnotLTliOHgzN1ljb0RmWFFpbnp3MXdaY2NjZkZSQk
       NGR3FkRzJvIiwgIm9LSTFHZDJmd041V3d2amxGa29oaWRHdmltLTMxT3VsUjNxMG
       hyRE8wNzgiXSwgImlzcyI6ICJodHRwczovL2lzc3Vlci5leGFtcGxlLmNvbSIsIC
       JpYXQiOiAxNjgzMDAwMDAwLCAiZXhwIjogMTg4MzAwMDAwMCwgIl9zZF9hbGciOi
       Aic2hhLTI1NiJ9",
     "protected":
       "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0",
     "signature": "NSUqfh9INRyW_bGphuEgkKJaiOuov7qjs68BMJiHLisDeZ99OIKM
       ZZVuCjVCxELBmvA6jQW4e5_uxj14ak6bcw",
     "disclosures": [
       "WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN1YiIsICJqb2huX2RvZV80MiJ
         d",
       "WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiSm9obiJ
         d",
       "WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIkRvZSJ
         d",
       "WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImVtYWlsIiwgImpvaG5kb2VAZXh
         hbXBsZS5jb20iXQ",
       "WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJlciIsICIrMS0
         yMDItNTU1LTAxMDEiXQ",
       "WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImFkZHJlc3MiLCB7InN0cmVldF9
         hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRvd24iL
         CAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0",
       "WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImJpcnRoZGF0ZSIsICIxOTQwLTA
         xLTAxIl0"
     ]
   }

   Below is a non-normative example of a presentation of the JWS JSON
   serialized SD-JWT, where the Holder has selected to disclose
   given_name, family_name, and address.










Fett, et al.            Expires 5 September 2024               [Page 32]

Internet-Draft                   SD-JWT                       March 2024


   {
     "payload": "eyJfc2QiOiBbIjRIQm42YUlZM1d0dUdHV1R4LXFVajZjZGs2V0JwWn
       lnbHRkRmF2UGE3TFkiLCAiOHNtMVFDZjAyMXBObkhBQ0k1c1A0bTRLWmd5Tk9PQV
       ljVGo5SE5hQzF3WSIsICJTRE43OU5McEFuSFBta3JkZVlkRWE4OVhaZHNrME04RE
       tZU1FPVTJaeFFjIiwgIlh6RnJ6d3NjTTZHbjZDSkRjNnZWSzhCa01uZkc4dk9TS2
       ZwUElaZEFmZEUiLCAiZ2JPc0k0RWRxMngyS3ctdzV3UEV6YWtvYjloVjFjUkQwQV
       ROM29RTDlKTSIsICJqTUNYVnotLTliOHgzN1ljb0RmWFFpbnp3MXdaY2NjZkZSQk
       NGR3FkRzJvIiwgIm9LSTFHZDJmd041V3d2amxGa29oaWRHdmltLTMxT3VsUjNxMG
       hyRE8wNzgiXSwgImlzcyI6ICJodHRwczovL2lzc3Vlci5leGFtcGxlLmNvbSIsIC
       JpYXQiOiAxNjgzMDAwMDAwLCAiZXhwIjogMTg4MzAwMDAwMCwgIl9zZF9hbGciOi
       Aic2hhLTI1NiJ9",
     "protected":
       "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0",
     "signature": "NSUqfh9INRyW_bGphuEgkKJaiOuov7qjs68BMJiHLisDeZ99OIKM
       ZZVuCjVCxELBmvA6jQW4e5_uxj14ak6bcw",
     "disclosures": [
       "WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIkRvZSJ
         d",
       "WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImFkZHJlc3MiLCB7InN0cmVldF9
         hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRvd24iL
         CAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0",
       "WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiSm9obiJ
         d"
     ]
   }

10.  Security Considerations

   Security considerations in this section help achieve the following
   properties:

   *Selective Disclosure:* An adversary in the role of the Verifier
   cannot obtain information from an SD-JWT about any claim name or
   claim value that was not explicitly disclosed by the Holder unless
   that information can be derived from other disclosed claims or
   sources other than the presented SD-JWT.

   *Integrity:* A malicious Holder cannot modify names or values of
   selectively disclosable claims without detection by the Verifier.

   Additionally, as described in Section 10.6, the application of Key
   Binding can ensure that the presenter of an SD-JWT credential is the
   legitimate Holder of the credential.








Fett, et al.            Expires 5 September 2024               [Page 33]

Internet-Draft                   SD-JWT                       March 2024


10.1.  Mandatory Signing of the Issuer-signed JWT

   The Issuer-signed JWT MUST be signed by the Issuer to protect
   integrity of the issued claims.  An attacker can modify or add claims
   if this JWT is not signed (e.g., change the "email" attribute to take
   over the victim's account or add an attribute indicating a fake
   academic qualification).

   The Verifier MUST always check the signature of the Issuer-signed JWT
   to ensure that it has not been tampered with since the issuance.  The
   Issuer-signed JWT MUST be rejected if the signature cannot be
   verified.

   The security of the Issuer-signed JWT depends on the security of the
   signature algorithm.  Any of the JWS asymmetric digital signature
   algorithms registered in [IANA.JWS.Algorithms] can be used, including
   post-quantum algorithms, when they are ready.

10.2.  Manipulation of Disclosures

   Holders can manipulate the Disclosures by changing the values of the
   claims before sending them to the Verifier.  The Verifier MUST check
   the Disclosures to ensure that the values of the claims are correct,
   i.e., the digests of the Disclosures are actually present in the
   signed SD-JWT.

   A naive Verifier that extracts all claim values from the Disclosures
   (without checking the hashes) and inserts them into the SD-JWT
   payload is vulnerable to this attack.  However, in a structured SD-
   JWT, without comparing the digests of the Disclosures, such an
   implementation could not determine the correct place in a nested
   object where a claim needs to be inserted.  Therefore, the naive
   implementation would not only be insecure, but also incorrect.

   The steps described in Section 8.3 ensure that the Verifier checks
   the Disclosures correctly.

10.3.  Entropy of the salt

   The security model that conceals the plaintext claims relies on the
   fact that salts not revealed to an attacker cannot be learned or
   guessed by the attacker, even if other salts have been revealed.  It
   is vitally important to adhere to this principle.  As such, each salt
   MUST be created in such a manner that it is cryptographically random,
   long enough, and has high entropy that it is not practical for the
   attacker to guess.  A new salt MUST be chosen for each claim
   independently from other salts.  See Randomness Requirements for
   Security [RFC4086] for considerations on generating random values.



Fett, et al.            Expires 5 September 2024               [Page 34]

Internet-Draft                   SD-JWT                       March 2024


10.4.  Minimum length of the salt

   The RECOMMENDED minimum length of the randomly-generated portion of
   the salt is 128 bits.

   The Issuer MUST ensure that a new salt value is chosen for each
   claim, including when the same claim name occurs at different places
   in the structure of the SD-JWT.  This can be seen in Example 3 in the
   Appendix, where multiple claims with the name type appear, but each
   of them has a different salt.

10.5.  Choice of a Hash Algorithm

   To ensure privacy of claims that are selectively disclosable, but are
   not being disclosed in a given presentation, the hash function MUST
   ensure that it is infeasible to calculate any portion of the three
   elements (salt, claim name, claim value) from a particular digest.
   This implies the hash function MUST be preimage resistant, but should
   also not allow an observer to infer any partial information about the
   undisclosed content.  In the terminology of cryptographic commitment
   schemes, the hash function MUST be computationally hiding.

   To ensure the integrity of selectively disclosable claims, the hash
   function MUST be second-preimage resistant.  That is, for any
   combination of salt, claim name and claim value, it is infeasible to
   find a different combination of salt, claim name and claim value that
   result in the same digest.

   The hash function SHOULD also be collision resistant.  Although not
   essential to the anticipated uses of SD-JWT, without collision
   resistance an Issuer may be able to find multiple disclosures that
   have the same hash value.  In which case, the signature over the SD-
   JWT would not then commit the Issuer to the contents of the JWT.  The
   collision resistance of the hash function used to generate digests
   SHOULD match the collision resistance of the hash function used by
   the signature scheme.  For example, use of the ES512 signature
   algorithm would require a disclosure hash function with at least
   256-bit collision resistance, such as SHA-512.

   Note that inclusion in the "Named Information Hash Algorithm"
   registry [IANA.Hash.Algorithms] alone does not indicate a hash
   algorithm's suitability for use in SD-JWT (it contains several
   heavily truncated digests, such as sha-256-32 and sha-256-64, which
   are unfit for security applications).

   Furthermore, the hash algorithms MD2, MD4, MD5, and SHA-1 revealed
   fundamental weaknesses and MUST NOT be used.




Fett, et al.            Expires 5 September 2024               [Page 35]

Internet-Draft                   SD-JWT                       March 2024


10.6.  Key Binding

   Key Binding aims to ensure that the presenter of an SD-JWT credential
   is actually the legitimate Holder of the credential.  An SD-JWT with
   Key Binding contains a public key, or a reference to a public key,
   that corresponds to a private key possessed by the Holder.  The
   Verifier requires that the Holder prove possession of that private
   key when presenting the SD-JWT credential.

   Without Key Binding, a Verifier only gets the proof that the
   credential was issued by a particular Issuer, but the credential
   itself can be replayed by anyone who gets access to it.  This means
   that, for example, after a credential was leaked to an attacker, the
   attacker can present the credential to any verifier that does not
   require a binding.  But also a malicious Verifier to which the Holder
   presented the credential can present the credential to another
   Verifier if that other Verifier does not require Key Binding.

   Verifiers MUST decide whether Key Binding is required for a
   particular use case before verifying a credential.  This decision can
   be informed by various factors including, but not limited to the
   following: business requirements, the use case, the type of binding
   between a Holder and its credential that is required for a use case,
   the sensitivity of the use case, the expected properties of a
   credential, the type and contents of other credentials expected to be
   presented at the same time, etc.

   It is important that a Verifier does not make its security policy
   decisions based on data that can be influenced by an attacker or that
   can be misinterpreted.  For this reason, when deciding whether Key
   Binding is required or not, Verifiers MUST NOT take into account

   *  whether a Key Binding JWT is present or not, as an attacker can
      remove the Key Binding JWT from any Presentation and present it to
      the Verifier, or
   *  whether Key Binding data is present in the SD-JWT or not, as the
      Issuer might have added the key to the SD-JWT in a format/claim
      that is not recognized by the Verifier.

   If a Verifier has decided that Key Binding is required for a
   particular use case and the Key Binding is not present, does not
   fulfill the requirements (e.g., on the signing algorithm), or no
   recognized Key Binding data is present in the SD-JWT, the Verifier
   will reject the presentation, as described in Section 8.3.







Fett, et al.            Expires 5 September 2024               [Page 36]

Internet-Draft                   SD-JWT                       March 2024


10.7.  Blinding Claim Names

   SD-JWT ensures that names of claims that are selectively disclosable
   are always blinded.  This prevents an attacker from learning the
   names of the disclosable claims.  However, the names of the claims
   that are not disclosable are not blinded.  This includes the keys of
   objects that themselves are not blinded, but contain disclosable
   claims.  This limitation needs to be taken into account by Issuers
   when creating the structure of the SD-JWT.

10.8.  Selectively-Disclosable Validity Claims

   An Issuer MUST NOT allow any content to be selectively disclosable
   that is critical for evaluating the SD-JWT's authenticity or
   validity.  The exact list of such content will depend on the
   application and SHOULD be listed by any application-specific profile
   of SD-JWT.  The following is a list of registered JWT claim names
   that SHOULD be considered as security-critical:

   *  iss (Issuer)
   *  aud (Audience), although issuers MAY allow individual entries in
      the array to be selectively disclosable
   *  exp (Expiration Time)
   *  nbf (Not Before)
   *  cnf (Confirmation Key)

   Issuers will typically include claims controlling the validity of the
   SD-JWT in plaintext in the SD-JWT payload, but there is no guarantee
   they would do so.  Therefore, Verifiers cannot reliably depend on
   that and need to operate as though security-critical claims might be
   selectively disclosable.

   Verifiers therefore MUST ensure that all claims they deem necessary
   for checking the validity of an SD-JWT in the given context are
   present (or disclosed, respectively) during validation of the SD-JWT.
   This is implemented in the last step of the verification defined in
   Section 8.1.

   The precise set of required validity claims will typically be defined
   by ecosystem rules, application-specific profile, or the credential
   format and MAY include claims other than those listed herein.










Fett, et al.            Expires 5 September 2024               [Page 37]

Internet-Draft                   SD-JWT                       March 2024


10.9.  Issuer Signature Key Distribution and Rotation

   This specification does not define how signature verification keys of
   Issuers are distributed to Verifiers.  However, it is RECOMMENDED
   that Issuers publish their keys in a way that allows for efficient
   and secure key rotation and revocation, for example, by publishing
   keys at a predefined location using the JSON Web Key Set (JWKS)
   format [RFC7517].  Verifiers need to ensure that they are not using
   expired or revoked keys for signature verification using reasonable
   and appropriate means for the given key-distribution method.

10.10.  Forwarding Credentials

   When Key Binding is not enforced, any entity in possession of an SD-
   JWT Presentation can forward the contents to third parties.  When
   doing so, that entity may remove Disclosures such that the receiver
   learns only a subset of the claims contained in the original SD-JWT.

   For example, a device manufacturer might produce an SD-JWT containing
   information about upstream and downstream supply chain contributors.
   Each supply chain party can verify only the claims that were
   selectively disclosed to them by an upstream party, and they can
   choose to further reduce the disclosed claims when presenting to a
   downstream party.

   In some scenarios this behavior could be desirable, but if it is not,
   Issuers need to support and Verifiers need to enforce Key Binding.

10.11.  Integrity of Presentation

   In a Presentation, the Issuer-signed JWT is integrity-protected by
   the Issuer's signature, and the Disclosures are integrity-protected
   by the digests included in the Issuer-signed JWT.  If used, the KB-
   JWT, besides proving Key Binding, protects the integrity of the set
   of Disclosures the Holder disclosed.

10.12.  Explicit Typing

   Section 3.11 of [RFC8725] describes the use of explicit typing to
   prevent confusion attacks in which one kind of JWT is mistaken for
   another.  SD-JWTs are also potentially vulnerable to such confusion
   attacks, so it is RECOMMENDED to specify an explicit type by
   including the typ header parameter when the SD-JWT is issued, and for
   Verifiers to check this value.

   When explicit typing is employed for an SD-JWT, it is RECOMMENDED
   that a media type name of the format "application/example+sd-jwt" be
   used, where "example" is replaced by the identifier for the specific



Fett, et al.            Expires 5 September 2024               [Page 38]

Internet-Draft                   SD-JWT                       March 2024


   kind of SD-JWT.  The definition of typ in Section 4.1.9 of [RFC7515]
   recommends that the "application/" prefix be omitted, so "example+sd-
   jwt" would be the value of the typ header parameter.

11.  Privacy Considerations

   The privacy principles of [ISO.29100] should be adhered to.

11.1.  Storage of Signed User Data

   Wherever End-User data is stored, it represents a potential target
   for an attacker.  This target can be of particularly high value when
   the data is signed by a trusted authority like an official national
   identity service.  For example, in OpenID Connect, signed ID Tokens
   can be stored by Relying Parties.  In the case of SD-JWT, Holders
   have to store SD-JWTs, and Issuers and Verifiers may decide to do so
   as well.

   Not surprisingly, a leak of such data risks revealing private data of
   End-Users to third parties.  Signed End-User data, the authenticity
   of which can be easily verified by third parties, further exacerbates
   the risk.  As discussed in Section 10.6, leaked SD-JWTs may also
   allow attackers to impersonate Holders unless Key Binding is enforced
   and the attacker does not have access to the Holder's cryptographic
   keys.  Altogether, leaked SD-JWT credentials may have a high monetary
   value on black markets.

   Due to these risks, systems implementing SD-JWT SHOULD be designed to
   minimize the amount of data that is stored.  All involved parties
   SHOULD store SD-JWTs containing privacy-sensitive data only for as
   long as needed, including in log files.

   After Issuance, Issuers SHOULD NOT store the Issuer-signed JWT or the
   respective Disclosures if they contain privacy-sensitive data.

   Holders SHOULD store SD-JWTs only in encrypted form, and, wherever
   possible, use hardware-backed encryption in particular for the
   private Key Binding key.  Decentralized storage of data, e.g., on
   End-User devices, SHOULD be preferred for End-User credentials over
   centralized storage.  Expired SD-JWTs SHOULD be deleted as soon as
   possible.

   After Verification, Verifiers SHOULD NOT store the Issuer-signed JWT
   or the respective Disclosures if they contain privacy-sensitive data.
   It may be sufficient to store the result of the verification and any
   End-User data that is needed for the application.





Fett, et al.            Expires 5 September 2024               [Page 39]

Internet-Draft                   SD-JWT                       March 2024


   If reliable and secure key rotation and revocation is ensured
   according to Section 10.9, Issuers may opt to publish expired or
   revoked private signing keys (after a grace period that ensures that
   the keys are not cached any longer at any Verifier).  This reduces
   the value of any leaked credentials as the signatures on them can no
   longer be trusted to originate from the Issuer.

11.2.  Confidentiality during Transport

   If the SD-JWT is transmitted over an insecure channel during issuance
   or presentation, an adversary may be able to intercept and read the
   End-User's personal data or correlate the information with previous
   uses of the same SD-JWT.

   Usually, transport protocols for issuance and presentation of
   credentials are designed to protect the confidentiality of the
   transmitted data, for example, by requiring the use of TLS.

   This specification therefore considers the confidentiality of the
   data to be provided by the transport protocol and does not specify
   any encryption mechanism.

   Implementers MUST ensure that the transport protocol provides
   confidentiality if the privacy of End-User data or correlation
   attacks by passive observers are a concern.

   To encrypt the SD-JWT when transmitted over an insecure channel,
   implementers MAY use JSON Web Encryption (JWE) [RFC7516] by nesting
   the SD-JWT as the plaintext payload of a JWE.  Especially, when an
   SD-JWT is transmitted via a URL and information may be stored/cached
   in the browser or end up in web server logs, the SD-JWT SHOULD be
   encrypted using JWE.

11.3.  Decoy Digests

   The use of decoy digests is RECOMMENDED when the number of claims (or
   the existence of particular claims) can be a side-channel disclosing
   information about otherwise undisclosed claims.  In particular, if a
   claim in an SD-JWT is present only if a certain condition is met
   (e.g., a membership number is only contained if the End-User is a
   member of a group), the Issuer SHOULD add decoy digests when the
   condition is not met.

   Decoy digests increase the size of the SD-JWT.  The number of decoy
   digests (or whether to use them at all) is a trade-off between the
   size of the SD-JWT and the privacy of the End-User's data.





Fett, et al.            Expires 5 September 2024               [Page 40]

Internet-Draft                   SD-JWT                       March 2024


11.4.  Unlinkability

   Unlinkability is a property whereby adversaries are prevented from
   correlating credential presentations of the same user beyond the
   user's consent.  Without unlinkability, an adversary might be able to
   learn more about the user than the user intended to disclose, for
   example:

   *  Cooperating Verifiers might want to track users across services to
      build advertising profiles.
   *  Issuers might want to track where users present their credentials
      to enable surveillance.
   *  After a data breach at multiple Verifiers, publicly available
      information might allow linking identifiable information presented
      to Verifier A with originally anonymous information presented to
      Verifier B, therefore revealing the identities of users of
      Verifier B.

   The following types of unlinkability are considered here:

   *  Presentation Unlinkability: A Verifier should not be able to link
      two presentations of the same credential.
   *  Verifier/Verifier Unlinkability: Two colluding Verifiers should
      not be able to learn that they have received presentations of the
      same credential.
   *  Issuer/Verifier Unlinkability (Honest Verifier): An Issuer of a
      credential should not be able to know that a user presented the
      credential to a certain Verifier that is not behaving maliciously.
   *  Issuer/Verifier Unlinkability (Colluding/Compromised Verifier): An
      Issuer of a credential should not be able to tell that a user
      presented the credential to a certain Verifier, even if the
      Verifier colludes with the Issuer or becomes compromised and leaks
      stored credentials from presentations.

   In all cases, unlinkability is limited to cases where the disclosed
   claims do not contain information that directly or indirectly
   identifies the user.  For example, when a taxpayer identification
   number is contained in the disclosed claims, the Issuer and Verifier
   can easily link the user's transactions.  However, when the user only
   discloses a birthdate to one Verifier and a postal code to another
   Verifier, the two Verifiers should not be able to determine that they
   were interacting with the same user.

   Issuer/Verifier unlinkability with a colluding or compromised
   Verifier cannot be achieved in salted-hash based selective disclosure
   approaches, such as SD-JWT, as the issued credential with the
   Issuer's signature is directly presented to the Verifier, who can
   forward it to the Issuer.



Fett, et al.            Expires 5 September 2024               [Page 41]

Internet-Draft                   SD-JWT                       March 2024


   Contrary to that, Issuer/Verifier unlinkability with an honest
   Verifier can generally be achieved.  However, a callback from the
   Verifier to the Issuer, such as a revocation check, could potentially
   disclose information about the credential's usage to the Issuer.
   Where such callbacks are necessary, they MUST be executed in a manner
   that preserves privacy and does not disclose details about the
   credential to the Issuer.  It is important to note that the timing of
   such requests could potentially serve as a side-channel.

   Verifier/Verifier unlinkablility and presentation unlinkablility can
   be achieved using batch issuance: A batch of credentials based on the
   same claims is issued to the Holder instead of just a single
   credential.  The Holder can then use a different credential for each
   Verifier or even for each session with a Verifier.  New key binding
   keys and salts MUST be used for each credential in the batch to
   ensure that the Verifiers cannot link the credentials using these
   values.  Likewise, claims carrying time information, like iat, exp,
   and nbf, MUST either be randomized within a time period considered
   appropriate (e.g., randomize iat within the last 24 hours and
   calculate exp accordingly) or rounded (e.g., rounded down to the
   beginning of the day).

11.5.  Issuer Identifier

   An Issuer issuing only one type of SD-JWT might have privacy
   implications, because if the Holder has an SD-JWT issued by that
   Issuer, its type and claim names can be determined.

   For example, if the National Cancer Institute only issued SD-JWTs
   with cancer registry information, it is possible to deduce that the
   Holder owning its SD-JWT is a cancer patient.

   Moreover, the issuer identifier alone may reveal information about
   the user.

   For example, when a military organization or a drug rehabilitation
   center issues a vaccine credential, verifiers can deduce that the
   holder is a military member or may have a substance use disorder.

   To mitigate this issue, a group of issuers may elect to use a common
   Issuer identifier.  A group signature scheme outside the scope of
   this specification may also be used, instead of an individual
   signature.








Fett, et al.            Expires 5 September 2024               [Page 42]

Internet-Draft                   SD-JWT                       March 2024


12.  Acknowledgements

   We would like to thank Alen Horvat, Anders Rundgren, Arjan Geluk,
   Christian Bormann, Christian Paquin, David Bakker, David Waite,
   Fabian Hauck, Filip Skokan, Giuseppe De Marco, Jacob Ward, Jeffrey
   Yasskin, John Mattsson, Justin Richer, Kushal Das, Matthew Miller,
   Mike Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu,
   Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard
   Barnes, Rohan Mahy, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield,
   Simon Schulz, Tobias Looker, Takahiko Kawasaki, Torsten Lodderstedt,
   Vittorio Bertocci, and Yaron Sheffer for their contributions (some of
   which substantial) to this draft and to the initial set of
   implementations.

   The work on this draft was started at OAuth Security Workshop 2022 in
   Trondheim, Norway.

13.  IANA Considerations

13.1.  JSON Web Token Claims Registration

   This specification requests registration of the following Claims in
   the IANA "JSON Web Token Claims" registry [IANA.JWT] established by
   [RFC7519].

   *  Claim Name: _sd
   *  Claim Description: Digests of Disclosures for object properties
   *  Change Controller: IETF
   *  Specification Document(s): [[ Section 5.2.4.1 of this
      specification ]]



   *  Claim Name: ...
   *  Claim Description: Digest of the Disclosure for an array element
   *  Change Controller: IETF
   *  Specification Document(s): [[ Section 5.2.4.2 of this
      specification ]]



   *  Claim Name: _sd_alg
   *  Claim Description: Hash algorithm used to generate Disclosure
      digests and digest over presentation
   *  Change Controller: IETF
   *  Specification Document(s): [[ Section 5.1.1 of this specification
      ]]




Fett, et al.            Expires 5 September 2024               [Page 43]

Internet-Draft                   SD-JWT                       March 2024


   *  Claim Name: sd_hash
   *  Claim Description: Digest of the Issuer-signed JWT and Disclosures
      in a Presentation
   *  Change Controller: IETF
   *  Specification Document(s): [[ Section 5.3 of this specification ]]

13.2.  Media Type Registration

   This section requests registration of the following media types
   [RFC2046] in the "Media Types" registry [IANA.MediaTypes] in the
   manner described in [RFC6838].

   To indicate that the content is an SD-JWT:

   *  Type name: application
   *  Subtype name: sd-jwt
   *  Required parameters: n/a
   *  Optional parameters: n/a
   *  Encoding considerations: binary; application/sd-jwt values are a
      series of base64url-encoded values (some of which may be the empty
      string) separated by period ('.') or tilde ('~') characters.
   *  Security considerations: See the Security Considerations section
      of [[ this specification ]], [RFC7519], and [RFC8725].
   *  Interoperability considerations: n/a
   *  Published specification: [[ this specification ]]
   *  Applications that use this media type: TBD
   *  Fragment identifier considerations: n/a
   *  Additional information:
      -  Magic number(s): n/a
      -  File extension(s): n/a
      -  Macintosh file type code(s): n/a
   *  Person & email address to contact for further information: Daniel
      Fett, mail@danielfett.de
   *  Intended usage: COMMON
   *  Restrictions on usage: none
   *  Author: Daniel Fett, mail@danielfett.de
   *  Change Controller: IETF
   *  Provisional registration?  No


   To indicate that the content is a JWS JSON serialized SD-JWT:

   *  Type name: application
   *  Subtype name: sd-jwt+json
   *  Required parameters: n/a
   *  Optional parameters: n/a





Fett, et al.            Expires 5 September 2024               [Page 44]

Internet-Draft                   SD-JWT                       March 2024


   *  Encoding considerations: binary; application/sd-jwt+json values
      are represented as a JSON Object; UTF-8 encoding SHOULD be
      employed for the JSON object.
   *  Security considerations: See the Security Considerations section
      of [[ this specification ]], and [RFC7515].
   *  Interoperability considerations: n/a
   *  Published specification: [[ this specification ]]
   *  Applications that use this media type: TBD
   *  Fragment identifier considerations: n/a
   *  Additional information:
      -  Magic number(s): n/a
      -  File extension(s): n/a
      -  Macintosh file type code(s): n/a
   *  Person & email address to contact for further information: Daniel
      Fett, mail@danielfett.de
   *  Intended usage: COMMON
   *  Restrictions on usage: none
   *  Author: Daniel Fett, mail@danielfett.de
   *  Change Controller: IETF
   *  Provisional registration?  No


   To indicate that the content is a Key Binding JWT:

   *  Type name: application
   *  Subtype name: kb+jwt
   *  Required parameters: n/a
   *  Optional parameters: n/a
   *  Encoding considerations: binary; A Key Binding JWT is a JWT; JWT
      values are encoded as a series of base64url-encoded values (some
      of which may be the empty string) separated by period ('.')
      characters.
   *  Security considerations: See the Security Considerations section
      of [[ this specification ]], [RFC7519], and [RFC8725].
   *  Interoperability considerations: n/a
   *  Published specification: [[ this specification ]]
   *  Applications that use this media type: TBD
   *  Fragment identifier considerations: n/a
   *  Additional information:
      -  Magic number(s): n/a
      -  File extension(s): n/a
      -  Macintosh file type code(s): n/a
   *  Person & email address to contact for further information: Daniel
      Fett, mail@danielfett.de
   *  Intended usage: COMMON
   *  Restrictions on usage: none
   *  Author: Daniel Fett, mail@danielfett.de
   *  Change Controller: IETF



Fett, et al.            Expires 5 September 2024               [Page 45]

Internet-Draft                   SD-JWT                       March 2024


   *  Provisional registration?  No

13.3.  Structured Syntax Suffix Registration

   This section requests registration of the "+sd-jwt" structured syntax
   suffix in the "Structured Syntax Suffix" registry
   [IANA.StructuredSuffix] in the manner described in [RFC6838], which
   can be used to indicate that the media type is encoded as an SD-JWT.

   *  Name: SD-JWT
   *  +suffix: +sd-jwt
   *  References: [[ this specification ]]
   *  Encoding considerations: binary; SD-JWT values are a series of
      base64url-encoded values (some of which may be the empty string)
      separated by period ('.') or tilde ('~') characters.
   *  Interoperability considerations: n/a
   *  Fragment identifier considerations: n/a
   *  Security considerations: See the Security Considerations section
      of [[ this specification ]], [RFC7519], and [RFC8725].
   *  Contact: Daniel Fett, mail@danielfett.de
   *  Author/Change controller: IETF

14.  References

14.1.  Normative References

   [RFC0020]  Cerf, V., "ASCII format for network interchange", STD 80,
              RFC 20, DOI 10.17487/RFC0020, October 1969,
              <https://www.rfc-editor.org/info/rfc20>.

   [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/info/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/info/rfc7515>.

   [RFC7516]  Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
              RFC 7516, DOI 10.17487/RFC7516, May 2015,
              <https://www.rfc-editor.org/info/rfc7516>.

   [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/info/rfc7519>.





Fett, et al.            Expires 5 September 2024               [Page 46]

Internet-Draft                   SD-JWT                       March 2024


   [RFC7800]  Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
              Possession Key Semantics for JSON Web Tokens (JWTs)",
              RFC 7800, DOI 10.17487/RFC7800, April 2016,
              <https://www.rfc-editor.org/info/rfc7800>.

   [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/info/rfc8174>.

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.

14.2.  Informative References

   [EUDIW.ARF]
              Commission, E., "The European Digital Identity Wallet
              Architecture and Reference Framework", <https://digital-
              strategy.ec.europa.eu/en/library/european-digital-
              identity-wallet-architecture-and-reference-framework>.

   [I-D.ietf-oauth-sd-jwt-vc]
              Terbu, O., Fett, D., and B. Campbell, "SD-JWT-based
              Verifiable Credentials (SD-JWT VC)", Work in Progress,
              Internet-Draft, draft-ietf-oauth-sd-jwt-vc-02, 27 February
              2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
              oauth-sd-jwt-vc-02>.

   [IANA.Hash.Algorithms]
              IANA, "Named Information Hash Algorithm",
              <https://www.iana.org/assignments/named-information/named-
              information.xhtml>.

   [IANA.JWS.Algorithms]
              IANA, "JSON Web Signature and Encryption Algorithms",
              <https://www.iana.org/assignments/jose/jose.xhtml#web-
              signature-encryption-algorithms>.

   [IANA.JWT] IANA, "JSON Web Token Claims",
              <https://www.iana.org/assignments/jwt>.

   [IANA.MediaTypes]
              IANA, "Media Types", <https://www.iana.org/assignments/
              media-types/media-types.xhtml>.






Fett, et al.            Expires 5 September 2024               [Page 47]

Internet-Draft                   SD-JWT                       March 2024


   [IANA.StructuredSuffix]
              IANA, "Structured Syntax Suffixs",
              <https://www.iana.org/assignments/media-type-structured-
              suffix/media-type-structured-suffix.xhtml>.

   [ISO.29100]
              ISO, "ISO/IEC 29100:2011 Information technology — Security
              techniques — Privacy framework",
              <https://standards.iso.org/ittf/
              PubliclyAvailableStandards/index.html>.

   [OIDC.IDA] Lodderstedt, T., Fett, D., Haine, M., Pulido, A., Lehmann,
              K., and K. Koiwai, "OpenID Connect for Identity Assurance
              1.0", <https://openid.net/specs/openid-connect-4-identity-
              assurance-1_0-13.html>.

   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Two: Media Types", RFC 2046,
              DOI 10.17487/RFC2046, November 1996,
              <https://www.rfc-editor.org/info/rfc2046>.

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,
              <https://www.rfc-editor.org/info/rfc4086>.

   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13,
              RFC 6838, DOI 10.17487/RFC6838, January 2013,
              <https://www.rfc-editor.org/info/rfc6838>.

   [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7517, May 2015,
              <https://www.rfc-editor.org/info/rfc7517>.

   [RFC8725]  Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
              Current Practices", BCP 225, RFC 8725,
              DOI 10.17487/RFC8725, February 2020,
              <https://www.rfc-editor.org/info/rfc8725>.

   [RFC8785]  Rundgren, A., Jordan, B., and S. Erdtman, "JSON
              Canonicalization Scheme (JCS)", RFC 8785,
              DOI 10.17487/RFC8785, June 2020,
              <https://www.rfc-editor.org/info/rfc8785>.







Fett, et al.            Expires 5 September 2024               [Page 48]

Internet-Draft                   SD-JWT                       March 2024


   [VC_DATA_v2.0]
              Sporny, M., Steele, O., Jones, M. B., Cohen, G., and O.
              Terbu, "Verifiable Credentials Data Model 2.0", 7 March
              2023, <https://www.w3.org/TR/vc-data-model-2.0/>.

Appendix A.  Additional Examples

   Important: The following examples are not normative and are provided
   for illustrative purposes only.  In particular, neither the structure
   of the claims nor the selection of selectively disclosable claims is
   normative.

   Line breaks have been added for readability.

A.1.  Example 2: Handling Structured Claims

   In this example, in contrast to Example 1 (#example-1), the Issuer
   decided to create a structured object for the address claim, allowing
   to separately disclose individual members of the claim.

   The Issuer is using the following input claim set:

   {
     "sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c",
     "given_name": "太郎",
     "family_name": "山田",
     "email": "\"unusual email address\"@example.jp",
     "phone_number": "+81-80-1234-5678",
     "address": {
       "street_address": "東京都港区芝公園4丁目2−8",
       "locality": "東京都",
       "region": "港区",
       "country": "JP"
     },
     "birthdate": "1940-01-01"
   }

   The Issuer also decided to add decoy digests to prevent the Verifier
   from deducing the true number of claims.

   The following payload is used for the SD-JWT:










Fett, et al.            Expires 5 September 2024               [Page 49]

Internet-Draft                   SD-JWT                       March 2024


   {
     "_sd": [
       "C9inp6YoRaEXR427zYJP7Qrk1WH_8bdwOA_YUrUnGQU",
       "Kuet1yAa0HIQvYnOVd59hcViO9Ug6J2kSfqYRBeowvE",
       "MMldOFFzB2d0umlmpTIaGerhWdU_PpYfLvKhh_f_9aY",
       "X6ZAYOII2vPN40V7xExZwVwz7yRmLNcVwt5DL8RLv4g",
       "Y34zmIo0QLLOtdMpXGwjBgLvr17yEhhYT0FGofR-aIE",
       "fyGp0WTwwPv2JDQln1lSiaeobZsMWA10bQ5989-9DTs",
       "ommFAicVT8LGHCB0uywx7fYuo3MHYKO15cz-RZEYM5Q",
       "s0BKYsLWxQQeU8tVlltM7MKsIRTrEIa1PkJmqxBBf5U"
     ],
     "iss": "https://issuer.example.com",
     "iat": 1683000000,
     "exp": 1883000000,
     "address": {
       "_sd": [
         "6aUhzYhZ7SJ1kVmagQAO3u2ETN2CC1aHheZpKnaF0_E",
         "AzLlFobkJ2xiaupREPyoJz-9-NSldB6Cgjr7fUyoHzg",
         "PzzcVu0qbMuBGSjulfewzkesD9zutOExn5EWNwkrQ-k",
         "b2Dkw0jcIF9rGg8_PF8ZcvncW7zwZj5ryBWvXfrpzek",
         "cPYJHIZ8Vu-f9CCyVub2UfgEk8jvvXezwK1p_JneeXQ",
         "glT3hrSU7fSWgwF5UDZmWwBTw32gnUldIhi8hGVCaV4",
         "rvJd6iq6T5ejmsBMoGwuNXh9qAAFATAci40oidEeVsA",
         "uNHoWYhXsZhVJCNE2Dqy-zqt7t69gJKy5QaFv7GrMX4"
       ]
     },
     "_sd_alg": "sha-256"
   }

   The following Disclosures are created:

   *Claim sub*:

   *  SHA-256 Hash: X6ZAYOII2vPN40V7xExZwVwz7yRmLNcVwt5DL8RLv4g
   *  Disclosure:
      WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN1YiIsICI2YzVjMGE0OS1i
      NTg5LTQzMWQtYmFlNy0yMTkxMjJhOWVjMmMiXQ
   *  Contents: ["2GLC42sKQveCfGfryNRN9w", "sub",
      "6c5c0a49-b589-431d-bae7-219122a9ec2c"]

   *Claim given_name*:

   *  SHA-256 Hash: ommFAicVT8LGHCB0uywx7fYuo3MHYKO15cz-RZEYM5Q
   *  Disclosure:
      WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiXHU1
      OTJhXHU5MGNlIl0
   *  Contents: ["eluV5Og3gSNII8EYnsxA_A", "given_name", "\u592a\u90ce"]




Fett, et al.            Expires 5 September 2024               [Page 50]

Internet-Draft                   SD-JWT                       March 2024


   *Claim family_name*:

   *  SHA-256 Hash: C9inp6YoRaEXR427zYJP7Qrk1WH_8bdwOA_YUrUnGQU
   *  Disclosure:
      WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIlx1
      NWM3MVx1NzUzMCJd
   *  Contents: ["6Ij7tM-a5iVPGboS5tmvVA", "family_name",
      "\u5c71\u7530"]

   *Claim email*:

   *  SHA-256 Hash: Kuet1yAa0HIQvYnOVd59hcViO9Ug6J2kSfqYRBeowvE
   *  Disclosure:
      WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImVtYWlsIiwgIlwidW51c3Vh
      bCBlbWFpbCBhZGRyZXNzXCJAZXhhbXBsZS5qcCJd
   *  Contents: ["eI8ZWm9QnKPpNPeNenHdhQ", "email", "\"unusual email
      address\"@example.jp"]

   *Claim phone_number*:

   *  SHA-256 Hash: s0BKYsLWxQQeU8tVlltM7MKsIRTrEIa1PkJmqxBBf5U
   *  Disclosure:
      WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJlciIsICIr
      ODEtODAtMTIzNC01Njc4Il0
   *  Contents: ["Qg_O64zqAxe412a108iroA", "phone_number",
      "+81-80-1234-5678"]

   *Claim street_address*:

   *  SHA-256 Hash: 6aUhzYhZ7SJ1kVmagQAO3u2ETN2CC1aHheZpKnaF0_E
   *  Disclosure:
      WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInN0cmVldF9hZGRyZXNzIiwg
      Ilx1Njc3MVx1NGVhY1x1OTBmZFx1NmUyZlx1NTMzYVx1ODI5ZFx1NTE2Y1x1
      NTcxMlx1ZmYxNFx1NGUwMVx1NzZlZVx1ZmYxMlx1MjIxMlx1ZmYxOCJd
   *  Contents: ["AJx-095VPrpTtN4QMOqROA", "street_address",
      "\u6771\u4eac\u
      90fd\u6e2f\u533a\u829d\u516c\u5712\uff14\u4e01\u76ee\uff12\u
      2212\uff18"]

   *Claim locality*:

   *  SHA-256 Hash: rvJd6iq6T5ejmsBMoGwuNXh9qAAFATAci40oidEeVsA
   *  Disclosure:
      WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImxvY2FsaXR5IiwgIlx1Njc3
      MVx1NGVhY1x1OTBmZCJd
   *  Contents: ["Pc33JM2LchcU_lHggv_ufQ", "locality",
      "\u6771\u4eac\u90fd"]




Fett, et al.            Expires 5 September 2024               [Page 51]

Internet-Draft                   SD-JWT                       March 2024


   *Claim region*:

   *  SHA-256 Hash: PzzcVu0qbMuBGSjulfewzkesD9zutOExn5EWNwkrQ-k
   *  Disclosure:
      WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInJlZ2lvbiIsICJcdTZlMmZc
      dTUzM2EiXQ
   *  Contents: ["G02NSrQfjFXQ7Io09syajA", "region", "\u6e2f\u533a"]

   *Claim country*:

   *  SHA-256 Hash: uNHoWYhXsZhVJCNE2Dqy-zqt7t69gJKy5QaFv7GrMX4
   *  Disclosure:
      WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImNvdW50cnkiLCAiSlAiXQ
   *  Contents: ["lklxF5jMYlGTPUovMNIvCA", "country", "JP"]

   *Claim birthdate*:

   *  SHA-256 Hash: MMldOFFzB2d0umlmpTIaGerhWdU_PpYfLvKhh_f_9aY
   *  Disclosure:
      WyJ5eXRWYmRBUEdjZ2wyckk0QzlHU29nIiwgImJpcnRoZGF0ZSIsICIxOTQw
      LTAxLTAxIl0
   *  Contents: ["yytVbdAPGcgl2rI4C9GSog", "birthdate", "1940-01-01"]

   The following decoy digests are added:

   *  AzLlFobkJ2xiaupREPyoJz-9-NSldB6Cgjr7fUyoHzg
   *  cPYJHIZ8Vu-f9CCyVub2UfgEk8jvvXezwK1p_JneeXQ
   *  glT3hrSU7fSWgwF5UDZmWwBTw32gnUldIhi8hGVCaV4
   *  b2Dkw0jcIF9rGg8_PF8ZcvncW7zwZj5ryBWvXfrpzek
   *  fyGp0WTwwPv2JDQln1lSiaeobZsMWA10bQ5989-9DTs
   *  Y34zmIo0QLLOtdMpXGwjBgLvr17yEhhYT0FGofR-aIE

   The following is how a presentation of the SD-JWT that discloses only
   region and country of the address property and without a Key Binding
   JWT could look like:
















Fett, et al.            Expires 5 September 2024               [Page 52]

Internet-Draft                   SD-JWT                       March 2024


   eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb
   IkM5aW5wNllvUmFFWFI0Mjd6WUpQN1FyazFXSF84YmR3T0FfWVVyVW5HUVUiLCAiS3Vl
   dDF5QWEwSElRdlluT1ZkNTloY1ZpTzlVZzZKMmtTZnFZUkJlb3d2RSIsICJNTWxkT0ZG
   ekIyZDB1bWxtcFRJYUdlcmhXZFVfUHBZZkx2S2hoX2ZfOWFZIiwgIlg2WkFZT0lJMnZQ
   TjQwVjd4RXhad1Z3ejd5Um1MTmNWd3Q1REw4Ukx2NGciLCAiWTM0em1JbzBRTExPdGRN
   cFhHd2pCZ0x2cjE3eUVoaFlUMEZHb2ZSLWFJRSIsICJmeUdwMFdUd3dQdjJKRFFsbjFs
   U2lhZW9iWnNNV0ExMGJRNTk4OS05RFRzIiwgIm9tbUZBaWNWVDhMR0hDQjB1eXd4N2ZZ
   dW8zTUhZS08xNWN6LVJaRVlNNVEiLCAiczBCS1lzTFd4UVFlVTh0VmxsdE03TUtzSVJU
   ckVJYTFQa0ptcXhCQmY1VSJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu
   Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAiYWRkcmVz
   cyI6IHsiX3NkIjogWyI2YVVoelloWjdTSjFrVm1hZ1FBTzN1MkVUTjJDQzFhSGhlWnBL
   bmFGMF9FIiwgIkF6TGxGb2JrSjJ4aWF1cFJFUHlvSnotOS1OU2xkQjZDZ2pyN2ZVeW9I
   emciLCAiUHp6Y1Z1MHFiTXVCR1NqdWxmZXd6a2VzRDl6dXRPRXhuNUVXTndrclEtayIs
   ICJiMkRrdzBqY0lGOXJHZzhfUEY4WmN2bmNXN3p3Wmo1cnlCV3ZYZnJwemVrIiwgImNQ
   WUpISVo4VnUtZjlDQ3lWdWIyVWZnRWs4anZ2WGV6d0sxcF9KbmVlWFEiLCAiZ2xUM2hy
   U1U3ZlNXZ3dGNVVEWm1Xd0JUdzMyZ25VbGRJaGk4aEdWQ2FWNCIsICJydkpkNmlxNlQ1
   ZWptc0JNb0d3dU5YaDlxQUFGQVRBY2k0MG9pZEVlVnNBIiwgInVOSG9XWWhYc1poVkpD
   TkUyRHF5LXpxdDd0NjlnSkt5NVFhRnY3R3JNWDQiXX0sICJfc2RfYWxnIjogInNoYS0y
   NTYifQ.H0uI6M5t7BDfAt_a3Rw5zq4IiYNtkMORENcQFXYkW1LURRp66baOXRcxb164s
   nsUJneI-XLM2-COCTX1y7Sedw~WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInJlZ2
   lvbiIsICJcdTZlMmZcdTUzM2EiXQ~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImN
   vdW50cnkiLCAiSlAiXQ~

A.2.  Example 3 - Complex Structured SD-JWT

   In this example, an SD-JWT with a complex object is represented.  The
   data structures defined in OIDC4IDA [OIDC.IDA] are used.

   The Issuer is using the following input claim set:






















Fett, et al.            Expires 5 September 2024               [Page 53]

Internet-Draft                   SD-JWT                       March 2024


   {
     "verified_claims": {
       "verification": {
         "trust_framework": "de_aml",
         "time": "2012-04-23T18:25Z",
         "verification_process": "f24c6f-6d3f-4ec5-973e-b0d8506f3bc7",
         "evidence": [
           {
             "type": "document",
             "method": "pipp",
             "time": "2012-04-22T11:30Z",
             "document": {
               "type": "idcard",
               "issuer": {
                 "name": "Stadt Augsburg",
                 "country": "DE"
               },
               "number": "53554554",
               "date_of_issuance": "2010-03-23",
               "date_of_expiry": "2020-03-22"
             }
           }
         ]
       },
       "claims": {
         "given_name": "Max",
         "family_name": "Müller",
         "nationalities": [
           "DE"
         ],
         "birthdate": "1956-01-28",
         "place_of_birth": {
           "country": "IS",
           "locality": "Þykkvabæjarklaustur"
         },
         "address": {
           "locality": "Maxstadt",
           "postal_code": "12344",
           "country": "DE",
           "street_address": "Weidenstraße 22"
         }
       }
     },
     "birth_middle_name": "Timotheus",
     "salutation": "Dr.",
     "msisdn": "49123456789"
   }




Fett, et al.            Expires 5 September 2024               [Page 54]

Internet-Draft                   SD-JWT                       March 2024


   The following payload is used for the SD-JWT:

   {
     "_sd": [
       "-aSznId9mWM8ocuQolCllsxVggq1-vHW4OtnhUtVmWw",
       "IKbrYNn3vA7WEFrysvbdBJjDDU_EvQIr0W18vTRpUSg",
       "otkxuT14nBiwzNJ3MPaOitOl9pVnXOaEHal_xkyNfKI"
     ],
     "iss": "https://issuer.example.com",
     "iat": 1683000000,
     "exp": 1883000000,
     "verified_claims": {
       "verification": {
         "_sd": [
           "7h4UE9qScvDKodXVCuoKfKBJpVBfXMF_TmAGVaZe3Sc",
           "vTwe3raHIFYgFA3xaUD2aMxFz5oDo8iBu05qKlOg9Lw"
         ],
         "trust_framework": "de_aml",
         "evidence": [
           {
             "...": "tYJ0TDucyZZCRMbROG4qRO5vkPSFRxFhUELc18CSl3k"
           }
         ]
       },
       "claims": {
         "_sd": [
           "RiOiCn6_w5ZHaadkQMrcQJf0Jte5RwurRs54231DTlo",
           "S_498bbpKzB6Eanftss0xc7cOaoneRr3pKr7NdRmsMo",
           "WNA-UNK7F_zhsAb9syWO6IIQ1uHlTmOU8r8CvJ0cIMk",
           "Wxh_sV3iRH9bgrTBJi-aYHNCLt-vjhX1sd-igOf_9lk",
           "_O-wJiH3enSB4ROHntToQT8JmLtz-mhO2f1c89XoerQ",
           "hvDXhwmGcJQsBCA2OtjuLAcwAMpDsaU0nkovcKOqWNE"
         ]
       }
     },
     "_sd_alg": "sha-256"
   }

   The following Disclosures are created by the Issuer:

   *Claim time*:

   *  SHA-256 Hash: vTwe3raHIFYgFA3xaUD2aMxFz5oDo8iBu05qKlOg9Lw
   *  Disclosure:
      WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInRpbWUiLCAiMjAxMi0wNC0y
      M1QxODoyNVoiXQ
   *  Contents: ["2GLC42sKQveCfGfryNRN9w", "time", "2012-04-23T18:25Z"]




Fett, et al.            Expires 5 September 2024               [Page 55]

Internet-Draft                   SD-JWT                       March 2024


   *Claim verification_process*:

   *  SHA-256 Hash: 7h4UE9qScvDKodXVCuoKfKBJpVBfXMF_TmAGVaZe3Sc
   *  Disclosure:
      WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgInZlcmlmaWNhdGlvbl9wcm9j
      ZXNzIiwgImYyNGM2Zi02ZDNmLTRlYzUtOTczZS1iMGQ4NTA2ZjNiYzciXQ
   *  Contents: ["eluV5Og3gSNII8EYnsxA_A", "verification_process",
      "f24c6f-6d3f-4ec5-973e-b0d8506f3bc7"]

   *Claim type*:

   *  SHA-256 Hash: G5EnhOAOoU9X_6QMNvzFXjpEA_Rc-AEtm1bG_wcaKIk
   *  Disclosure:
      WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInR5cGUiLCAiZG9jdW1lbnQi
      XQ
   *  Contents: ["6Ij7tM-a5iVPGboS5tmvVA", "type", "document"]

   *Claim method*:

   *  SHA-256 Hash: WpxQ4HSoEtcTmCCKOeDslB_emucYLz2oO8oHNr1bEVQ
   *  Disclosure:
      WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm1ldGhvZCIsICJwaXBwIl0
   *  Contents: ["eI8ZWm9QnKPpNPeNenHdhQ", "method", "pipp"]

   *Claim time*:

   *  SHA-256 Hash: 9wpjVPWuD7PK0nsQDL8B06lmdgV3LVybhHydQpTNyLI
   *  Disclosure:
      WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInRpbWUiLCAiMjAxMi0wNC0y
      MlQxMTozMFoiXQ
   *  Contents: ["Qg_O64zqAxe412a108iroA", "time", "2012-04-22T11:30Z"]

   *Claim document*:

   *  SHA-256 Hash: IhwFrWUB63RcZq9yvgZ0XPc7Gowh3O2kqXeBIswg1B4
   *  Disclosure:
      WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRvY3VtZW50IiwgeyJ0eXBl
      IjogImlkY2FyZCIsICJpc3N1ZXIiOiB7Im5hbWUiOiAiU3RhZHQgQXVnc2J1
      cmciLCAiY291bnRyeSI6ICJERSJ9LCAibnVtYmVyIjogIjUzNTU0NTU0Iiwg
      ImRhdGVfb2ZfaXNzdWFuY2UiOiAiMjAxMC0wMy0yMyIsICJkYXRlX29mX2V4
      cGlyeSI6ICIyMDIwLTAzLTIyIn1d
   *  Contents: ["AJx-095VPrpTtN4QMOqROA", "document", {"type":
      "idcard",
      "issuer": {"name": "Stadt Augsburg", "country": "DE"},
      "number": "53554554", "date_of_issuance": "2010-03-23",
      "date_of_expiry": "2020-03-22"}]

   *Array Entry*:



Fett, et al.            Expires 5 September 2024               [Page 56]

Internet-Draft                   SD-JWT                       March 2024


   *  SHA-256 Hash: tYJ0TDucyZZCRMbROG4qRO5vkPSFRxFhUELc18CSl3k
   *  Disclosure:
      WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgeyJfc2QiOiBbIjl3cGpWUFd1
      RDdQSzBuc1FETDhCMDZsbWRnVjNMVnliaEh5ZFFwVE55TEkiLCAiRzVFbmhP
      QU9vVTlYXzZRTU52ekZYanBFQV9SYy1BRXRtMWJHX3djYUtJayIsICJJaHdG
      cldVQjYzUmNacTl5dmdaMFhQYzdHb3doM08ya3FYZUJJc3dnMUI0IiwgIldw
      eFE0SFNvRXRjVG1DQ0tPZURzbEJfZW11Y1lMejJvTzhvSE5yMWJFVlEiXX1d
   *  Contents: ["Pc33JM2LchcU_lHggv_ufQ", {"_sd":
      ["9wpjVPWuD7PK0nsQDL8B06lmdgV3LVybhHydQpTNyLI",
      "G5EnhOAOoU9X_6QMNvzFXjpEA_Rc-AEtm1bG_wcaKIk",
      "IhwFrWUB63RcZq9yvgZ0XPc7Gowh3O2kqXeBIswg1B4",
      "WpxQ4HSoEtcTmCCKOeDslB_emucYLz2oO8oHNr1bEVQ"]}]

   *Claim given_name*:

   *  SHA-256 Hash: S_498bbpKzB6Eanftss0xc7cOaoneRr3pKr7NdRmsMo
   *  Disclosure:
      WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdpdmVuX25hbWUiLCAiTWF4
      Il0
   *  Contents: ["G02NSrQfjFXQ7Io09syajA", "given_name", "Max"]

   *Claim family_name*:

   *  SHA-256 Hash: Wxh_sV3iRH9bgrTBJi-aYHNCLt-vjhX1sd-igOf_9lk
   *  Disclosure:
      WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImZhbWlseV9uYW1lIiwgIk1c
      dTAwZmNsbGVyIl0
   *  Contents: ["lklxF5jMYlGTPUovMNIvCA", "family_name", "M\u00fcller"]

   *Claim nationalities*:

   *  SHA-256 Hash: hvDXhwmGcJQsBCA2OtjuLAcwAMpDsaU0nkovcKOqWNE
   *  Disclosure:
      WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIm5hdGlvbmFsaXRpZXMiLCBb
      IkRFIl1d
   *  Contents: ["nPuoQnkRFq3BIeAm7AnXFA", "nationalities", ["DE"]]

   *Claim birthdate*:

   *  SHA-256 Hash: WNA-UNK7F_zhsAb9syWO6IIQ1uHlTmOU8r8CvJ0cIMk
   *  Disclosure:
      WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImJpcnRoZGF0ZSIsICIxOTU2
      LTAxLTI4Il0
   *  Contents: ["5bPs1IquZNa0hkaFzzzZNw", "birthdate", "1956-01-28"]

   *Claim place_of_birth*:

   *  SHA-256 Hash: RiOiCn6_w5ZHaadkQMrcQJf0Jte5RwurRs54231DTlo



Fett, et al.            Expires 5 September 2024               [Page 57]

Internet-Draft                   SD-JWT                       March 2024


   *  Disclosure:
      WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgInBsYWNlX29mX2JpcnRoIiwg
      eyJjb3VudHJ5IjogIklTIiwgImxvY2FsaXR5IjogIlx1MDBkZXlra3ZhYlx1
      MDBlNmphcmtsYXVzdHVyIn1d
   *  Contents: ["5a2W0_NrlEZzfqmk_7Pq-w", "place_of_birth", {"country":
      "IS", "locality": "\u00deykkvab\u00e6jarklaustur"}]

   *Claim address*:

   *  SHA-256 Hash: _O-wJiH3enSB4ROHntToQT8JmLtz-mhO2f1c89XoerQ
   *  Disclosure:
      WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImFkZHJlc3MiLCB7ImxvY2Fs
      aXR5IjogIk1heHN0YWR0IiwgInBvc3RhbF9jb2RlIjogIjEyMzQ0IiwgImNv
      dW50cnkiOiAiREUiLCAic3RyZWV0X2FkZHJlc3MiOiAiV2VpZGVuc3RyYVx1
      MDBkZmUgMjIifV0
   *  Contents: ["y1sVU5wdfJahVdgwPgS7RQ", "address", {"locality":
      "Maxstadt", "postal_code": "12344", "country": "DE",
      "street_address": "Weidenstra\u00dfe 22"}]

   *Claim birth_middle_name*:

   *  SHA-256 Hash: otkxuT14nBiwzNJ3MPaOitOl9pVnXOaEHal_xkyNfKI
   *  Disclosure:
      WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImJpcnRoX21pZGRsZV9uYW1l
      IiwgIlRpbW90aGV1cyJd
   *  Contents: ["HbQ4X8srVW3QDxnIJdqyOA", "birth_middle_name",
      "Timotheus"]

   *Claim salutation*:

   *  SHA-256 Hash: -aSznId9mWM8ocuQolCllsxVggq1-vHW4OtnhUtVmWw
   *  Disclosure:
      WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgInNhbHV0YXRpb24iLCAiRHIu
      Il0
   *  Contents: ["C9GSoujviJquEgYfojCb1A", "salutation", "Dr."]

   *Claim msisdn*:

   *  SHA-256 Hash: IKbrYNn3vA7WEFrysvbdBJjDDU_EvQIr0W18vTRpUSg
   *  Disclosure:
      WyJreDVrRjE3Vi14MEptd1V4OXZndnR3IiwgIm1zaXNkbiIsICI0OTEyMzQ1
      Njc4OSJd
   *  Contents: ["kx5kF17V-x0JmwUx9vgvtw", "msisdn", "49123456789"]

   The following is how a presentation of the SD-JWT without a Key
   Binding JWT could look like:





Fett, et al.            Expires 5 September 2024               [Page 58]

Internet-Draft                   SD-JWT                       March 2024


   eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb
   Ii1hU3puSWQ5bVdNOG9jdVFvbENsbHN4VmdncTEtdkhXNE90bmhVdFZtV3ciLCAiSUti
   cllObjN2QTdXRUZyeXN2YmRCSmpERFVfRXZRSXIwVzE4dlRScFVTZyIsICJvdGt4dVQx
   NG5CaXd6TkozTVBhT2l0T2w5cFZuWE9hRUhhbF94a3lOZktJIl0sICJpc3MiOiAiaHR0
   cHM6Ly9pc3N1ZXIuZXhhbXBsZS5jb20iLCAiaWF0IjogMTY4MzAwMDAwMCwgImV4cCI6
   IDE4ODMwMDAwMDAsICJ2ZXJpZmllZF9jbGFpbXMiOiB7InZlcmlmaWNhdGlvbiI6IHsi
   X3NkIjogWyI3aDRVRTlxU2N2REtvZFhWQ3VvS2ZLQkpwVkJmWE1GX1RtQUdWYVplM1Nj
   IiwgInZUd2UzcmFISUZZZ0ZBM3hhVUQyYU14Rno1b0RvOGlCdTA1cUtsT2c5THciXSwg
   InRydXN0X2ZyYW1ld29yayI6ICJkZV9hbWwiLCAiZXZpZGVuY2UiOiBbeyIuLi4iOiAi
   dFlKMFREdWN5WlpDUk1iUk9HNHFSTzV2a1BTRlJ4RmhVRUxjMThDU2wzayJ9XX0sICJj
   bGFpbXMiOiB7Il9zZCI6IFsiUmlPaUNuNl93NVpIYWFka1FNcmNRSmYwSnRlNVJ3dXJS
   czU0MjMxRFRsbyIsICJTXzQ5OGJicEt6QjZFYW5mdHNzMHhjN2NPYW9uZVJyM3BLcjdO
   ZFJtc01vIiwgIldOQS1VTks3Rl96aHNBYjlzeVdPNklJUTF1SGxUbU9VOHI4Q3ZKMGNJ
   TWsiLCAiV3hoX3NWM2lSSDliZ3JUQkppLWFZSE5DTHQtdmpoWDFzZC1pZ09mXzlsayIs
   ICJfTy13SmlIM2VuU0I0Uk9IbnRUb1FUOEptTHR6LW1oTzJmMWM4OVhvZXJRIiwgImh2
   RFhod21HY0pRc0JDQTJPdGp1TEFjd0FNcERzYVUwbmtvdmNLT3FXTkUiXX19LCAiX3Nk
   X2FsZyI6ICJzaGEtMjU2In0.BYUpdUIaUTNj5UlPBk6g0GhDp213yGD_HIMk8P45LwkS
   AfZgc_ayGnf9VC4gebeE-crDoonxf89Y7qsTA-4qdQ~WyIyR0xDNDJzS1F2ZUNmR2Zye
   U5STjl3IiwgInRpbWUiLCAiMjAxMi0wNC0yM1QxODoyNVoiXQ~WyJQYzMzSk0yTGNoY1
   VfbEhnZ3ZfdWZRIiwgeyJfc2QiOiBbIjl3cGpWUFd1RDdQSzBuc1FETDhCMDZsbWRnVj
   NMVnliaEh5ZFFwVE55TEkiLCAiRzVFbmhPQU9vVTlYXzZRTU52ekZYanBFQV9SYy1BRX
   RtMWJHX3djYUtJayIsICJJaHdGcldVQjYzUmNacTl5dmdaMFhQYzdHb3doM08ya3FYZU
   JJc3dnMUI0IiwgIldweFE0SFNvRXRjVG1DQ0tPZURzbEJfZW11Y1lMejJvTzhvSE5yMW
   JFVlEiXX1d~WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm1ldGhvZCIsICJwaXBwI
   l0~WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdpdmVuX25hbWUiLCAiTWF4Il0~W
   yJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImZhbWlseV9uYW1lIiwgIk1cdTAwZmNsb
   GVyIl0~WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImFkZHJlc3MiLCB7ImxvY2Fsa
   XR5IjogIk1heHN0YWR0IiwgInBvc3RhbF9jb2RlIjogIjEyMzQ0IiwgImNvdW50cnkiO
   iAiREUiLCAic3RyZWV0X2FkZHJlc3MiOiAiV2VpZGVuc3RyYVx1MDBkZmUgMjIifV0~

   After the validation, the Verifier will have the following data for
   further processing:



















Fett, et al.            Expires 5 September 2024               [Page 59]

Internet-Draft                   SD-JWT                       March 2024


   {
     "iss": "https://issuer.example.com",
     "iat": 1683000000,
     "exp": 1883000000,
     "verified_claims": {
       "verification": {
         "trust_framework": "de_aml",
         "evidence": [
           {
             "method": "pipp"
           }
         ],
         "time": "2012-04-23T18:25Z"
       },
       "claims": {
         "given_name": "Max",
         "family_name": "Müller",
         "address": {
           "locality": "Maxstadt",
           "postal_code": "12344",
           "country": "DE",
           "street_address": "Weidenstraße 22"
         }
       }
     }
   }

A.3.  Example 4a - SD-JWT-based Verifiable Credentials (SD-JWT VC)

   This example shows how the artifacts defined in this specification
   could be used in the context of SD-JWT-based Verifiable Credentials
   (SD-JWT VC) [I-D.ietf-oauth-sd-jwt-vc] to represent the concept of a
   Person Identification Data (PID) [EUDIW.ARF] using the data of a
   German citizen.

   Key Binding is applied using the Holder's public key passed in a cnf
   claim in the SD-JWT.

   The Issuer is using the following input claim set:












Fett, et al.            Expires 5 September 2024               [Page 60]

Internet-Draft                   SD-JWT                       March 2024


   {
     "vct": "https://bmi.bund.example/credential/pid/1.0",
     "given_name": "Erika",
     "family_name": "Mustermann",
     "birthdate": "1963-08-12",
     "source_document_type": "id_card",
     "address": {
       "street_address": "Heidestraße 17",
       "locality": "Köln",
       "postal_code": "51147",
       "country": "DE"
     },
     "nationalities": [
       "DE"
     ],
     "gender": "female",
     "birth_family_name": "Gabler",
     "place_of_birth": {
       "locality": "Berlin",
       "country": "DE"
     },
     "also_known_as": "Schwester Agnes",
     "age_equal_or_over": {
       "12": true,
       "14": true,
       "16": true,
       "18": true,
       "21": true,
       "65": false
     }
   }

   The following is the issued SD-JWT:

   eyJhbGciOiAiRVMyNTYiLCAidHlwIjogInZjK3NkLWp3dCJ9.eyJfc2QiOiBbIjBIWm1
   uU0lQejMzN2tTV2U3QzM0bC0tODhnekppLWVCSjJWel9ISndBVGciLCAiOVpicGxDN1R
   kRVc3cWFsNkJCWmxNdHFKZG1lRU9pWGV2ZEpsb1hWSmRSUSIsICJJMDBmY0ZVb0RYQ3V
   jcDV5eTJ1anFQc3NEVkdhV05pVWxpTnpfYXdEMGdjIiwgIklFQllTSkdOaFhJbHJRbzU
   4eWtYbTJaeDN5bGw5WmxUdFRvUG8xN1FRaVkiLCAiTGFpNklVNmQ3R1FhZ1hSN0F2R1R
   yblhnU2xkM3o4RUlnX2Z2M2ZPWjFXZyIsICJodkRYaHdtR2NKUXNCQ0EyT3RqdUxBY3d
   BTXBEc2FVMG5rb3ZjS09xV05FIiwgImlrdXVyOFE0azhxM1ZjeUE3ZEMtbU5qWkJrUmV
   EVFUtQ0c0bmlURTdPVFUiLCAicXZ6TkxqMnZoOW80U0VYT2ZNaVlEdXZUeWtkc1dDTmc
   wd1RkbHIwQUVJTSIsICJ3elcxNWJoQ2t2a3N4VnZ1SjhSRjN4aThpNjRsbjFqb183NkJ
   DMm9hMXVnIiwgInpPZUJYaHh2SVM0WnptUWNMbHhLdUVBT0dHQnlqT3FhMXoySW9WeF9
   ZRFEiXSwgImlzcyI6ICJodHRwczovL2lzc3Vlci5leGFtcGxlLmNvbSIsICJpYXQiOiA
   xNjgzMDAwMDAwLCAiZXhwIjogMTg4MzAwMDAwMCwgInZjdCI6ICJodHRwczovL2JtaS5
   idW5kLmV4YW1wbGUvY3JlZGVudGlhbC9waWQvMS4wIiwgImFnZV9lcXVhbF9vcl9vdmV
   yIjogeyJfc2QiOiBbIkZjOElfMDdMT2NnUHdyREpLUXlJR085N3dWc09wbE1Makh2UkM



Fett, et al.            Expires 5 September 2024               [Page 61]

Internet-Draft                   SD-JWT                       March 2024


   0UjQtV2ciLCAiWEx0TGphZFVXYzl6Tl85aE1KUm9xeTQ2VXNDS2IxSXNoWnV1cVVGS1N
   DQSIsICJhb0NDenNDN3A0cWhaSUFoX2lkUkNTQ2E2NDF1eWNuYzh6UGZOV3o4bngwIiw
   gImYxLVAwQTJkS1dhdnYxdUZuTVgyQTctRVh4dmhveHY1YUhodUVJTi1XNjQiLCAiazV
   oeTJyMDE4dnJzSmpvLVZqZDZnNnl0N0Fhb25Lb25uaXVKOXplbDNqbyIsICJxcDdaX0t
   5MVlpcDBzWWdETzN6VnVnMk1GdVBOakh4a3NCRG5KWjRhSS1jIl19LCAiX3NkX2FsZyI
   6ICJzaGEtMjU2IiwgImNuZiI6IHsiandrIjogeyJrdHkiOiAiRUMiLCAiY3J2IjogIlA
   tMjU2IiwgIngiOiAiVENBRVIxOVp2dTNPSEY0ajRXNHZmU1ZvSElQMUlMaWxEbHM3dkN
   lR2VtYyIsICJ5IjogIlp4amlXV2JaTVFHSFZXS1ZRNGhiU0lpcnNWZnVlY0NFNnQ0alQ
   5RjJIWlEifX19.jeF9GjGbjCr0NND0SbkV4HeSpsysixALFScJl4bYkIykXhF6cRtqni
   64_d7X6Ef8Rx80rfsgXe0H7TdiSoIJOw~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3Iiw
   gImdpdmVuX25hbWUiLCAiRXJpa2EiXQ~WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwg
   ImZhbWlseV9uYW1lIiwgIk11c3Rlcm1hbm4iXQ~WyI2SWo3dE0tYTVpVlBHYm9TNXRtd
   lZBIiwgImJpcnRoZGF0ZSIsICIxOTYzLTA4LTEyIl0~WyJlSThaV205UW5LUHBOUGVOZ
   W5IZGhRIiwgInNvdXJjZV9kb2N1bWVudF90eXBlIiwgImlkX2NhcmQiXQ~WyJRZ19PNj
   R6cUF4ZTQxMmExMDhpcm9BIiwgInN0cmVldF9hZGRyZXNzIiwgIkhlaWRlc3RyYVx1MD
   BkZmUgMTciXQ~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImxvY2FsaXR5IiwgIkt
   cdTAwZjZsbiJd~WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgInBvc3RhbF9jb2RlIi
   wgIjUxMTQ3Il0~WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImNvdW50cnkiLCAiRE
   UiXQ~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImFkZHJlc3MiLCB7Il9zZCI6IFs
   iWEZjN3pYUG03enpWZE15d20yRXVCZmxrYTVISHF2ZjhVcF9zek5HcXZpZyIsICJiZDF
   FVnpnTm9wVWs0RVczX2VRMm4zX05VNGl1WE9IdjlYYkdITjNnMVRFIiwgImZfRlFZZ3Z
   RV3Z5VnFObklYc0FSbE55ZTdZR3A4RTc3Z1JBamFxLXd2bnciLCAidjRra2JfcFAxamx
   2VWJTanR5YzVicWNXeUEtaThYTHZoVllZN1pUMHRiMCJdfV0~WyJuUHVvUW5rUkZxM0J
   JZUFtN0FuWEZBIiwgIm5hdGlvbmFsaXRpZXMiLCBbIkRFIl1d~WyI1YlBzMUlxdVpOYT
   Boa2FGenp6Wk53IiwgImdlbmRlciIsICJmZW1hbGUiXQ~WyI1YTJXMF9OcmxFWnpmcW1
   rXzdQcS13IiwgImJpcnRoX2ZhbWlseV9uYW1lIiwgIkdhYmxlciJd~WyJ5MXNWVTV3ZG
   ZKYWhWZGd3UGdTN1JRIiwgImxvY2FsaXR5IiwgIkJlcmxpbiJd~WyJIYlE0WDhzclZXM
   1FEeG5JSmRxeU9BIiwgInBsYWNlX29mX2JpcnRoIiwgeyJfc2QiOiBbIldwaEhvSUR5b
   1diQXBEQzR6YnV3UjQweGwweExoRENfY3Y0dHNTNzFyRUEiXSwgImNvdW50cnkiOiAiR
   EUifV0~WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgImFsc29fa25vd25fYXMiLCAiU
   2Nod2VzdGVyIEFnbmVzIl0~WyJreDVrRjE3Vi14MEptd1V4OXZndnR3IiwgIjEyIiwgd
   HJ1ZV0~WyJIM28xdXN3UDc2MEZpMnllR2RWQ0VRIiwgIjE0IiwgdHJ1ZV0~WyJPQktsV
   FZsdkxnLUFkd3FZR2JQOFpBIiwgIjE2IiwgdHJ1ZV0~WyJNMEpiNTd0NDF1YnJrU3V5c
   kRUM3hBIiwgIjE4IiwgdHJ1ZV0~WyJEc210S05ncFY0ZEFIcGpyY2Fvc0F3IiwgIjIxI
   iwgdHJ1ZV0~WyJlSzVvNXBIZmd1cFBwbHRqMXFoQUp3IiwgIjY1IiwgZmFsc2Vd~

   The following payload is used for the SD-JWT:














Fett, et al.            Expires 5 September 2024               [Page 62]

Internet-Draft                   SD-JWT                       March 2024


   {
     "_sd": [
       "0HZmnSIPz337kSWe7C34l--88gzJi-eBJ2Vz_HJwATg",
       "9ZbplC7TdEW7qal6BBZlMtqJdmeEOiXevdJloXVJdRQ",
       "I00fcFUoDXCucp5yy2ujqPssDVGaWNiUliNz_awD0gc",
       "IEBYSJGNhXIlrQo58ykXm2Zx3yll9ZlTtToPo17QQiY",
       "Lai6IU6d7GQagXR7AvGTrnXgSld3z8EIg_fv3fOZ1Wg",
       "hvDXhwmGcJQsBCA2OtjuLAcwAMpDsaU0nkovcKOqWNE",
       "ikuur8Q4k8q3VcyA7dC-mNjZBkReDTU-CG4niTE7OTU",
       "qvzNLj2vh9o4SEXOfMiYDuvTykdsWCNg0wTdlr0AEIM",
       "wzW15bhCkvksxVvuJ8RF3xi8i64ln1jo_76BC2oa1ug",
       "zOeBXhxvIS4ZzmQcLlxKuEAOGGByjOqa1z2IoVx_YDQ"
     ],
     "iss": "https://issuer.example.com",
     "iat": 1683000000,
     "exp": 1883000000,
     "vct": "https://bmi.bund.example/credential/pid/1.0",
     "age_equal_or_over": {
       "_sd": [
         "Fc8I_07LOcgPwrDJKQyIGO97wVsOplMLjHvRC4R4-Wg",
         "XLtLjadUWc9zN_9hMJRoqy46UsCKb1IshZuuqUFKSCA",
         "aoCCzsC7p4qhZIAh_idRCSCa641uycnc8zPfNWz8nx0",
         "f1-P0A2dKWavv1uFnMX2A7-EXxvhoxv5aHhuEIN-W64",
         "k5hy2r018vrsJjo-Vjd6g6yt7AaonKonniuJ9zel3jo",
         "qp7Z_Ky1Yip0sYgDO3zVug2MFuPNjHxksBDnJZ4aI-c"
       ]
     },
     "_sd_alg": "sha-256",
     "cnf": {
       "jwk": {
         "kty": "EC",
         "crv": "P-256",
         "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
         "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
       }
     }
   }

   The following Disclosures are created by the Issuer:

   *Claim given_name*:

   *  SHA-256 Hash: 0HZmnSIPz337kSWe7C34l--88gzJi-eBJ2Vz_HJwATg
   *  Disclosure:
      WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiRXJp
      a2EiXQ
   *  Contents: ["2GLC42sKQveCfGfryNRN9w", "given_name", "Erika"]




Fett, et al.            Expires 5 September 2024               [Page 63]

Internet-Draft                   SD-JWT                       March 2024


   *Claim family_name*:

   *  SHA-256 Hash: I00fcFUoDXCucp5yy2ujqPssDVGaWNiUliNz_awD0gc
   *  Disclosure:
      WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIk11
      c3Rlcm1hbm4iXQ
   *  Contents: ["eluV5Og3gSNII8EYnsxA_A", "family_name", "Mustermann"]

   *Claim birthdate*:

   *  SHA-256 Hash: Lai6IU6d7GQagXR7AvGTrnXgSld3z8EIg_fv3fOZ1Wg
   *  Disclosure:
      WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImJpcnRoZGF0ZSIsICIxOTYz
      LTA4LTEyIl0
   *  Contents: ["6Ij7tM-a5iVPGboS5tmvVA", "birthdate", "1963-08-12"]

   *Claim source_document_type*:

   *  SHA-256 Hash: qvzNLj2vh9o4SEXOfMiYDuvTykdsWCNg0wTdlr0AEIM
   *  Disclosure:
      WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInNvdXJjZV9kb2N1bWVudF90
      eXBlIiwgImlkX2NhcmQiXQ
   *  Contents: ["eI8ZWm9QnKPpNPeNenHdhQ", "source_document_type",
      "id_card"]

   *Claim street_address*:

   *  SHA-256 Hash: bd1EVzgNopUk4EW3_eQ2n3_NU4iuXOHv9XbGHN3g1TE
   *  Disclosure:
      WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInN0cmVldF9hZGRyZXNzIiwg
      IkhlaWRlc3RyYVx1MDBkZmUgMTciXQ
   *  Contents: ["Qg_O64zqAxe412a108iroA", "street_address",
      "Heidestra\u00dfe 17"]

   *Claim locality*:

   *  SHA-256 Hash: f_FQYgvQWvyVqNnIXsARlNye7YGp8E77gRAjaq-wvnw
   *  Disclosure:
      WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImxvY2FsaXR5IiwgIktcdTAw
      ZjZsbiJd
   *  Contents: ["AJx-095VPrpTtN4QMOqROA", "locality", "K\u00f6ln"]

   *Claim postal_code*:

   *  SHA-256 Hash: XFc7zXPm7zzVdMywm2EuBflka5HHqvf8Up_szNGqvig
   *  Disclosure:
      WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgInBvc3RhbF9jb2RlIiwgIjUx
      MTQ3Il0



Fett, et al.            Expires 5 September 2024               [Page 64]

Internet-Draft                   SD-JWT                       March 2024


   *  Contents: ["Pc33JM2LchcU_lHggv_ufQ", "postal_code", "51147"]

   *Claim country*:

   *  SHA-256 Hash: v4kkb_pP1jlvUbSjtyc5bqcWyA-i8XLvhVYY7ZT0tb0
   *  Disclosure:
      WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImNvdW50cnkiLCAiREUiXQ
   *  Contents: ["G02NSrQfjFXQ7Io09syajA", "country", "DE"]

   *Claim address*:

   *  SHA-256 Hash: zOeBXhxvIS4ZzmQcLlxKuEAOGGByjOqa1z2IoVx_YDQ
   *  Disclosure:
      WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImFkZHJlc3MiLCB7Il9zZCI6
      IFsiWEZjN3pYUG03enpWZE15d20yRXVCZmxrYTVISHF2ZjhVcF9zek5HcXZp
      ZyIsICJiZDFFVnpnTm9wVWs0RVczX2VRMm4zX05VNGl1WE9IdjlYYkdITjNn
      MVRFIiwgImZfRlFZZ3ZRV3Z5VnFObklYc0FSbE55ZTdZR3A4RTc3Z1JBamFx
      LXd2bnciLCAidjRra2JfcFAxamx2VWJTanR5YzVicWNXeUEtaThYTHZoVllZ
      N1pUMHRiMCJdfV0
   *  Contents: ["lklxF5jMYlGTPUovMNIvCA", "address", {"_sd":
      ["XFc7zXPm7zzVdMywm2EuBflka5HHqvf8Up_szNGqvig",
      "bd1EVzgNopUk4EW3_eQ2n3_NU4iuXOHv9XbGHN3g1TE",
      "f_FQYgvQWvyVqNnIXsARlNye7YGp8E77gRAjaq-wvnw",
      "v4kkb_pP1jlvUbSjtyc5bqcWyA-i8XLvhVYY7ZT0tb0"]}]

   *Claim nationalities*:

   *  SHA-256 Hash: hvDXhwmGcJQsBCA2OtjuLAcwAMpDsaU0nkovcKOqWNE
   *  Disclosure:
      WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIm5hdGlvbmFsaXRpZXMiLCBb
      IkRFIl1d
   *  Contents: ["nPuoQnkRFq3BIeAm7AnXFA", "nationalities", ["DE"]]

   *Claim gender*:

   *  SHA-256 Hash: IEBYSJGNhXIlrQo58ykXm2Zx3yll9ZlTtToPo17QQiY
   *  Disclosure:
      WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImdlbmRlciIsICJmZW1hbGUi
      XQ
   *  Contents: ["5bPs1IquZNa0hkaFzzzZNw", "gender", "female"]

   *Claim birth_family_name*:

   *  SHA-256 Hash: ikuur8Q4k8q3VcyA7dC-mNjZBkReDTU-CG4niTE7OTU
   *  Disclosure:
      WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgImJpcnRoX2ZhbWlseV9uYW1l
      IiwgIkdhYmxlciJd




Fett, et al.            Expires 5 September 2024               [Page 65]

Internet-Draft                   SD-JWT                       March 2024


   *  Contents: ["5a2W0_NrlEZzfqmk_7Pq-w", "birth_family_name",
      "Gabler"]

   *Claim locality*:

   *  SHA-256 Hash: WphHoIDyoWbApDC4zbuwR40xl0xLhDC_cv4tsS71rEA
   *  Disclosure:
      WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImxvY2FsaXR5IiwgIkJlcmxp
      biJd
   *  Contents: ["y1sVU5wdfJahVdgwPgS7RQ", "locality", "Berlin"]

   *Claim place_of_birth*:

   *  SHA-256 Hash: wzW15bhCkvksxVvuJ8RF3xi8i64ln1jo_76BC2oa1ug
   *  Disclosure:
      WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgInBsYWNlX29mX2JpcnRoIiwg
      eyJfc2QiOiBbIldwaEhvSUR5b1diQXBEQzR6YnV3UjQweGwweExoRENfY3Y0
      dHNTNzFyRUEiXSwgImNvdW50cnkiOiAiREUifV0
   *  Contents: ["HbQ4X8srVW3QDxnIJdqyOA", "place_of_birth", {"_sd":
      ["WphHoIDyoWbApDC4zbuwR40xl0xLhDC_cv4tsS71rEA"], "country":
      "DE"}]

   *Claim also_known_as*:

   *  SHA-256 Hash: 9ZbplC7TdEW7qal6BBZlMtqJdmeEOiXevdJloXVJdRQ
   *  Disclosure:
      WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgImFsc29fa25vd25fYXMiLCAi
      U2Nod2VzdGVyIEFnbmVzIl0
   *  Contents: ["C9GSoujviJquEgYfojCb1A", "also_known_as", "Schwester
      Agnes"]

   *Claim 12*:

   *  SHA-256 Hash: Fc8I_07LOcgPwrDJKQyIGO97wVsOplMLjHvRC4R4-Wg
   *  Disclosure:
      WyJreDVrRjE3Vi14MEptd1V4OXZndnR3IiwgIjEyIiwgdHJ1ZV0
   *  Contents: ["kx5kF17V-x0JmwUx9vgvtw", "12", true]

   *Claim 14*:

   *  SHA-256 Hash: f1-P0A2dKWavv1uFnMX2A7-EXxvhoxv5aHhuEIN-W64
   *  Disclosure:
      WyJIM28xdXN3UDc2MEZpMnllR2RWQ0VRIiwgIjE0IiwgdHJ1ZV0
   *  Contents: ["H3o1uswP760Fi2yeGdVCEQ", "14", true]

   *Claim 16*:

   *  SHA-256 Hash: k5hy2r018vrsJjo-Vjd6g6yt7AaonKonniuJ9zel3jo



Fett, et al.            Expires 5 September 2024               [Page 66]

Internet-Draft                   SD-JWT                       March 2024


   *  Disclosure:
      WyJPQktsVFZsdkxnLUFkd3FZR2JQOFpBIiwgIjE2IiwgdHJ1ZV0
   *  Contents: ["OBKlTVlvLg-AdwqYGbP8ZA", "16", true]

   *Claim 18*:

   *  SHA-256 Hash: qp7Z_Ky1Yip0sYgDO3zVug2MFuPNjHxksBDnJZ4aI-c
   *  Disclosure:
      WyJNMEpiNTd0NDF1YnJrU3V5ckRUM3hBIiwgIjE4IiwgdHJ1ZV0
   *  Contents: ["M0Jb57t41ubrkSuyrDT3xA", "18", true]

   *Claim 21*:

   *  SHA-256 Hash: aoCCzsC7p4qhZIAh_idRCSCa641uycnc8zPfNWz8nx0
   *  Disclosure:
      WyJEc210S05ncFY0ZEFIcGpyY2Fvc0F3IiwgIjIxIiwgdHJ1ZV0
   *  Contents: ["DsmtKNgpV4dAHpjrcaosAw", "21", true]

   *Claim 65*:

   *  SHA-256 Hash: XLtLjadUWc9zN_9hMJRoqy46UsCKb1IshZuuqUFKSCA
   *  Disclosure:
      WyJlSzVvNXBIZmd1cFBwbHRqMXFoQUp3IiwgIjY1IiwgZmFsc2Vd
   *  Contents: ["eK5o5pHfgupPpltj1qhAJw", "65", false]

   The following is how a presentation of the SD-JWT with a Key Binding
   JWT that discloses only nationality and the fact that the person is
   over 18 years old could look like:























Fett, et al.            Expires 5 September 2024               [Page 67]

Internet-Draft                   SD-JWT                       March 2024


   eyJhbGciOiAiRVMyNTYiLCAidHlwIjogInZjK3NkLWp3dCJ9.eyJfc2QiOiBbIjBIWm1
   uU0lQejMzN2tTV2U3QzM0bC0tODhnekppLWVCSjJWel9ISndBVGciLCAiOVpicGxDN1R
   kRVc3cWFsNkJCWmxNdHFKZG1lRU9pWGV2ZEpsb1hWSmRSUSIsICJJMDBmY0ZVb0RYQ3V
   jcDV5eTJ1anFQc3NEVkdhV05pVWxpTnpfYXdEMGdjIiwgIklFQllTSkdOaFhJbHJRbzU
   4eWtYbTJaeDN5bGw5WmxUdFRvUG8xN1FRaVkiLCAiTGFpNklVNmQ3R1FhZ1hSN0F2R1R
   yblhnU2xkM3o4RUlnX2Z2M2ZPWjFXZyIsICJodkRYaHdtR2NKUXNCQ0EyT3RqdUxBY3d
   BTXBEc2FVMG5rb3ZjS09xV05FIiwgImlrdXVyOFE0azhxM1ZjeUE3ZEMtbU5qWkJrUmV
   EVFUtQ0c0bmlURTdPVFUiLCAicXZ6TkxqMnZoOW80U0VYT2ZNaVlEdXZUeWtkc1dDTmc
   wd1RkbHIwQUVJTSIsICJ3elcxNWJoQ2t2a3N4VnZ1SjhSRjN4aThpNjRsbjFqb183NkJ
   DMm9hMXVnIiwgInpPZUJYaHh2SVM0WnptUWNMbHhLdUVBT0dHQnlqT3FhMXoySW9WeF9
   ZRFEiXSwgImlzcyI6ICJodHRwczovL2lzc3Vlci5leGFtcGxlLmNvbSIsICJpYXQiOiA
   xNjgzMDAwMDAwLCAiZXhwIjogMTg4MzAwMDAwMCwgInZjdCI6ICJodHRwczovL2JtaS5
   idW5kLmV4YW1wbGUvY3JlZGVudGlhbC9waWQvMS4wIiwgImFnZV9lcXVhbF9vcl9vdmV
   yIjogeyJfc2QiOiBbIkZjOElfMDdMT2NnUHdyREpLUXlJR085N3dWc09wbE1Makh2UkM
   0UjQtV2ciLCAiWEx0TGphZFVXYzl6Tl85aE1KUm9xeTQ2VXNDS2IxSXNoWnV1cVVGS1N
   DQSIsICJhb0NDenNDN3A0cWhaSUFoX2lkUkNTQ2E2NDF1eWNuYzh6UGZOV3o4bngwIiw
   gImYxLVAwQTJkS1dhdnYxdUZuTVgyQTctRVh4dmhveHY1YUhodUVJTi1XNjQiLCAiazV
   oeTJyMDE4dnJzSmpvLVZqZDZnNnl0N0Fhb25Lb25uaXVKOXplbDNqbyIsICJxcDdaX0t
   5MVlpcDBzWWdETzN6VnVnMk1GdVBOakh4a3NCRG5KWjRhSS1jIl19LCAiX3NkX2FsZyI
   6ICJzaGEtMjU2IiwgImNuZiI6IHsiandrIjogeyJrdHkiOiAiRUMiLCAiY3J2IjogIlA
   tMjU2IiwgIngiOiAiVENBRVIxOVp2dTNPSEY0ajRXNHZmU1ZvSElQMUlMaWxEbHM3dkN
   lR2VtYyIsICJ5IjogIlp4amlXV2JaTVFHSFZXS1ZRNGhiU0lpcnNWZnVlY0NFNnQ0alQ
   5RjJIWlEifX19.jeF9GjGbjCr0NND0SbkV4HeSpsysixALFScJl4bYkIykXhF6cRtqni
   64_d7X6Ef8Rx80rfsgXe0H7TdiSoIJOw~WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiw
   gIm5hdGlvbmFsaXRpZXMiLCBbIkRFIl1d~WyJNMEpiNTd0NDF1YnJrU3V5ckRUM3hBIi
   wgIjE4IiwgdHJ1ZV0~eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dCJ9.eyJub
   25jZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaWVyLmV4YW1wb
   GUub3JnIiwgImlhdCI6IDE3MDk1NzI1NzgsICJzZF9oYXNoIjogIkpCc2FIZzZjbjdLR
   W5vSjJjVGZvenFpZG1VWE9EMWlpVHpfRGdUWklNNGMifQ.404FK0WQAawQHq446EtkFJ
   cKJydFs2S4L9f8RR5Fuf8_O7N0RG2FvgLB71gJhHdey_F6Kgqd55xSDpIyzZw4lQ

   The following is the payload of a corresponding Key Binding JWT:

   {
     "nonce": "1234567890",
     "aud": "https://verifier.example.org",
     "iat": 1709572578,
     "sd_hash": "JBsaHg6cn7KEnoJ2cTfozqidmUXOD1iiTz_DgTZIM4c"
   }

   After the validation, the Verifier will have the following data for
   further processing:









Fett, et al.            Expires 5 September 2024               [Page 68]

Internet-Draft                   SD-JWT                       March 2024


   {
     "iss": "https://issuer.example.com",
     "iat": 1683000000,
     "exp": 1883000000,
     "vct": "https://bmi.bund.example/credential/pid/1.0",
     "age_equal_or_over": {
       "18": true
     },
     "cnf": {
       "jwk": {
         "kty": "EC",
         "crv": "P-256",
         "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
         "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
       }
     },
     "nationalities": [
       "DE"
     ]
   }

A.4.  Example 4b - W3C Verifiable Credentials Data Model v2.0

   This non-normative example illustrates how the artifacts defined in
   this specification could be used to express a W3C Verifiable
   Credentials Data Model v2.0 [VC_DATA_v2.0] payload.

   Key Binding is applied using the Holder's public key passed in a cnf
   claim in the SD-JWT.

   The Issuer is using the following input claim set:




















Fett, et al.            Expires 5 September 2024               [Page 69]

Internet-Draft                   SD-JWT                       March 2024


   {
     "@context": [
       "https://www.w3.org/2018/credentials/v1",
       "https://w3id.org/vaccination/v1"
     ],
     "type": [
       "VerifiableCredential",
       "VaccinationCertificate"
     ],
     "issuer": "https://example.com/issuer",
     "issuanceDate": "2023-02-09T11:01:59Z",
     "expirationDate": "2028-02-08T11:01:59Z",
     "name": "COVID-19 Vaccination Certificate",
     "description": "COVID-19 Vaccination Certificate",
     "credentialSubject": {
       "vaccine": {
         "type": "Vaccine",
         "atcCode": "J07BX03",
         "medicinalProductName": "COVID-19 Vaccine Moderna",
         "marketingAuthorizationHolder": "Moderna Biotech"
       },
       "nextVaccinationDate": "2021-08-16T13:40:12Z",
       "countryOfVaccination": "GE",
       "dateOfVaccination": "2021-06-23T13:40:12Z",
       "order": "3/3",
       "recipient": {
         "type": "VaccineRecipient",
         "gender": "Female",
         "birthDate": "1961-08-17",
         "givenName": "Marion",
         "familyName": "Mustermann"
       },
       "type": "VaccinationEvent",
       "administeringCentre": "Praxis Sommergarten",
       "batchNumber": "1626382736",
       "healthProfessional": "883110000015376"
     }
   }

   The following is the issued SD-JWT:











Fett, et al.            Expires 5 September 2024               [Page 70]

Internet-Draft                   SD-JWT                       March 2024


   eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJAY29udGV4
   dCI6IFsiaHR0cHM6Ly93d3cudzMub3JnLzIwMTgvY3JlZGVudGlhbHMvdjEiLCAiaHR0
   cHM6Ly93M2lkLm9yZy92YWNjaW5hdGlvbi92MSJdLCAidHlwZSI6IFsiVmVyaWZpYWJs
   ZUNyZWRlbnRpYWwiLCAiVmFjY2luYXRpb25DZXJ0aWZpY2F0ZSJdLCAiaXNzdWVyIjog
   Imh0dHBzOi8vZXhhbXBsZS5jb20vaXNzdWVyIiwgImlzc3VhbmNlRGF0ZSI6ICIyMDIz
   LTAyLTA5VDExOjAxOjU5WiIsICJleHBpcmF0aW9uRGF0ZSI6ICIyMDI4LTAyLTA4VDEx
   OjAxOjU5WiIsICJuYW1lIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRl
   IiwgImRlc2NyaXB0aW9uIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRl
   IiwgImNyZWRlbnRpYWxTdWJqZWN0IjogeyJfc2QiOiBbIjFWX0stOGxEUThpRlhCRlhi
   Wlk5ZWhxUjRIYWJXQ2k1VDB5Ykl6WlBld3ciLCAiSnpqTGd0UDI5ZFAtQjN0ZDEyUDY3
   NGdGbUsyenk4MUhNdEJnZjZDSk5XZyIsICJSMmZHYmZBMDdaX1lsa3FtTlp5bWExeHl5
   eDFYc3RJaVM2QjFZYmwySlo0IiwgIlRDbXpybDdLMmdldl9kdTdwY01JeXpSTEhwLVll
   Zy1GbF9jeHRyVXZQeGciLCAiVjdrSkJMSzc4VG1WRE9tcmZKN1p1VVBIdUtfMmNjN3la
   UmE0cVYxdHh3TSIsICJiMGVVc3ZHUC1PRERkRm9ZNE5semxYYzN0RHNsV0p0Q0pGNzVO
   dzhPal9nIiwgInpKS19lU01YandNOGRYbU1aTG5JOEZHTTA4ekozX3ViR2VFTUotNVRC
   eTAiXSwgInZhY2NpbmUiOiB7Il9zZCI6IFsiMWNGNWhMd2toTU5JYXFmV0pyWEk3Tk1X
   ZWRMLTlmNlkyUEE1MnlQalNaSSIsICJIaXk2V1d1ZUxENWJuMTYyOTh0UHY3R1hobWxk
   TURPVG5CaS1DWmJwaE5vIiwgIkxiMDI3cTY5MWpYWGwtakM3M3ZpOGViT2o5c214M0Mt
   X29nN2dBNFRCUUUiXSwgInR5cGUiOiAiVmFjY2luZSJ9LCAicmVjaXBpZW50IjogeyJf
   c2QiOiBbIjFsU1FCTlkyNHEwVGg2T0d6dGhxLTctNGw2Y0FheHJZWE9HWnBlV19sbkEi
   LCAiM256THE4MU0yb04wNndkdjFzaEh2T0VKVnhaNUtMbWREa0hFREpBQldFSSIsICJQ
   bjFzV2kwNkc0TEpybm4tX1JUMFJiTV9IVGR4blBKUXVYMmZ6V3ZfSk9VIiwgImxGOXV6
   ZHN3N0hwbEdMYzcxNFRyNFdPN01HSnphN3R0N1FGbGVDWDRJdHciXSwgInR5cGUiOiAi
   VmFjY2luZVJlY2lwaWVudCJ9LCAidHlwZSI6ICJWYWNjaW5hdGlvbkV2ZW50In0sICJf
   c2RfYWxnIjogInNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJj
   cnYiOiAiUC0yNTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxp
   bERsczd2Q2VHZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVj
   Q0U2dDRqVDlGMkhaUSJ9fX0.cxCH425HJYyAKyExUyF1UJZoFTICsUKAaVUKXf67zx2h
   csu40flxynZPZ3ImXEa71G2-U9qihHiYjDHQjE8mLw~WyIyR0xDNDJzS1F2ZUNmR2Zye
   U5STjl3IiwgImF0Y0NvZGUiLCAiSjA3QlgwMyJd~WyJlbHVWNU9nM2dTTklJOEVZbnN4
   QV9BIiwgIm1lZGljaW5hbFByb2R1Y3ROYW1lIiwgIkNPVklELTE5IFZhY2NpbmUgTW9k
   ZXJuYSJd~WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgIm1hcmtldGluZ0F1dGhvcml
   6YXRpb25Ib2xkZXIiLCAiTW9kZXJuYSBCaW90ZWNoIl0~WyJlSThaV205UW5LUHBOUGV
   OZW5IZGhRIiwgIm5leHRWYWNjaW5hdGlvbkRhdGUiLCAiMjAyMS0wOC0xNlQxMzo0MDo
   xMloiXQ~WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImNvdW50cnlPZlZhY2NpbmF0
   aW9uIiwgIkdFIl0~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRhdGVPZlZhY2Np
   bmF0aW9uIiwgIjIwMjEtMDYtMjNUMTM6NDA6MTJaIl0~WyJQYzMzSk0yTGNoY1VfbEhn
   Z3ZfdWZRIiwgIm9yZGVyIiwgIjMvMyJd~WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiw
   gImdlbmRlciIsICJGZW1hbGUiXQ~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImJp
   cnRoRGF0ZSIsICIxOTYxLTA4LTE3Il0~WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwg
   ImdpdmVuTmFtZSIsICJNYXJpb24iXQ~WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgI
   mZhbWlseU5hbWUiLCAiTXVzdGVybWFubiJd~WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13
   IiwgImFkbWluaXN0ZXJpbmdDZW50cmUiLCAiUHJheGlzIFNvbW1lcmdhcnRlbiJd~WyJ
   5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImJhdGNoTnVtYmVyIiwgIjE2MjYzODI3MzY
   iXQ~WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImhlYWx0aFByb2Zlc3Npb25hbCIs
   ICI4ODMxMTAwMDAwMTUzNzYiXQ~

   The following payload is used for the SD-JWT:



Fett, et al.            Expires 5 September 2024               [Page 71]

Internet-Draft                   SD-JWT                       March 2024


   {
     "@context": [
       "https://www.w3.org/2018/credentials/v1",
       "https://w3id.org/vaccination/v1"
     ],
     "type": [
       "VerifiableCredential",
       "VaccinationCertificate"
     ],
     "issuer": "https://example.com/issuer",
     "issuanceDate": "2023-02-09T11:01:59Z",
     "expirationDate": "2028-02-08T11:01:59Z",
     "name": "COVID-19 Vaccination Certificate",
     "description": "COVID-19 Vaccination Certificate",
     "credentialSubject": {
       "_sd": [
         "1V_K-8lDQ8iFXBFXbZY9ehqR4HabWCi5T0ybIzZPeww",
         "JzjLgtP29dP-B3td12P674gFmK2zy81HMtBgf6CJNWg",
         "R2fGbfA07Z_YlkqmNZyma1xyyx1XstIiS6B1Ybl2JZ4",
         "TCmzrl7K2gev_du7pcMIyzRLHp-Yeg-Fl_cxtrUvPxg",
         "V7kJBLK78TmVDOmrfJ7ZuUPHuK_2cc7yZRa4qV1txwM",
         "b0eUsvGP-ODDdFoY4NlzlXc3tDslWJtCJF75Nw8Oj_g",
         "zJK_eSMXjwM8dXmMZLnI8FGM08zJ3_ubGeEMJ-5TBy0"
       ],
       "vaccine": {
         "_sd": [
           "1cF5hLwkhMNIaqfWJrXI7NMWedL-9f6Y2PA52yPjSZI",
           "Hiy6WWueLD5bn16298tPv7GXhmldMDOTnBi-CZbphNo",
           "Lb027q691jXXl-jC73vi8ebOj9smx3C-_og7gA4TBQE"
         ],
         "type": "Vaccine"
       },
       "recipient": {
         "_sd": [
           "1lSQBNY24q0Th6OGzthq-7-4l6cAaxrYXOGZpeW_lnA",
           "3nzLq81M2oN06wdv1shHvOEJVxZ5KLmdDkHEDJABWEI",
           "Pn1sWi06G4LJrnn-_RT0RbM_HTdxnPJQuX2fzWv_JOU",
           "lF9uzdsw7HplGLc714Tr4WO7MGJza7tt7QFleCX4Itw"
         ],
         "type": "VaccineRecipient"
       },
       "type": "VaccinationEvent"
     },
     "_sd_alg": "sha-256",
     "cnf": {
       "jwk": {
         "kty": "EC",
         "crv": "P-256",



Fett, et al.            Expires 5 September 2024               [Page 72]

Internet-Draft                   SD-JWT                       March 2024


         "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
         "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
       }
     }
   }

   The following Disclosures are created by the Issuer:

   *Claim atcCode*:

   *  SHA-256 Hash: 1cF5hLwkhMNIaqfWJrXI7NMWedL-9f6Y2PA52yPjSZI
   *  Disclosure:
      WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImF0Y0NvZGUiLCAiSjA3Qlgw
      MyJd
   *  Contents: ["2GLC42sKQveCfGfryNRN9w", "atcCode", "J07BX03"]

   *Claim medicinalProductName*:

   *  SHA-256 Hash: Hiy6WWueLD5bn16298tPv7GXhmldMDOTnBi-CZbphNo
   *  Disclosure:
      WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgIm1lZGljaW5hbFByb2R1Y3RO
      YW1lIiwgIkNPVklELTE5IFZhY2NpbmUgTW9kZXJuYSJd
   *  Contents: ["eluV5Og3gSNII8EYnsxA_A", "medicinalProductName",
      "COVID-19
      Vaccine Moderna"]

   *Claim marketingAuthorizationHolder*:

   *  SHA-256 Hash: Lb027q691jXXl-jC73vi8ebOj9smx3C-_og7gA4TBQE
   *  Disclosure:
      WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgIm1hcmtldGluZ0F1dGhvcml6
      YXRpb25Ib2xkZXIiLCAiTW9kZXJuYSBCaW90ZWNoIl0
   *  Contents: ["6Ij7tM-a5iVPGboS5tmvVA",
      "marketingAuthorizationHolder",
      "Moderna Biotech"]

   *Claim nextVaccinationDate*:

   *  SHA-256 Hash: R2fGbfA07Z_YlkqmNZyma1xyyx1XstIiS6B1Ybl2JZ4
   *  Disclosure:
      WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm5leHRWYWNjaW5hdGlvbkRh
      dGUiLCAiMjAyMS0wOC0xNlQxMzo0MDoxMloiXQ
   *  Contents: ["eI8ZWm9QnKPpNPeNenHdhQ", "nextVaccinationDate",
      "2021-08-16T13:40:12Z"]

   *Claim countryOfVaccination*:

   *  SHA-256 Hash: JzjLgtP29dP-B3td12P674gFmK2zy81HMtBgf6CJNWg



Fett, et al.            Expires 5 September 2024               [Page 73]

Internet-Draft                   SD-JWT                       March 2024


   *  Disclosure:
      WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImNvdW50cnlPZlZhY2NpbmF0
      aW9uIiwgIkdFIl0
   *  Contents: ["Qg_O64zqAxe412a108iroA", "countryOfVaccination", "GE"]

   *Claim dateOfVaccination*:

   *  SHA-256 Hash: zJK_eSMXjwM8dXmMZLnI8FGM08zJ3_ubGeEMJ-5TBy0
   *  Disclosure:
      WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRhdGVPZlZhY2NpbmF0aW9u
      IiwgIjIwMjEtMDYtMjNUMTM6NDA6MTJaIl0
   *  Contents: ["AJx-095VPrpTtN4QMOqROA", "dateOfVaccination",
      "2021-06-23T13:40:12Z"]

   *Claim order*:

   *  SHA-256 Hash: b0eUsvGP-ODDdFoY4NlzlXc3tDslWJtCJF75Nw8Oj_g
   *  Disclosure:
      WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgIm9yZGVyIiwgIjMvMyJd
   *  Contents: ["Pc33JM2LchcU_lHggv_ufQ", "order", "3/3"]

   *Claim gender*:

   *  SHA-256 Hash: 3nzLq81M2oN06wdv1shHvOEJVxZ5KLmdDkHEDJABWEI
   *  Disclosure:
      WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdlbmRlciIsICJGZW1hbGUi
      XQ
   *  Contents: ["G02NSrQfjFXQ7Io09syajA", "gender", "Female"]

   *Claim birthDate*:

   *  SHA-256 Hash: Pn1sWi06G4LJrnn-_RT0RbM_HTdxnPJQuX2fzWv_JOU
   *  Disclosure:
      WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImJpcnRoRGF0ZSIsICIxOTYx
      LTA4LTE3Il0
   *  Contents: ["lklxF5jMYlGTPUovMNIvCA", "birthDate", "1961-08-17"]

   *Claim givenName*:

   *  SHA-256 Hash: lF9uzdsw7HplGLc714Tr4WO7MGJza7tt7QFleCX4Itw
   *  Disclosure:
      WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgImdpdmVuTmFtZSIsICJNYXJp
      b24iXQ
   *  Contents: ["nPuoQnkRFq3BIeAm7AnXFA", "givenName", "Marion"]

   *Claim familyName*:

   *  SHA-256 Hash: 1lSQBNY24q0Th6OGzthq-7-4l6cAaxrYXOGZpeW_lnA



Fett, et al.            Expires 5 September 2024               [Page 74]

Internet-Draft                   SD-JWT                       March 2024


   *  Disclosure:
      WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImZhbWlseU5hbWUiLCAiTXVz
      dGVybWFubiJd
   *  Contents: ["5bPs1IquZNa0hkaFzzzZNw", "familyName", "Mustermann"]

   *Claim administeringCentre*:

   *  SHA-256 Hash: TCmzrl7K2gev_du7pcMIyzRLHp-Yeg-Fl_cxtrUvPxg
   *  Disclosure:
      WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgImFkbWluaXN0ZXJpbmdDZW50
      cmUiLCAiUHJheGlzIFNvbW1lcmdhcnRlbiJd
   *  Contents: ["5a2W0_NrlEZzfqmk_7Pq-w", "administeringCentre",
      "Praxis
      Sommergarten"]

   *Claim batchNumber*:

   *  SHA-256 Hash: V7kJBLK78TmVDOmrfJ7ZuUPHuK_2cc7yZRa4qV1txwM
   *  Disclosure:
      WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImJhdGNoTnVtYmVyIiwgIjE2
      MjYzODI3MzYiXQ
   *  Contents: ["y1sVU5wdfJahVdgwPgS7RQ", "batchNumber", "1626382736"]

   *Claim healthProfessional*:

   *  SHA-256 Hash: 1V_K-8lDQ8iFXBFXbZY9ehqR4HabWCi5T0ybIzZPeww
   *  Disclosure:
      WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImhlYWx0aFByb2Zlc3Npb25h
      bCIsICI4ODMxMTAwMDAwMTUzNzYiXQ
   *  Contents: ["HbQ4X8srVW3QDxnIJdqyOA", "healthProfessional",
      "883110000015376"]

   The following is how a presentation of the SD-JWT with Key Binding
   JWT that discloses only type, medicinalProductName, atcCode of the
   vaccine, type of the recipient, type, order and dateOfVaccination
   could look like:















Fett, et al.            Expires 5 September 2024               [Page 75]

Internet-Draft                   SD-JWT                       March 2024


   eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJAY29udGV4
   dCI6IFsiaHR0cHM6Ly93d3cudzMub3JnLzIwMTgvY3JlZGVudGlhbHMvdjEiLCAiaHR0
   cHM6Ly93M2lkLm9yZy92YWNjaW5hdGlvbi92MSJdLCAidHlwZSI6IFsiVmVyaWZpYWJs
   ZUNyZWRlbnRpYWwiLCAiVmFjY2luYXRpb25DZXJ0aWZpY2F0ZSJdLCAiaXNzdWVyIjog
   Imh0dHBzOi8vZXhhbXBsZS5jb20vaXNzdWVyIiwgImlzc3VhbmNlRGF0ZSI6ICIyMDIz
   LTAyLTA5VDExOjAxOjU5WiIsICJleHBpcmF0aW9uRGF0ZSI6ICIyMDI4LTAyLTA4VDEx
   OjAxOjU5WiIsICJuYW1lIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRl
   IiwgImRlc2NyaXB0aW9uIjogIkNPVklELTE5IFZhY2NpbmF0aW9uIENlcnRpZmljYXRl
   IiwgImNyZWRlbnRpYWxTdWJqZWN0IjogeyJfc2QiOiBbIjFWX0stOGxEUThpRlhCRlhi
   Wlk5ZWhxUjRIYWJXQ2k1VDB5Ykl6WlBld3ciLCAiSnpqTGd0UDI5ZFAtQjN0ZDEyUDY3
   NGdGbUsyenk4MUhNdEJnZjZDSk5XZyIsICJSMmZHYmZBMDdaX1lsa3FtTlp5bWExeHl5
   eDFYc3RJaVM2QjFZYmwySlo0IiwgIlRDbXpybDdLMmdldl9kdTdwY01JeXpSTEhwLVll
   Zy1GbF9jeHRyVXZQeGciLCAiVjdrSkJMSzc4VG1WRE9tcmZKN1p1VVBIdUtfMmNjN3la
   UmE0cVYxdHh3TSIsICJiMGVVc3ZHUC1PRERkRm9ZNE5semxYYzN0RHNsV0p0Q0pGNzVO
   dzhPal9nIiwgInpKS19lU01YandNOGRYbU1aTG5JOEZHTTA4ekozX3ViR2VFTUotNVRC
   eTAiXSwgInZhY2NpbmUiOiB7Il9zZCI6IFsiMWNGNWhMd2toTU5JYXFmV0pyWEk3Tk1X
   ZWRMLTlmNlkyUEE1MnlQalNaSSIsICJIaXk2V1d1ZUxENWJuMTYyOTh0UHY3R1hobWxk
   TURPVG5CaS1DWmJwaE5vIiwgIkxiMDI3cTY5MWpYWGwtakM3M3ZpOGViT2o5c214M0Mt
   X29nN2dBNFRCUUUiXSwgInR5cGUiOiAiVmFjY2luZSJ9LCAicmVjaXBpZW50IjogeyJf
   c2QiOiBbIjFsU1FCTlkyNHEwVGg2T0d6dGhxLTctNGw2Y0FheHJZWE9HWnBlV19sbkEi
   LCAiM256THE4MU0yb04wNndkdjFzaEh2T0VKVnhaNUtMbWREa0hFREpBQldFSSIsICJQ
   bjFzV2kwNkc0TEpybm4tX1JUMFJiTV9IVGR4blBKUXVYMmZ6V3ZfSk9VIiwgImxGOXV6
   ZHN3N0hwbEdMYzcxNFRyNFdPN01HSnphN3R0N1FGbGVDWDRJdHciXSwgInR5cGUiOiAi
   VmFjY2luZVJlY2lwaWVudCJ9LCAidHlwZSI6ICJWYWNjaW5hdGlvbkV2ZW50In0sICJf
   c2RfYWxnIjogInNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJj
   cnYiOiAiUC0yNTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxp
   bERsczd2Q2VHZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVj
   Q0U2dDRqVDlGMkhaUSJ9fX0.cxCH425HJYyAKyExUyF1UJZoFTICsUKAaVUKXf67zx2h
   csu40flxynZPZ3ImXEa71G2-U9qihHiYjDHQjE8mLw~WyJQYzMzSk0yTGNoY1VfbEhnZ
   3ZfdWZRIiwgIm9yZGVyIiwgIjMvMyJd~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwg
   ImRhdGVPZlZhY2NpbmF0aW9uIiwgIjIwMjEtMDYtMjNUMTM6NDA6MTJaIl0~WyIyR0xD
   NDJzS1F2ZUNmR2ZyeU5STjl3IiwgImF0Y0NvZGUiLCAiSjA3QlgwMyJd~WyJlbHVWNU9
   nM2dTTklJOEVZbnN4QV9BIiwgIm1lZGljaW5hbFByb2R1Y3ROYW1lIiwgIkNPVklELTE
   5IFZhY2NpbmUgTW9kZXJuYSJd~eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dC
   J9.eyJub25jZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaWVyL
   mV4YW1wbGUub3JnIiwgImlhdCI6IDE3MDk1NzI1NzgsICJzZF9oYXNoIjogIklzd3dPe
   kh6OVF5RFdxQXVzeUZHcDZ2RGt3YlN3X25tQk9FSmlIRkFaSlUifQ.7YtKL_1dLXm2VO
   bTJc98m6dgdUvXwTcfyYZ007KOaidfgVuKpQ87ROPjGtpH4mNAQKzfdoDYm5pAAMOUJ-
   xtHg

   After the validation, the Verifier will have the following data for
   further processing:









Fett, et al.            Expires 5 September 2024               [Page 76]

Internet-Draft                   SD-JWT                       March 2024


   {
     "@context": [
       "https://www.w3.org/2018/credentials/v1",
       "https://w3id.org/vaccination/v1"
     ],
     "type": [
       "VerifiableCredential",
       "VaccinationCertificate"
     ],
     "issuer": "https://example.com/issuer",
     "issuanceDate": "2023-02-09T11:01:59Z",
     "expirationDate": "2028-02-08T11:01:59Z",
     "name": "COVID-19 Vaccination Certificate",
     "description": "COVID-19 Vaccination Certificate",
     "credentialSubject": {
       "vaccine": {
         "type": "Vaccine",
         "atcCode": "J07BX03",
         "medicinalProductName": "COVID-19 Vaccine Moderna"
       },
       "recipient": {
         "type": "VaccineRecipient"
       },
       "type": "VaccinationEvent",
       "order": "3/3",
       "dateOfVaccination": "2021-06-23T13:40:12Z"
     },
     "cnf": {
       "jwk": {
         "kty": "EC",
         "crv": "P-256",
         "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
         "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
       }
     }
   }

A.5.  Elliptic Curve Key Used in the Examples

   The following Elliptic Curve public key, represented in JWK format,
   can be used to validate the Issuer signatures in the above examples:

   {
     "kty": "EC",
     "crv": "P-256",
     "x": "b28d4MwZMjw8-00CG4xfnn9SLMVMM19SlqZpVb_uNtQ",
     "y": "Xv5zWwuoaTgdS6hV43yI6gBwTnjukmFQQnJ_kCxzqk8"
   }



Fett, et al.            Expires 5 September 2024               [Page 77]

Internet-Draft                   SD-JWT                       March 2024


   The public key used to validate a Key Binding JWT can be found in the
   examples as the content of the cnf claim.

Appendix B.  Disclosure Format Considerations

   As described in Section 5.2, the Disclosure structure is JSON
   containing salt and the cleartext content of a claim, which is
   base64url encoded.  The encoded value is the input used to calculate
   a digest for the respective claim.  The inclusion of digest value in
   the signed JWT ensures the integrity of the claim value.  Using
   encoded content as the input to the integrity mechanism is
   conceptually similar to the approach in JWS and particularly useful
   when the content, like JSON, can have differences but be semantically
   equivalent.  Some further discussion of the considerations around
   this design decision follows.

   When receiving an SD-JWT, a Verifier must be able to re-compute
   digests of the disclosed claim values and, given the same input
   values, obtain the same digest values as signed by the Issuer.

   Usually, JSON-based formats transport claim values as simple
   properties of a JSON object such as this:

   ...
     "family_name": "Möbius",
     "address": {
       "street_address": "Schulstr. 12",
       "locality": "Schulpforta"
     }
   ...

   However, a problem arises when computation over the data need to be
   performed and verified, like signing or computing digests.  Common
   signature schemes require the same byte string as input to the
   signature verification as was used for creating the signature.  In
   the digest approach outlined above, the same problem exists: for the
   Issuer and the Verifier to arrive at the same digest, the same byte
   string must be hashed.

   JSON, however, does not prescribe a unique encoding for data, but
   allows for variations in the encoded string.  The data above, for
   example, can be encoded as









Fett, et al.            Expires 5 September 2024               [Page 78]

Internet-Draft                   SD-JWT                       March 2024


   ...
   "family_name": "M\u00f6bius",
   "address": {
     "street_address": "Schulstr. 12",
     "locality": "Schulpforta"
   }
   ...

   or as

  ...
  "family_name": "Möbius",
  "address": {"locality":"Schulpforta", "street_address":"Schulstr. 12"}
  ...

   The two representations of the value in family_name are very
   different on the byte-level, but yield equivalent objects.  Same for
   the representations of address, varying in white space and order of
   elements in the object.

   The variations in white space, ordering of object properties, and
   encoding of Unicode characters are all allowed by the JSON
   specification, including further variations, e.g., concerning
   floating-point numbers, as described in [RFC8785].  Variations can be
   introduced whenever JSON data is serialized or deserialized and
   unless dealt with, will lead to different digests and the inability
   to verify signatures.

   There are generally two approaches to deal with this problem:

   1.  Canonicalization: The data is transferred in JSON format,
       potentially introducing variations in its representation, but is
       transformed into a canonical form before computing a digest.
       Both the Issuer and the Verifier must use the same
       canonicalization algorithm to arrive at the same byte string for
       computing a digest.
   2.  Source string hardening: Instead of transferring data in a format
       that may introduce variations, a representation of the data is
       serialized.  This representation is then used as the hashing
       input at the Verifier, but also transferred to the Verifier and
       used for the same digest calculation there.  This means that the
       Verifier can easily compute and check the digest of the byte
       string before finally deserializing and accessing the data.

   Mixed approaches are conceivable, i.e., transferring both the
   original JSON data plus a string suitable for computing a digest, but
   such approaches can easily lead to undetected inconsistencies
   resulting in time-of-check-time-of-use type security vulnerabilities.



Fett, et al.            Expires 5 September 2024               [Page 79]

Internet-Draft                   SD-JWT                       March 2024


   In this specification, the source string hardening approach is used,
   as it allows for simple and reliable interoperability without the
   requirement for a canonicalization library.  To harden the source
   string, any serialization format that supports the necessary data
   types could be used in theory, like protobuf, msgpack, or pickle.  In
   this specification, JSON is used and plaintext contents of each
   Disclosure are encoded using base64url-encoding for transport.  This
   approach means that SD-JWTs can be implemented purely based on widely
   available JWT, JSON, and Base64 encoding and decoding libraries.

   A Verifier can then easily check the digest over the source string
   before extracting the original JSON data.  Variations in the encoding
   of the source string are implicitly tolerated by the Verifier, as the
   digest is computed over a predefined byte string and not over a JSON
   object.

   It is important to note that the Disclosures are neither intended nor
   suitable for direct consumption by an application that needs to
   access the disclosed claim values after the verification by the
   Verifier.  The Disclosures are only intended to be used by a Verifier
   to check the digests over the source strings and to extract the
   original JSON data.  The original JSON data is then used by the
   application.  See Section 8.3 for details.

Appendix C.  Document History

   [[ To be removed from the final specification ]]

   -08

   *  Make RFCs 0020 and 7515 normative references
   *  Be a bit more prescriptive in suggesting RFC7800 cnf/jwk be used
      to convey the Key Binding key
   *  Editorial changes aimed at improved clarity
   *  Improve unlinkability considerations, mention that different KB
      keys must be used
   *  Remove the explicit prohibition on HMAC
   *  Remove mention of unspecified key binding methods and the
      Enveloping SD-JWTs section
   *  Editorial updates aimed at more consistent treatment of a
      Disclosure vs the contents of a Disclosure
   *  Update PID example
   *  Be more explicit that the VCDM and SD-JWT VC examples are only
      illustrative and do not define anything

   -07

   *  Reference RFC4086 in security considerations about salt entropy



Fett, et al.            Expires 5 September 2024               [Page 80]

Internet-Draft                   SD-JWT                       March 2024


   *  Update change controller for the Structured Syntax Suffix
      registration from IESG to IETF per IANA suggestion
   *  Strengthen security considerations around claims controlling the
      validity of the SD-JWT not being selectively disclosable
   *  Expand/rework considerations on the choice of hash algorithm
   *  Clarify validation around no duplicate digests in the payload
      (directly or recursively) and no unused disclosures at the end of
      processing
   *  Better describe and illustrate the tilde separated format
   *  Change claim name from _sd_hash to sd_hash

   -06

   *  Added hash of Issuer-signed part and Disclosures in KB-JWT
   *  Fix minor issues in some examples
   *  Added IANA media type registration request for the JSON
      Serialization
   *  More precise wording around storing artifacts with sensitive data
   *  The claim name _sd or ... must not be used in a disclosure.
   *  Added JWT claims registration requests to IANA
   *  Ensure claims that control validity are checked after decoding
      payload
   *  Restructure sections around data formats and Example 1
   *  Update JSON Serialization to remove the kb_jwt member and allow
      for the disclosures to be conveyed elsewhere
   *  Expand the Enveloping SD-JWTs section to also discuss enveloping
      JSON serialized SD-JWTs

   -05

   *  Consolidate processing rules for Holder and Verifier
   *  Add support for selective disclosure of array elements.
   *  Consolidate SD-JWT terminology and format
   *  Use the term Key Binding rather than Holder Binding
   *  Defined the structure of the Key Binding JWT
   *  Added a JWS JSON Serialization
   *  Added initial IANA media type and structured suffix registration
      requests
   *  Added recommendation for explicit typing of SD-JWTs
   *  Added considerations around forwarding credentials
   *  Removed Example 2b and merged the demo of decoy digests into
      Example 2a
   *  Improved example for allowed variations in Disclosures
   *  Added some text to the Abstract and Introduction to be more
      inclusive of JWS with JSON
   *  Added some security considerations text about the scope of the Key
      Binding JWT
   *  Aligned examples structure and used the term input claim set



Fett, et al.            Expires 5 September 2024               [Page 81]

Internet-Draft                   SD-JWT                       March 2024


   *  Replaced the general SD-JWT VC example with one based on Person
      Identification Data (PID) from the European Digital Identity
      Wallet Architecture and Reference Framework
   *  Added/clarified some privacy considerations in Confidentiality
      during Transport
   *  No longer recommending a claim name for enveloped SD-JWTs
   *  Mention prospective future PQ algs for JWS
   *  Include the public key in the draft, which can be used to verify
      the issuer signature examples
   *  Clarify that _sd_alg can only be at the top level of the SD-JWT
      payload
   *  Externalized the SD-JWT library that generates examples
   *  Attempt to improve description of security properties

   -04

   *  Improve description of processing of disclosures

   -03

   *  Clarify that other specifications may define enveloping multiple
      Combined Formats for Presentation
   *  Add an example of W3C vc-data-model that uses a JSON-LD object as
      the claims set
   *  Clarify requirements for the combined formats for issuance and
      presentation
   *  Added overview of the Security Considerations section
   *  Enhanced examples in the Privacy Considerations section
   *  Allow for recursive disclosures
   *  Discussion on holder binding and privacy of stored credentials
   *  Add some context about SD-JWT being general-purpose despite being
      a product of the OAuth WG
   *  More explicitly say that SD-JWTs have to be signed asymmetrically
      (no MAC and no none)
   *  Make sha-256 the default hash algorithm, if the hash alg claim is
      omitted
   *  Use ES256 instead of RS256 in examples
   *  Rename and move the c14n challenges section to an appendix
   *  A bit more in security considerations for Choice of a Hash
      Algorithm (1st & 2nd preimage resistant and not majorly truncated)
   *  Remove the notational figures from the Concepts section
   *  Change salt to always be a string (rather than any JSON type)
   *  Fix the Document History (which had a premature list for -03)

   -02

   *  Disclosures are now delivered not as a JWT but as separate
      base64url-encoded JSON objects.



Fett, et al.            Expires 5 September 2024               [Page 82]

Internet-Draft                   SD-JWT                       March 2024


   *  In the SD-JWT, digests are collected under a _sd claim per level.
   *  Terms "II-Disclosures" and "HS-Disclosures" are replaced with
      "Disclosures".
   *  Holder Binding is now separate from delivering the Disclosures and
      implemented, if required, with a separate JWT.
   *  Examples updated and modified to properly explain the specifics of
      the new SD-JWT format.
   *  Examples are now pulled in from the examples directory, not
      inlined.
   *  Updated and automated the W3C VC example.
   *  Added examples with multibyte characters to show that the
      specification and demo code work well with UTF-8.
   *  reverted back to hash alg from digest derivation alg (renamed to
      _sd_alg)
   *  reformatted

   -01

   *  introduced blinded claim names
   *  explained why JSON-encoding of values is needed
   *  explained merging algorithm ("processing model")
   *  generalized hash alg to digest derivation alg which also enables
      HMAC to calculate digests
   *  _sd_hash_alg renamed to sd_digest_derivation_alg
   *  Salt/Value Container (SVC) renamed to Issuer-Issued Disclosures
      (II-Disclosures)
   *  SD-JWT-Release (SD-JWT-R) renamed to Holder-Selected Disclosures
      (HS-Disclosures)
   *  sd_disclosure in II-Disclosures renamed to sd_ii_disclosures
   *  sd_disclosure in HS-Disclosures renamed to sd_hs_disclosures
   *  clarified relationship between sd_hs_disclosure and SD-JWT
   *  clarified combined formats for issuance and presentation
   *  clarified security requirements for blinded claim names
   *  improved description of Holder Binding security considerations -
      especially around the usage of "alg=none".
   *  updated examples
   *  text clarifications
   *  fixed cnf structure in examples
   *  added feature summary

   -00

   *  Upload as draft-ietf-oauth-selective-disclosure-jwt-00

   [[ pre Working Group Adoption: ]]

   -02




Fett, et al.            Expires 5 September 2024               [Page 83]

Internet-Draft                   SD-JWT                       March 2024


   *  Added acknowledgements
   *  Improved Security Considerations
   *  Stressed entropy requirements for salts
   *  Python reference implementation clean-up and refactoring
   *  hash_alg renamed to _sd_hash_alg

   -01

   *  Editorial fixes
   *  Added hash_alg claim
   *  Renamed _sd to sd_digests and sd_release
   *  Added descriptions on Holder Binding - more work to do
   *  Clarify that signing the SD-JWT is mandatory

   -00

   *  Renamed to SD-JWT (focus on JWT instead of JWS since signature is
      optional)
   *  Make Holder Binding optional
   *  Rename proof to release, since when there is no signature, the
      term "proof" can be misleading
   *  Improved the structure of the description
   *  Described verification steps
   *  All examples generated from python demo implementation
   *  Examples for structured objects

Authors' Addresses

   Daniel Fett
   Authlete
   Email: mail@danielfett.de
   URI:   https://danielfett.de/


   Kristina Yasuda
   Microsoft
   Email: Kristina.Yasuda@microsoft.com


   Brian Campbell
   Ping Identity
   Email: bcampbell@pingidentity.com









Fett, et al.            Expires 5 September 2024               [Page 84]