<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-oauth-selective-disclosure-jwt-22" number="9901" updates="" obsoletes="" consensus="true" symRefs="true" sortRefs="true" submissionType="IETF" category="std" xml:lang="en" tocInclude="true" prepTime="2025-11-19T17:13:12" indexInclude="true" scripts="Common,Han,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt-22" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9901" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="SD-JWT">Selective Disclosure for JSON Web Tokens</title>
    <seriesInfo name="RFC" value="9901" stream="IETF"/>
    <author initials="D." surname="Fett" fullname="Daniel Fett">
      <organization showOnFrontPage="true">Authlete</organization>
      <address>
        <email>mail@danielfett.de</email>
        <uri>https://danielfett.de/</uri>
      </address>
    </author>
    <author initials="K." surname="Yasuda" fullname="Kristina Yasuda">
      <organization showOnFrontPage="true">Keio University</organization>
      <address>
        <email>kristina@sfc.keio.ac.jp</email>
      </address>
    </author>
    <author initials="B." surname="Campbell" fullname="Brian Campbell">
      <organization showOnFrontPage="true">Ping Identity</organization>
      <address>
        <email>bcampbell@pingidentity.com</email>
      </address>
    </author>
    <date month="11" year="2025"/>
    <area>SEC</area>
    <workgroup>oauth</workgroup>
    <keyword>security</keyword>
    <keyword>oauth2</keyword>
    <keyword>SD-JWT</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This specification defines a mechanism for the selective disclosure of individual elements of a JSON data structure used as the payload of a JSON Web Signature (JWS).
The primary use case is the selective disclosure of JSON Web Token (JWT) claims.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9901" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-feature-summary">Feature Summary</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conventions-and-terminology">Conventions and Terminology</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-flow-diagram">Flow Diagram</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-concepts">Concepts</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sd-jwt-and-disclosures">SD-JWT and Disclosures</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-disclosing-to-a-verifier">Disclosing to a Verifier</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-optional-key-binding">Optional Key Binding</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.4">
                <t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-verification">Verification</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sd-jwt-and-sd-jwtkb-data-fo">SD-JWT and SD-JWT+KB Data Formats</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-issuer-signed-jwt">Issuer-Signed JWT</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.1.2">
                  <li pn="section-toc.1-1.4.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.1.1"><xref derivedContent="4.1.1" format="counter" sectionFormat="of" target="section-4.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-hash-function-claim">Hash Function Claim</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.2.1"><xref derivedContent="4.1.2" format="counter" sectionFormat="of" target="section-4.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-key-binding">Key Binding</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-disclosures">Disclosures</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.2.2">
                  <li pn="section-toc.1-1.4.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.1.1"><xref derivedContent="4.2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-disclosures-for-object-prop">Disclosures for Object Properties</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.2.1"><xref derivedContent="4.2.2" format="counter" sectionFormat="of" target="section-4.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-disclosures-for-array-eleme">Disclosures for Array Elements</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.3.1"><xref derivedContent="4.2.3" format="counter" sectionFormat="of" target="section-4.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-hashing-disclosures">Hashing Disclosures</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.4">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.4.1"><xref derivedContent="4.2.4" format="counter" sectionFormat="of" target="section-4.2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-embedding-disclosure-digest">Embedding Disclosure Digests in SD-JWTs</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.5">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.5.1"><xref derivedContent="4.2.5" format="counter" sectionFormat="of" target="section-4.2.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-decoy-digests">Decoy Digests</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.6">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.6.1"><xref derivedContent="4.2.6" format="counter" sectionFormat="of" target="section-4.2.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-recursive-disclosures">Recursive Disclosures</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-key-binding-jwt">Key Binding JWT</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.3.2">
                  <li pn="section-toc.1-1.4.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.1.1"><xref derivedContent="4.3.1" format="counter" sectionFormat="of" target="section-4.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-binding-to-an-sd-jwt">Binding to an SD-JWT</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.2.1"><xref derivedContent="4.3.2" format="counter" sectionFormat="of" target="section-4.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-validating-the-key-binding-">Validating the Key Binding JWT</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-example-sd-jwt">Example SD-JWT</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-issuance">Issuance</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-presentation">Presentation</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-considerations-on-nested-da">Considerations on Nested Data in SD-JWTs</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-example-flat-sd-jwt">Example: Flat SD-JWT</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-example-structured-sd-jwt">Example: Structured SD-JWT</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-example-sd-jwt-with-recursi">Example: SD-JWT with Recursive Disclosures</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-verification-and-processing">Verification and Processing</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-verification-of-the-sd-jwt">Verification of the SD-JWT</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-processing-by-the-holder">Processing by the Holder</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.3">
                <t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent="7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-verification-by-the-verifie">Verification by the Verifier</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-jws-json-serialization">JWS JSON Serialization</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-new-unprotected-header-para">New Unprotected Header Parameters</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-flattened-json-serializatio">Flattened JSON Serialization</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.3">
                <t indent="0" pn="section-toc.1-1.8.2.3.1"><xref derivedContent="8.3" format="counter" sectionFormat="of" target="section-8.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-general-json-serialization">General JSON Serialization</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.4">
                <t indent="0" pn="section-toc.1-1.8.2.4.1"><xref derivedContent="8.4" format="counter" sectionFormat="of" target="section-8.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-verification-of-the-jws-jso">Verification of the JWS JSON Serialized SD-JWT</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mandatory-signing-of-the-is">Mandatory Signing of the Issuer-Signed JWT</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-manipulation-of-disclosures">Manipulation of Disclosures</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.3">
                <t indent="0" pn="section-toc.1-1.9.2.3.1"><xref derivedContent="9.3" format="counter" sectionFormat="of" target="section-9.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-entropy-of-the-salt">Entropy of the Salt</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.4">
                <t indent="0" pn="section-toc.1-1.9.2.4.1"><xref derivedContent="9.4" format="counter" sectionFormat="of" target="section-9.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-choice-of-a-hash-algorithm">Choice of a Hash Algorithm</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.5">
                <t indent="0" pn="section-toc.1-1.9.2.5.1"><xref derivedContent="9.5" format="counter" sectionFormat="of" target="section-9.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-key-binding-2">Key Binding</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.6">
                <t indent="0" pn="section-toc.1-1.9.2.6.1"><xref derivedContent="9.6" format="counter" sectionFormat="of" target="section-9.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-concealing-claim-names">Concealing Claim Names</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.7">
                <t indent="0" pn="section-toc.1-1.9.2.7.1"><xref derivedContent="9.7" format="counter" sectionFormat="of" target="section-9.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-selectively-disclosable-val">Selectively Disclosable Validity Claims</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.8">
                <t indent="0" pn="section-toc.1-1.9.2.8.1"><xref derivedContent="9.8" format="counter" sectionFormat="of" target="section-9.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-distribution-and-rotation-o">Distribution and Rotation of Issuer Signature Verification Key</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.9">
                <t indent="0" pn="section-toc.1-1.9.2.9.1"><xref derivedContent="9.9" format="counter" sectionFormat="of" target="section-9.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-forwarding-credentials">Forwarding Credentials</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.10">
                <t indent="0" pn="section-toc.1-1.9.2.10.1"><xref derivedContent="9.10" format="counter" sectionFormat="of" target="section-9.10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-integrity-of-sd-jwts-and-sd">Integrity of SD-JWTs and SD-JWT+KBs</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.11">
                <t indent="0" pn="section-toc.1-1.9.2.11.1"><xref derivedContent="9.11" format="counter" sectionFormat="of" target="section-9.11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-explicit-typing">Explicit Typing</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.12">
                <t indent="0" pn="section-toc.1-1.9.2.12.1"><xref derivedContent="9.12" format="counter" sectionFormat="of" target="section-9.12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-key-pair-generation-and-lif">Key Pair Generation and Lifecycle Management</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-privacy-considerations">Privacy Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-unlinkability">Unlinkability</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-storage-of-user-data">Storage of User Data</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.3">
                <t indent="0" pn="section-toc.1-1.10.2.3.1"><xref derivedContent="10.3" format="counter" sectionFormat="of" target="section-10.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-confidentiality-during-tran">Confidentiality During Transport</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.4">
                <t indent="0" pn="section-toc.1-1.10.2.4.1"><xref derivedContent="10.4" format="counter" sectionFormat="of" target="section-10.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-decoy-digests-2">Decoy Digests</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.5">
                <t indent="0" pn="section-toc.1-1.10.2.5.1"><xref derivedContent="10.5" format="counter" sectionFormat="of" target="section-10.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-issuer-identifier">Issuer Identifier</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.11.2">
              <li pn="section-toc.1-1.11.2.1">
                <t indent="0" pn="section-toc.1-1.11.2.1.1"><xref derivedContent="11.1" format="counter" sectionFormat="of" target="section-11.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-json-web-token-claims-regis">JSON Web Token Claims Registration</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.2">
                <t indent="0" pn="section-toc.1-1.11.2.2.1"><xref derivedContent="11.2" format="counter" sectionFormat="of" target="section-11.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-media-type-registrations">Media Type Registrations</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.3">
                <t indent="0" pn="section-toc.1-1.11.2.3.1"><xref derivedContent="11.3" format="counter" sectionFormat="of" target="section-11.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-structured-syntax-suffixes-">Structured Syntax Suffixes Registration</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" format="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.12.2">
              <li pn="section-toc.1-1.12.2.1">
                <t indent="0" pn="section-toc.1-1.12.2.1.1"><xref derivedContent="12.1" format="counter" sectionFormat="of" target="section-12.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.12.2.2">
                <t indent="0" pn="section-toc.1-1.12.2.2.1"><xref derivedContent="12.2" format="counter" sectionFormat="of" target="section-12.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-additional-examples">Additional Examples</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.13.2">
              <li pn="section-toc.1-1.13.2.1">
                <t indent="0" pn="section-toc.1-1.13.2.1.1"><xref derivedContent="A.1" format="counter" sectionFormat="of" target="section-appendix.a.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-simple-structured-sd-jwt">Simple Structured SD-JWT</xref></t>
              </li>
              <li pn="section-toc.1-1.13.2.2">
                <t indent="0" pn="section-toc.1-1.13.2.2.1"><xref derivedContent="A.2" format="counter" sectionFormat="of" target="section-appendix.a.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-complex-structured-sd-jwt">Complex Structured SD-JWT</xref></t>
              </li>
              <li pn="section-toc.1-1.13.2.3">
                <t indent="0" pn="section-toc.1-1.13.2.3.1"><xref derivedContent="A.3" format="counter" sectionFormat="of" target="section-appendix.a.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sd-jwt-based-verifiable-cre">SD-JWT-Based Verifiable Credentials (SD-JWT VC)</xref></t>
              </li>
              <li pn="section-toc.1-1.13.2.4">
                <t indent="0" pn="section-toc.1-1.13.2.4.1"><xref derivedContent="A.4" format="counter" sectionFormat="of" target="section-appendix.a.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-w3c-verifiable-credentials-">W3C Verifiable Credentials Data Model v2.0</xref></t>
              </li>
              <li pn="section-toc.1-1.13.2.5">
                <t indent="0" pn="section-toc.1-1.13.2.5.1"><xref derivedContent="A.5" format="counter" sectionFormat="of" target="section-appendix.a.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-elliptic-curve-key-used-in-">Elliptic Curve Key Used in the Examples</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.14">
            <t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="Appendix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-disclosure-format-considera">Disclosure Format Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.15">
            <t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.16">
            <t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="Introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">The exchange of JSON data between systems is often secured against modification using JSON Web Signatures (JWSs) <xref target="RFC7515" format="default" sectionFormat="of" derivedContent="RFC7515"/>.
A popular application of JWS is the JSON Web Token (JWT) <xref target="RFC7519" format="default" sectionFormat="of" derivedContent="RFC7519"/>, a format that is often used to represent a user's identity.
An ID Token as defined in OpenID Connect <xref target="OpenID.Core" format="default" sectionFormat="of" derivedContent="OpenID.Core"/>, for example, is a JWT containing the user's claims created by the server for consumption by a relying party.
In cases where the JWT is sent immediately from the server to the relying party, as in OpenID Connect, the server can select at the time of issuance which user claims to include in the JWT, minimizing the information shared with the relying party who validates the JWT.</t>
      <t indent="0" pn="section-1-2">Another model is emerging that fully decouples the issuance of a JWT from its presentation.
In this model, a JWT containing many claims is issued to an intermediate party, who holds the JWT (the Holder).
The Holder can then present the JWT to different verifying parties (Verifiers) that each may only require a subset of the claims in the JWT.
For example, the JWT may contain claims representing both an address and a birthdate.
The Holder may elect to disclose only the address to one Verifier, and only the birthdate to a different Verifier.</t>
      <t indent="0" pn="section-1-3">Privacy principles of minimal disclosure in conjunction with this model demand a mechanism enabling selective disclosure of data elements while ensuring that Verifiers can still check the authenticity of the data provided.
This specification defines such a mechanism for JSON payloads of JWSs, with JWTs as the primary use case.</t>
      <t indent="0" pn="section-1-4">Selectively Disclosable JWT (SD-JWT) is based on an approach called "salted hashes": For any data element that should be selectively disclosable, the Issuer of the SD-JWT does not include the cleartext of the data in the JSON payload of the JWS structure; instead, a digest of the data takes its place.
For presentation to a Verifier, the Holder sends the signed payload along with the cleartext of those claims it wants to disclose.
The Verifier can then compute the digest of the cleartext data and confirm it is included in the signed payload.
To ensure that Verifiers cannot guess cleartext values of non-disclosed data elements, an additional salt value is used when creating the digest and sent along with the cleartext when disclosing it.</t>
      <t indent="0" pn="section-1-5">To prevent attacks in which an SD-JWT is presented to a Verifier without the Holder's consent, this specification additionally defines a mechanism for binding the SD-JWT to a key under the control of the Holder (Key Binding).
When Key Binding is enforced, a Holder has to prove possession of a private key belonging to a public key contained in the SD-JWT itself.
It usually does so by signing over a data structure containing transaction-specific data, herein defined as the Key Binding JWT.
An SD-JWT with a Key Binding JWT is called "SD-JWT+KB" in this specification.</t>
      <section anchor="feature-summary" numbered="true" removeInRFC="false" toc="include" pn="section-1.1">
        <name slugifiedName="name-feature-summary">Feature Summary</name>
        <t indent="0" pn="section-1.1-1">This specification defines two primary data formats:</t>
        <ol spacing="normal" indent="adaptive" start="1" type="1" pn="section-1.1-2">
<li pn="section-1.1-2.1" derivedCounter="1.">
            <t indent="0" pn="section-1.1-2.1.1">SD-JWT is a composite structure, consisting of a JWS plus optional Disclosures, enabling selective disclosure of portions of the JWS payload. It comprises the following:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1.1-2.1.2">
              <li pn="section-1.1-2.1.2.1">A format for enabling selective disclosure in nested JSON data structures,
supporting selectively disclosable object properties (name/value pairs) and array elements.</li>
              <li pn="section-1.1-2.1.2.2">A format for encoding the selectively disclosable data items.</li>
              <li pn="section-1.1-2.1.2.3">A format extending the JWS Compact Serialization, allowing for the combined
transport of the Issuer-signed JSON data structure and the disclosable data items.</li>
              <li pn="section-1.1-2.1.2.4">An alternate format extending the JWS JSON Serialization, also allowing for
transport of the Issuer-signed JSON data structure and Disclosure data.</li>
            </ul>
          </li>
          <li pn="section-1.1-2.2" derivedCounter="2.">
            <t indent="0" pn="section-1.1-2.2.1">SD-JWT+KB is a composite structure of an SD-JWT and a cryptographic Key Binding that can be presented to and verified by the Verifier. It comprises the following:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1.1-2.2.2">
              <li pn="section-1.1-2.2.2.1">A mechanism for associating an SD-JWT with a key pair.</li>
              <li pn="section-1.1-2.2.2.2">A format for a Key Binding JWT (KB-JWT) that allows proof of possession of the private key of
the associated key pair.</li>
              <li pn="section-1.1-2.2.2.3">A format extending the SD-JWT format for the combined transport of the SD-JWT
and the KB-JWT.</li>
            </ul>
          </li>
        </ol>
      </section>
      <section anchor="conventions-and-terminology" numbered="true" removeInRFC="false" toc="include" pn="section-1.2">
        <name slugifiedName="name-conventions-and-terminology">Conventions and Terminology</name>
        <t indent="0" pn="section-1.2-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>
        <dl spacing="normal" newline="true" indent="3" pn="section-1.2-2">
          <dt pn="section-1.2-2.1">Base64url:</dt>
          <dd pn="section-1.2-2.2">Denotes the URL-safe base64 encoding without padding defined in
 <xref target="RFC7515" section="2" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc7515#section-2" derivedContent="RFC7515"/>.</dd>
          <dt pn="section-1.2-2.3">Claim:</dt>
          <dd pn="section-1.2-2.4">In this document, refers generally to
object properties (name/value pairs) as well as array elements.</dd>
          <dt pn="section-1.2-2.5">Selective Disclosure:</dt>
          <dd pn="section-1.2-2.6">Process of a Holder disclosing to a Verifier a subset of claims contained in a JWT issued by an Issuer.</dd>
          <dt pn="section-1.2-2.7">Selectively Disclosable JWT (SD-JWT):</dt>
          <dd pn="section-1.2-2.8">A composite structure, consisting of an Issuer-signed JWT (JWS; see <xref target="RFC7515" format="default" sectionFormat="of" derivedContent="RFC7515"/>) and zero or more Disclosures, which
supports selective disclosure as defined in this document. It can contain both regular claims and digests of selectively disclosable claims.</dd>
          <dt pn="section-1.2-2.9">Disclosure:</dt>
          <dd pn="section-1.2-2.10">A base64url-encoded string of a JSON array that contains a salt, a claim name (present when the claim is a name/value pair and absent when the claim is an array element), and a claim value. The Disclosure is used to calculate a digest for the respective claim. The term Disclosure refers to the whole base64url-encoded string.</dd>
          <dt pn="section-1.2-2.11">Key Binding:</dt>
          <dd pn="section-1.2-2.12">Ability of the Holder to prove possession of an SD-JWT by proving
control over a private key during the presentation. When utilizing Key Binding, an SD-JWT contains
the public key corresponding to the private key controlled by the Holder (or a reference to this public key).</dd>
          <dt pn="section-1.2-2.13">Key Binding JWT (KB-JWT):</dt>
          <dd pn="section-1.2-2.14">A Key Binding JWT is said to "be tied to" a particular SD-JWT when its payload
is signed using the key included in the SD-JWT payload, and the KB-JWT contains
a hash of the SD-JWT in its <tt>sd_hash</tt> claim. Its format is defined in <xref target="kb-jwt" format="default" sectionFormat="of" derivedContent="Section 4.3"/>.</dd>
          <dt pn="section-1.2-2.15">Selectively Disclosable JWT with Key Binding (SD-JWT+KB):</dt>
          <dd pn="section-1.2-2.16">A composite structure, comprising an SD-JWT and a Key Binding JWT tied to that SD-JWT.</dd>
          <dt pn="section-1.2-2.17">Processed SD-JWT Payload:</dt>
          <dd pn="section-1.2-2.18">The JSON object resulting from verification and processing of the Issuer-signed SD-JWT,
with digest placeholders replaced by the corresponding values from the Disclosures.</dd>
          <dt pn="section-1.2-2.19">Issuer:</dt>
          <dd pn="section-1.2-2.20">An entity that creates SD-JWTs.</dd>
          <dt pn="section-1.2-2.21">Holder:</dt>
          <dd pn="section-1.2-2.22">An entity that received SD-JWTs from the Issuer and has control over them. In the context of this document, the term may refer to the actual user, the supporting hardware and software in their possession, or both.</dd>
          <dt pn="section-1.2-2.23">Verifier:</dt>
          <dd pn="section-1.2-2.24">An entity that requests, checks, and extracts the claims from an SD-JWT with its respective Disclosures.</dd>
        </dl>
      </section>
    </section>
    <section anchor="flow-diagram" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-flow-diagram">Flow Diagram</name>
      <figure align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-sd-jwt-issuance-and-present">SD-JWT Issuance and Presentation Flow</name>
        <artwork align="left" pn="section-2-1.1">
           +------------+
           |            |
           |   Issuer   |
           |            |
           +------------+
                 |
            Issues SD-JWT
      including all Disclosures
                 |
                 v
           +------------+
           |            |
           |   Holder   |
           |            |
           +------------+
                 |
     Presents SD-JWT or SD-JWT+KB
    including selected Disclosures
                 |
                 v
           +-------------+
           |             |+
           |  Verifiers  ||+
           |             |||
           +-------------+||
            +-------------+|
             +-------------+
</artwork>
      </figure>
    </section>
    <section anchor="concepts" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-concepts">Concepts</name>
      <t indent="0" pn="section-3-1">This section describes SD-JWTs with their respective Disclosures and Key Binding at a
conceptual level, abstracting from the data formats described in <xref target="data_formats" format="default" sectionFormat="of" derivedContent="Section 4"/>.</t>
      <section anchor="sd-jwt-and-disclosures" numbered="true" removeInRFC="false" toc="include" pn="section-3.1">
        <name slugifiedName="name-sd-jwt-and-disclosures">SD-JWT and Disclosures</name>
        <t indent="0" pn="section-3.1-1">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 modifications to them can be detected. Selectively disclosable claims can be individual object properties (name/value pairs) or array elements.</t>
        <t indent="0" pn="section-3.1-2">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 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 with the SD-JWT in the format defined in <xref target="data_formats" format="default" sectionFormat="of" derivedContent="Section 4"/>.
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.</t>
        <t indent="0" pn="section-3.1-3">An SD-JWT <bcp14>MAY</bcp14> also contain cleartext claims that are always disclosed to the Verifier.</t>
      </section>
      <section anchor="disclosing-to-a-verifier" numbered="true" removeInRFC="false" toc="include" pn="section-3.2">
        <name slugifiedName="name-disclosing-to-a-verifier">Disclosing to a Verifier</name>
        <t indent="0" pn="section-3.2-1">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.</t>
      </section>
      <section anchor="optional-key-binding" numbered="true" removeInRFC="false" toc="include" pn="section-3.3">
        <name slugifiedName="name-optional-key-binding">Optional Key Binding</name>
        <t indent="0" pn="section-3.3-1">Key Binding is an optional feature. When Key Binding is required by the use case, the SD-JWT <bcp14>MUST</bcp14> contain information about the key material controlled by the Holder.</t>
        <aside pn="section-3.3-2">
          <t indent="0" pn="section-3.3-2.1">Note: How the public key is included in SD-JWT is described in <xref target="key_binding" format="default" sectionFormat="of" derivedContent="Section 4.1.2"/>.</t>
        </aside>
        <t indent="0" pn="section-3.3-3">When a Verifier requires Key Binding, the Holder presents an SD-JWT+KB, consisting of an SD-JWT as well as a Key Binding JWT tied to that SD-JWT.
The Key Binding JWT encodes a signature by the Holder's private key over</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.3-4">
          <li pn="section-3.3-4.1">a hash of the SD-JWT,</li>
          <li pn="section-3.3-4.2">a nonce to ensure the freshness of the signature, and</li>
          <li pn="section-3.3-4.3">an audience value to indicate the intended Verifier for the document.</li>
        </ul>
        <t indent="0" pn="section-3.3-5">Details of the format of Key Binding JWTs are described in <xref target="kb-jwt" format="default" sectionFormat="of" derivedContent="Section 4.3"/>.</t>
      </section>
      <section anchor="verification" numbered="true" removeInRFC="false" toc="include" pn="section-3.4">
        <name slugifiedName="name-verification">Verification</name>
        <t indent="0" pn="section-3.4-1">At a high level, the Verifier</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.4-2">
          <li pn="section-3.4-2.1">receives either an SD-JWT or an SD-JWT+KB from the Holder,</li>
          <li pn="section-3.4-2.2">verifies the signature on the SD-JWT (or the SD-JWT inside the SD-JWT+KB) using the Issuer's public key,</li>
          <li pn="section-3.4-2.3">verifies the signature on the KB-JWT using the public key included (or referenced) in the SD-JWT, if the Verifier's policy requires Key Binding, and</li>
          <li pn="section-3.4-2.4">calculates the digests over the Holder-Selected Disclosures and verifies that each digest is contained in the SD-JWT.</li>
        </ul>
        <t indent="0" pn="section-3.4-3">The detailed algorithm is described in <xref target="verifier_verification" format="default" sectionFormat="of" derivedContent="Section 7.3"/>.</t>
      </section>
    </section>
    <section anchor="data_formats" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-sd-jwt-and-sd-jwtkb-data-fo">SD-JWT and SD-JWT+KB Data Formats</name>
      <t indent="0" pn="section-4-1">An SD-JWT is composed of</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-2">
        <li pn="section-4-2.1">an Issuer-signed JWT, and</li>
        <li pn="section-4-2.2">zero or more Disclosures.</li>
      </ul>
      <t indent="0" pn="section-4-3">An SD-JWT+KB is composed of</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-4">
        <li pn="section-4-4.1">an SD-JWT (i.e., an Issuer-signed JWT and zero or more Disclosures), and</li>
        <li pn="section-4-4.2">a Key Binding JWT.</li>
      </ul>
      <t indent="0" pn="section-4-5">The Issuer-signed JWT, Disclosures, and Key Binding JWT are explained in Sections
<xref target="iss-signed-jwt" format="counter" sectionFormat="of" derivedContent="4.1"/>, <xref target="creating_disclosures" format="counter" sectionFormat="of" derivedContent="4.2"/>, and <xref target="kb-jwt" format="counter" sectionFormat="of" derivedContent="4.3"/>, respectively.</t>
      <t indent="0" pn="section-4-6">The compact serialized format for the SD-JWT is the concatenation of each part delineated with a single tilde ('~') character as follows, where "D.1" to "D.N" represent the respective Disclosures:</t>
      <artwork align="left" pn="section-4-7">
&lt;Issuer-signed JWT&gt;~&lt;D.1&gt;~&lt;D.2&gt;~...~&lt;D.N&gt;~
</artwork>
      <t indent="0" pn="section-4-8">The order of the concatenated parts <bcp14>MUST</bcp14> 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 <bcp14>MUST</bcp14> be an empty
string and the last separating tilde character <bcp14>MUST NOT</bcp14> be omitted.</t>
      <t indent="0" pn="section-4-9">The serialized format for an SD-JWT+KB extends the SD-JWT format by concatenating a Key Binding JWT.</t>
      <artwork align="left" pn="section-4-10">
&lt;Issuer-signed JWT&gt;~&lt;D.1&gt;~&lt;D.2&gt;~...~&lt;D.N&gt;~&lt;KB-JWT&gt;
</artwork>
      <t indent="0" pn="section-4-11">The two formats can be distinguished by the final <tt>~</tt> character that is present
on an SD-JWT.  A Verifier that expects an SD-JWT <bcp14>MUST</bcp14> verify that the final
tilde-separated component is empty.  A Verifier that expects an SD-JWT+KB <bcp14>MUST</bcp14> verify
that its final tilde-separated component is a valid KB-JWT.</t>
      <t indent="0" pn="section-4-12">The Disclosures are linked to the Issuer-signed JWT through the
digest values included therein.</t>
      <t indent="0" pn="section-4-13">When issuing to a Holder, the Issuer includes all the relevant Disclosures in the SD-JWT.</t>
      <t indent="0" pn="section-4-14">When presenting to a Verifier, the Holder sends only the selected set of the Disclosures in the SD-JWT.</t>
      <t indent="0" pn="section-4-15">The Holder <bcp14>MAY</bcp14> 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 <bcp14>MUST NOT</bcp14> send Disclosures or reveal the salt values in any
other way. A Holder <bcp14>MUST NOT</bcp14> send a Disclosure that was not included in the issued
SD-JWT or send a Disclosure more than once.</t>
      <t indent="0" pn="section-4-16">To further illustrate the SD-JWT format, the following examples show a few different
SD-JWT permutations, both with and without various constituent parts.</t>
      <t indent="0" pn="section-4-17">An SD-JWT without Disclosures:</t>
      <artwork align="left" pn="section-4-18">
&lt;Issuer-signed JWT&gt;~
</artwork>
      <t indent="0" pn="section-4-19">An SD-JWT with Disclosures:</t>
      <artwork align="left" pn="section-4-20">
&lt;Issuer-signed JWT&gt;~&lt;Disclosure 1&gt;~&lt;Disclosure N&gt;~
</artwork>
      <t indent="0" pn="section-4-21">An SD-JWT+KB without Disclosures:</t>
      <artwork align="left" pn="section-4-22">
&lt;Issuer-signed JWT&gt;~&lt;KB-JWT&gt;
</artwork>
      <t indent="0" pn="section-4-23">An SD-JWT+KB with Disclosures:</t>
      <artwork align="left" pn="section-4-24">
&lt;Issuer-signed JWT&gt;~&lt;Disclosure 1&gt;~&lt;Disclosure N&gt;~&lt;KB-JWT&gt;
</artwork>
      <t indent="0" pn="section-4-25">As an alternative illustration of the SD-JWT format, ABNF <xref target="RFC5234" format="default" sectionFormat="of" derivedContent="RFC5234"/> for the
SD-JWT, SD-JWT+KB, and various constituent parts is provided here (for those who celebrate):</t>
      <sourcecode type="abnf" markers="false" pn="section-4-26">
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
BASE64URL = 1*(ALPHA / DIGIT / "-" / "_")
JWT = BASE64URL "." BASE64URL "." BASE64URL
DISCLOSURE = BASE64URL
SD-JWT = JWT "~" *(DISCLOSURE "~")
KB-JWT = JWT
SD-JWT-KB = SD-JWT KB-JWT
</sourcecode>
      <section anchor="iss-signed-jwt" numbered="true" removeInRFC="false" toc="include" pn="section-4.1">
        <name slugifiedName="name-issuer-signed-jwt">Issuer-Signed JWT</name>
        <t indent="0" pn="section-4.1-1">An SD-JWT has a JWT component that <bcp14>MUST</bcp14> be signed using the Issuer's private
key. It <bcp14>MUST NOT</bcp14> use the <tt>none</tt> algorithm.</t>
        <t indent="0" pn="section-4.1-2">The payload of an SD-JWT is a JSON object according to the following rules:</t>
        <ol spacing="normal" indent="adaptive" start="1" type="1" pn="section-4.1-3">
<li pn="section-4.1-3.1" derivedCounter="1.">The payload <bcp14>MAY</bcp14> contain the <tt>_sd_alg</tt> key described in <xref target="hash_function_claim" format="default" sectionFormat="of" derivedContent="Section 4.1.1"/>.</li>
          <li pn="section-4.1-3.2" derivedCounter="2.">The payload <bcp14>MAY</bcp14> contain one or more digests of Disclosures to enable selective disclosure of the respective claims, created and formatted as described in <xref target="creating_disclosures" format="default" sectionFormat="of" derivedContent="Section 4.2"/>.</li>
          <li pn="section-4.1-3.3" derivedCounter="3.">The payload <bcp14>MAY</bcp14> contain one or more decoy digests to obscure the actual number of claims in the SD-JWT, created and formatted as described in <xref target="decoy_digests" format="default" sectionFormat="of" derivedContent="Section 4.2.5"/>.</li>
          <li pn="section-4.1-3.4" derivedCounter="4.">The payload <bcp14>MAY</bcp14> contain one or more permanently disclosed claims.</li>
          <li pn="section-4.1-3.5" derivedCounter="5.">The payload <bcp14>MAY</bcp14> contain the Holder's public key(s) or reference(s) thereto, as explained in <xref target="key_binding" format="default" sectionFormat="of" derivedContent="Section 4.1.2"/>.</li>
          <li pn="section-4.1-3.6" derivedCounter="6.">The payload <bcp14>MAY</bcp14> contain further claims such as <tt>iss</tt>, <tt>iat</tt>, etc. as defined or required by the application using SD-JWTs.</li>
          <li pn="section-4.1-3.7" derivedCounter="7.">The payload <bcp14>MUST NOT</bcp14> contain the claims <tt>_sd</tt> or <tt>...</tt> except for the purpose of conveying digests as described in Sections <xref target="embedding_object_properties" format="counter" sectionFormat="of" derivedContent="4.2.4.1"/> and <xref target="embedding_array_elements" format="counter" sectionFormat="of" derivedContent="4.2.4.2"/>, respectively.</li>
        </ol>
        <t indent="0" pn="section-4.1-4">The same digest value <bcp14>MUST NOT</bcp14> appear more than once in the SD-JWT.</t>
        <t indent="0" pn="section-4.1-5">Application and profiles of SD-JWT <bcp14>SHOULD</bcp14> be explicitly typed. See <xref target="explicit_typing" format="default" sectionFormat="of" derivedContent="Section 9.11"/> for more details.</t>
        <t indent="0" pn="section-4.1-6">It is the Issuer who decides which claims are selectively disclosable by the Holder and which are not. Claims <bcp14>MAY</bcp14> 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 <xref target="sd-validity-claims" format="default" sectionFormat="of" derivedContent="Section 9.7"/> for considerations on making validity-controlling claims such as <tt>exp</tt> selectively disclosable.</t>
        <t indent="0" pn="section-4.1-7">Claims that are not selectively disclosable are included in the SD-JWT in plaintext just as they would be in any other JSON structure.</t>
        <section anchor="hash_function_claim" numbered="true" removeInRFC="false" toc="include" pn="section-4.1.1">
          <name slugifiedName="name-hash-function-claim">Hash Function Claim</name>
          <t indent="0" pn="section-4.1.1-1">The claim <tt>_sd_alg</tt> indicates the hash algorithm used by the Issuer to generate
the digests as described in <xref target="creating_disclosures" format="default" sectionFormat="of" derivedContent="Section 4.2"/>. When used, this claim <bcp14>MUST</bcp14>
appear at the top level of the SD-JWT payload. It
<bcp14>MUST NOT</bcp14> be used in any object nested within the payload. If the  <tt>_sd_alg</tt>
claim is not present at the top level, a default value of <tt>sha-256</tt> <bcp14>MUST</bcp14> be used.</t>
          <t indent="0" pn="section-4.1.1-2">This claim value is a case-sensitive string with the hash algorithm identifier.
The hash algorithm identifier <bcp14>MUST</bcp14> be a hash algorithm value from the "Hash Name
String" column in the "Named Information Hash Algorithm Registry"
<xref target="Hash.Algs" format="default" sectionFormat="of" derivedContent="Hash.Algs"/> or a value defined in another specification and/or
profile of this specification.</t>
          <t indent="0" pn="section-4.1.1-3">To promote interoperability, implementations <bcp14>MUST</bcp14> support the <tt>sha-256</tt> hash
algorithm.</t>
          <t indent="0" pn="section-4.1.1-4">See <xref target="security_considerations" format="default" sectionFormat="of" derivedContent="Section 9"/> for requirements regarding entropy of the salt,
minimum length of the salt, and choice of a hash algorithm.</t>
        </section>
        <section anchor="key_binding" numbered="true" removeInRFC="false" toc="include" pn="section-4.1.2">
          <name slugifiedName="name-key-binding">Key Binding</name>
          <t indent="0" pn="section-4.1.2-1">If the Issuer wants to enable Key Binding, it includes a public key
associated with the Holder, or a reference thereto, using the <tt>cnf</tt> claim as defined in <xref target="RFC7800" format="default" sectionFormat="of" derivedContent="RFC7800"/>.
The <tt>jwk</tt> confirmation method, as defined in <xref target="RFC7800" section="3.2" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc7800#section-3.2" derivedContent="RFC7800"/>, is
suggested for doing so, however, other confirmation methods can be used.</t>
          <aside pn="section-4.1.2-2">
            <t indent="0" pn="section-4.1.2-2.1">Note that, as was stated in <xref target="RFC7800" format="default" sectionFormat="of" derivedContent="RFC7800"/>,
if an application needs to represent multiple proof-of-possession
keys in the same SD-JWT, one way to achieve this is to use other
claim names, in addition to <tt>cnf</tt>, to hold the additional proof-of-possession key information.</t>
          </aside>
          <t indent="0" pn="section-4.1.2-3">It is outside the scope of this document to describe how the Holder key pair is
established. For example, the Holder <bcp14>MAY</bcp14> create a key pair and provide a public key to the Issuer,
the Issuer <bcp14>MAY</bcp14> create the key pair for the Holder, or
Holder and Issuer <bcp14>MAY</bcp14> use pre-established key material.</t>
          <aside pn="section-4.1.2-4">
            <t indent="0" pn="section-4.1.2-4.1">Note: The examples throughout this document use the <tt>cnf</tt> claim with the <tt>jwk</tt> member to include
the raw public key by value in SD-JWT.</t>
          </aside>
        </section>
      </section>
      <section anchor="creating_disclosures" numbered="true" removeInRFC="false" toc="include" pn="section-4.2">
        <name slugifiedName="name-disclosures">Disclosures</name>
        <t indent="0" pn="section-4.2-1">Disclosures are created differently depending on whether a claim is an object property (name/value pair) or an array element.</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2-2">
          <li pn="section-4.2-2.1">For a claim that is an object property, the Issuer creates a Disclosure as described in <xref target="disclosures_for_object_properties" format="default" sectionFormat="of" derivedContent="Section 4.2.1"/>.</li>
          <li pn="section-4.2-2.2">For a claim that is an array element, the Issuer creates a Disclosure as described in <xref target="disclosures_for_array_elements" format="default" sectionFormat="of" derivedContent="Section 4.2.2"/>.</li>
        </ul>
        <section anchor="disclosures_for_object_properties" numbered="true" removeInRFC="false" toc="include" pn="section-4.2.1">
          <name slugifiedName="name-disclosures-for-object-prop">Disclosures for Object Properties</name>
          <t indent="0" pn="section-4.2.1-1">For each claim that is an object property and that is to be made selectively disclosable, the Issuer <bcp14>MUST</bcp14> create a Disclosure as follows:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2.1-2">
            <li pn="section-4.2.1-2.1">
              <t indent="0" pn="section-4.2.1-2.1.1">Create a JSON array of three elements in the following order:</t>
              <ol spacing="normal" indent="adaptive" start="1" type="1" pn="section-4.2.1-2.1.2">
<li pn="section-4.2.1-2.1.2.1" derivedCounter="1.">A salt value. <bcp14>MUST</bcp14> be a string. See <xref target="salt-entropy" format="default" sectionFormat="of" derivedContent="Section 9.3"/> for security considerations. To achieve the recommended entropy of the salt, the Issuer can base64url-encode 128 bits of cryptographically secure random data, producing a string. The salt value <bcp14>MUST</bcp14> be unique for each claim that is to be selectively disclosed. The Issuer <bcp14>MUST NOT</bcp14> reveal the salt value to any party other than the Holder.</li>
                <li pn="section-4.2.1-2.1.2.2" derivedCounter="2.">The claim name, or key, as it would be used in a regular JWT payload. It <bcp14>MUST</bcp14> be a string and <bcp14>MUST NOT</bcp14> be <tt>_sd</tt>, <tt>...</tt>, or a claim name existing in the object as a permanently disclosed claim.</li>
                <li pn="section-4.2.1-2.1.2.3" derivedCounter="3.">The claim value, as it would be used in a regular JWT payload. The value can be of any type that is allowed in JSON, including numbers, strings, booleans, arrays, null, and objects.</li>
              </ol>
            </li>
            <li pn="section-4.2.1-2.2">base64url-encode the UTF-8 byte sequence of the JSON array. This string is the Disclosure.</li>
          </ul>
          <aside pn="section-4.2.1-3">
            <t indent="0" pn="section-4.2.1-3.1">Note: The order was decided based on readability considerations: Salts 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.</t>
          </aside>
          <t indent="0" pn="section-4.2.1-4">The following example illustrates the steps described above.</t>
          <t indent="0" pn="section-4.2.1-5">The array is created as follows:</t>
          <sourcecode type="json" markers="false" pn="section-4.2.1-6">
["_26bc4LT-ac6q2KI6cBW5es", "family_name", "Möbius"]
</sourcecode>
          <t indent="0" pn="section-4.2.1-7">The resultant Disclosure is:</t>
          <t indent="0" pn="section-4.2.1-8"><tt>WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNw7ZiaXVzIl0</tt></t>
          <t indent="0" pn="section-4.2.1-9">Note that variations in whitespace, encoding of Unicode characters, ordering of object properties, etc., are allowed
in the JSON representation and no canonicalization needs to be performed before base64url encoding because the digest is calculated over the base64url-encoded value itself.
For example, the following strings are all valid and encode the
same claim value "Möbius":</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2.1-10">
            <li pn="section-4.2.1-10.1">
              <t indent="0" pn="section-4.2.1-10.1.1">A different way to encode the Unicode umlaut:</t>
              <t indent="0" pn="section-4.2.1-10.1.2"><tt>WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNXHUwMGY2Yml1cyJd</tt></t>
            </li>
            <li pn="section-4.2.1-10.2">
              <t indent="0" pn="section-4.2.1-10.2.1">No white space:</t>
              <t indent="0" pn="section-4.2.1-10.2.2"><tt>WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsImZhbWlseV9uYW1lIiwiTcO2Yml1cyJd</tt></t>
            </li>
            <li pn="section-4.2.1-10.3">
              <t indent="0" pn="section-4.2.1-10.3.1">Newline characters between elements:</t>
              <t indent="0" pn="section-4.2.1-10.3.2"><tt>WwoiXzI2YmM0TFQtYWM2cTJLSTZjQlc1ZXMiLAoiZmFtaWx5X25hbWUiLAoiTcO2Yml1cyIKXQ</tt></t>
            </li>
          </ul>
          <t indent="0" pn="section-4.2.1-11">However, the digest is calculated over the respective base64url-encoded value itself, which effectively signs the variation chosen by the Issuer and makes it immutable in the context of the particular SD-JWT.</t>
          <t indent="0" pn="section-4.2.1-12">See <xref target="disclosure_format_considerations" format="default" sectionFormat="of" derivedContent="Appendix B"/> for some further considerations on the Disclosure format approach.</t>
        </section>
        <section anchor="disclosures_for_array_elements" numbered="true" removeInRFC="false" toc="include" pn="section-4.2.2">
          <name slugifiedName="name-disclosures-for-array-eleme">Disclosures for Array Elements</name>
          <t indent="0" pn="section-4.2.2-1">For each claim that is an array element and that is to be made selectively disclosable, the Issuer <bcp14>MUST</bcp14> create a Disclosure as follows:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2.2-2">
            <li pn="section-4.2.2-2.1">
              <t indent="0" pn="section-4.2.2-2.1.1">The array <bcp14>MUST</bcp14> contain two elements in this order:</t>
              <ol spacing="normal" indent="adaptive" start="1" type="1" pn="section-4.2.2-2.1.2">
<li pn="section-4.2.2-2.1.2.1" derivedCounter="1.">The salt value as described in <xref target="disclosures_for_object_properties" format="default" sectionFormat="of" derivedContent="Section 4.2.1"/>.</li>
                <li pn="section-4.2.2-2.1.2.2" derivedCounter="2.">The array element that is to be hidden. This value can be of any type that is allowed in JSON, including numbers, strings, booleans, arrays, and objects.</li>
              </ol>
            </li>
          </ul>
          <t indent="0" pn="section-4.2.2-3">The Disclosure string is created by base64url-encoding the UTF-8 byte sequence of the resultant JSON array as described in <xref target="disclosures_for_object_properties" format="default" sectionFormat="of" derivedContent="Section 4.2.1"/>. The same considerations regarding
variations in the result of the JSON encoding apply.</t>
          <t indent="0" pn="section-4.2.2-4">For example, a Disclosure for the second element of the <tt>nationalities</tt> array in the following JWT Claims Set:</t>
          <sourcecode type="json" markers="false" pn="section-4.2.2-5">
{
  "nationalities": ["DE", "FR", "US"]
}
</sourcecode>
          <t indent="0" pn="section-4.2.2-6">could be created by first creating the following array:</t>
          <sourcecode type="json" markers="false" pn="section-4.2.2-7">
["lklxF5jMYlGTPUovMNIvCA", "FR"]
</sourcecode>
          <t indent="0" pn="section-4.2.2-8">The resultant Disclosure would be:</t>
          <t indent="0" pn="section-4.2.2-9"><tt>WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIkZSIl0</tt></t>
          <aside pn="section-4.2.2-10">
            <t indent="0" pn="section-4.2.2-10.1">Note that the size of an array alone can potentially reveal unintended information.
The use of decoys, as described in <xref target="decoy_digests" format="default" sectionFormat="of" derivedContent="Section 4.2.5"/>, to consistently pad the size of an array can help obscure
the actual number of elements present in any particular instance.</t>
          </aside>
        </section>
        <section anchor="hashing_disclosures" numbered="true" removeInRFC="false" toc="include" pn="section-4.2.3">
          <name slugifiedName="name-hashing-disclosures">Hashing Disclosures</name>
          <t indent="0" pn="section-4.2.3-1">For embedding references to the Disclosures in the SD-JWT, each Disclosure is hashed using the hash algorithm specified in the <tt>_sd_alg</tt> claim described in <xref target="hash_function_claim" format="default" sectionFormat="of" derivedContent="Section 4.1.1"/>, or SHA-256 if no algorithm is specified. The resultant digest is then included in the SD-JWT payload instead of the original claim value, as described next.</t>
          <t indent="0" pn="section-4.2.3-2">The digest <bcp14>MUST</bcp14> be computed over the US-ASCII bytes of the base64url-encoded value that is the Disclosure. This follows the convention in JWS <xref target="RFC7515" format="default" sectionFormat="of" derivedContent="RFC7515"/> and JWE <xref target="RFC7516" format="default" sectionFormat="of" derivedContent="RFC7516"/>. The bytes of the digest <bcp14>MUST</bcp14> then be base64url encoded.</t>
          <t indent="0" pn="section-4.2.3-3">It is important to note that:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2.3-4">
            <li pn="section-4.2.3-4.1">The input to the hash function <bcp14>MUST</bcp14> be the base64url-encoded Disclosure, not the bytes encoded by the base64url string.</li>
            <li pn="section-4.2.3-4.2">The bytes of the output of the hash function <bcp14>MUST</bcp14> be base64url encoded, and are not the bytes making up the (sometimes used) hex representation of the bytes of the digest.</li>
          </ul>
          <t indent="0" pn="section-4.2.3-5">For example, the base64url-encoded SHA-256 digest of the Disclosure
<tt>WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNw7ZiaXVzIl0</tt>
for the <tt>family_name</tt> claim from <xref target="disclosures_for_object_properties" format="default" sectionFormat="of" derivedContent="Section 4.2.1"/> above is
<tt>X9yH0Ajrdm1Oij4tWso9UzzKJvPoDxwmuEcO3XAdRC0</tt>.</t>
        </section>
        <section anchor="embedding_disclosure_digests" numbered="true" removeInRFC="false" toc="include" pn="section-4.2.4">
          <name slugifiedName="name-embedding-disclosure-digest">Embedding Disclosure Digests in SD-JWTs</name>
          <t indent="0" pn="section-4.2.4-1">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.</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2.4-2">
            <li pn="section-4.2.4-2.1">For a claim that is an object property, the Issuer embeds a Disclosure digest as described in <xref target="embedding_object_properties" format="default" sectionFormat="of" derivedContent="Section 4.2.4.1"/>.</li>
            <li pn="section-4.2.4-2.2">For a claim that is an array element, the Issuer creates a Disclosure digest as described in <xref target="embedding_array_elements" format="default" sectionFormat="of" derivedContent="Section 4.2.4.2"/>.</li>
          </ul>
          <section anchor="embedding_object_properties" numbered="true" removeInRFC="false" toc="exclude" pn="section-4.2.4.1">
            <name slugifiedName="name-object-properties">Object Properties</name>
            <t indent="0" pn="section-4.2.4.1-1">Digests of Disclosures for object properties are added to an array under the new
key <tt>_sd</tt> in the object. The <tt>_sd</tt> key <bcp14>MUST</bcp14> refer to an array of strings, each
string being a digest of a Disclosure or a decoy digest as described in <xref target="decoy_digests" format="default" sectionFormat="of" derivedContent="Section 4.2.5"/>.
An <tt>_sd</tt> key can be present at any level of the JSON object hierarchy, including at the top-level,
nested deeper as described in <xref target="nested_data" format="default" sectionFormat="of" derivedContent="Section 6"/>, or in recursive Disclosures as described in <xref target="recursive_disclosures" format="default" sectionFormat="of" derivedContent="Section 4.2.6"/>.</t>
            <t indent="0" pn="section-4.2.4.1-2">The array <bcp14>MAY</bcp14> be empty in case the Issuer decided not to selectively disclose
any of the claims at that level. However, it is <bcp14>RECOMMENDED</bcp14> to omit the <tt>_sd</tt>
key in this case to save space.</t>
            <t indent="0" pn="section-4.2.4.1-3">The Issuer <bcp14>MUST</bcp14> hide the original order of the claims in the array. To ensure
this, it is <bcp14>RECOMMENDED</bcp14> to shuffle the array of hashes, e.g., by sorting it
alphanumerically or randomly, after potentially adding
decoy digests as described in <xref target="decoy_digests" format="default" sectionFormat="of" derivedContent="Section 4.2.5"/>. The precise method does not matter as long as it
does not depend on the original order of elements.</t>
            <t indent="0" pn="section-4.2.4.1-4">For example, using the digest of the Disclosure from <xref target="hashing_disclosures" format="default" sectionFormat="of" derivedContent="Section 4.2.3"/>,
the Issuer could create the following SD-JWT payload to make <tt>family_name</tt>
selectively disclosable:</t>
            <sourcecode type="json" markers="false" pn="section-4.2.4.1-5">
{
  "given_name": "Alice",
  "_sd": ["X9yH0Ajrdm1Oij4tWso9UzzKJvPoDxwmuEcO3XAdRC0"]
}
</sourcecode>
          </section>
          <section anchor="embedding_array_elements" numbered="true" removeInRFC="false" toc="exclude" pn="section-4.2.4.2">
            <name slugifiedName="name-array-elements">Array Elements</name>
            <t indent="0" pn="section-4.2.4.2-1">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 <tt>{"...": "&lt;digest&gt;"}</tt> is added to the array. The key <bcp14>MUST</bcp14> always be the
string <tt>...</tt> (three dots). The value <bcp14>MUST</bcp14> be the digest of the Disclosure created as
described in <xref target="hashing_disclosures" format="default" sectionFormat="of" derivedContent="Section 4.2.3"/>. There <bcp14>MUST NOT</bcp14> be any other keys in the
object. Note that the string <tt>...</tt> was chosen because the ellipsis character, typically entered as three period characters, is commonly used in places where content is omitted from the present context.</t>
            <t indent="0" pn="section-4.2.4.2-2">For example, using the digest of the array element Disclosure created in <xref target="disclosures_for_array_elements" format="default" sectionFormat="of" derivedContent="Section 4.2.2"/>,
the Issuer could create the following SD-JWT payload to make the second element
of the <tt>nationalities</tt> array selectively disclosable:</t>
            <sourcecode type="json" markers="false" pn="section-4.2.4.2-3">
{
  "nationalities":
    ["DE", {"...":"w0I8EKcdCtUPkGCNUrfwVp2xEgNjtoIDlOxc9-PlOhs"},
     "US"]
}
</sourcecode>
            <t indent="0" pn="section-4.2.4.2-4">As described in <xref target="verifier_verification" format="default" sectionFormat="of" derivedContent="Section 7.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 two
elements, <tt>["DE", "US"]</tt>, unless the matching Disclosure for the second element is received,
in which case the output would be a three-element array, <tt>["DE", "FR", "US"]</tt>.</t>
          </section>
        </section>
        <section anchor="decoy_digests" numbered="true" removeInRFC="false" toc="include" pn="section-4.2.5">
          <name slugifiedName="name-decoy-digests">Decoy Digests</name>
          <t indent="0" pn="section-4.2.5-1">An Issuer <bcp14>MAY</bcp14> 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 adversarial Verifier to see the original number of claims or array elements contained in the SD-JWT. Decoy
digests <bcp14>MAY</bcp14> be added both to the <tt>_sd</tt> array for objects as well as in arrays.</t>
          <t indent="0" pn="section-4.2.5-2">It is <bcp14>RECOMMENDED</bcp14> to create the decoy digests by hashing over a
cryptographically secure random number. The bytes of the digest <bcp14>MUST</bcp14> then be
base64url encoded as above. The same digest function as for the Disclosures <bcp14>MUST</bcp14>
be used.</t>
          <t indent="0" pn="section-4.2.5-3">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
<xref target="decoy_digests_privacy" format="default" sectionFormat="of" derivedContent="Section 10.4"/> for additional privacy considerations.</t>
          <t indent="0" pn="section-4.2.5-4">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 <xref target="example-simple_structured" format="default" sectionFormat="of" derivedContent="Appendix A.1"/>.</t>
        </section>
        <section anchor="recursive_disclosures" numbered="true" removeInRFC="false" toc="include" pn="section-4.2.6">
          <name slugifiedName="name-recursive-disclosures">Recursive Disclosures</name>
          <t indent="0" pn="section-4.2.6-1">The algorithms above are compatible with "recursive Disclosures", in which one
selectively disclosed field reveals the existence of more selectively
disclosable fields.  For example, consider the following JSON structure:</t>
          <sourcecode type="json" markers="false" pn="section-4.2.6-2">
{
    "family_name": "Möbius",
    "nationalities": ["DE", "FR", "UK"]
}
</sourcecode>
          <t indent="0" pn="section-4.2.6-3">When the Holder has multiple nationalities, the Issuer may wish to conceal
the presence of any statement regarding nationalities while also allowing the
Holder to reveal each of those nationalities individually.
This can be accomplished by first making the entries within the "nationalities"
array selectively disclosable, and then making the whole "nationalities" field
selectively disclosable.</t>
          <t indent="0" pn="section-4.2.6-4">The following shows each of the entries within the "nationalities" array being made selectively disclosable:</t>
          <sourcecode type="json" markers="false" pn="section-4.2.6-5">
{
    "family_name": "Möbius",
    "nationalities": [
        { "...": "PmnlrRjhLcwf8zTDdK15HVGwHtPYjddvD362WjBLwro" }
        { "...": "r823HFN6Ba_lpSANYtXqqCBAH-TsQlIzfOK0lRAFLCM" },
        { "...": "nP5GYjwhFm6ESlAeC4NCaIliW4tz0hTrUeoJB3lb5TA" }
    ]
}
</sourcecode>
          <t indent="0" pn="section-4.2.6-6">Content of Disclosures:</t>
          <sourcecode type="json" markers="false" pn="section-4.2.6-7">
PmnlrRj... = ["16_mAd0GiwaZokU26_0i0h","DE"]
r823HFN... = ["fn9fN0rD-fFs2n303ZI-0c","FR"]
nP5GYjw... = ["YIKesqOkXXNzMQtsX_-_lw","UK"]
</sourcecode>
          <t indent="0" pn="section-4.2.6-8">Followed by making the whole "nationalities" array selectively disclosable:</t>
          <sourcecode type="json" markers="false" pn="section-4.2.6-9">
{
    "family_name": "Möbius",
    "_sd": [ "5G1srw3RG5W4pVTwSsYxeOWosRBbzd18ZoWKkC-hBL4" ]
}
</sourcecode>
          <t indent="0" pn="section-4.2.6-10">Content of Disclosures:</t>
          <sourcecode type="json" markers="false" pn="section-4.2.6-11">
PmnlrRj... = ["16_mAd0GiwaZokU26_0i0h","DE"]
r823HFN... = ["fn9fN0rD-fFs2n303ZI-0c","FR"]
nP5GYjw... = ["YIKesqOkXXNzMQtsX_-_lw","UK"]
5G1srw3... = ["4drfeTtSUK3aY_-PF12gcX","nationalities",
    [
        { "...": "PmnlrRjhLcwf8zTDdK15HVGwHtPYjddvD362WjBLwro" },
        { "...": "r823HFN6Ba_lpSANYtXqqCBAH-TsQlIzfOK0lRAFLCM" },
        { "...": "nP5GYjwhFm6ESlAeC4NCaIliW4tz0hTrUeoJB3lb5TA" }
    ]
]
</sourcecode>
          <t indent="0" pn="section-4.2.6-12">With this set of Disclosures, the Holder could include the Disclosure with hash
<tt>PmnlrRj...</tt> to disclose only the "DE" nationality, or include both <tt>PmnlrRj...</tt>
and <tt>r823HFN...</tt> to disclose both the "DE" and "FR" nationalities, but hide the
"UK" nationality. In either case, the Holder would also need to include the
Disclosure with hash <tt>5G1srw3...</tt> to disclose the <tt>nationalities</tt> field that
contains the respective elements.</t>
          <t indent="0" pn="section-4.2.6-13">Note that making recursive redactions introduces dependencies between the
Disclosure objects in an SD-JWT.  The <tt>r823HFN...</tt> Disclosure cannot be used
without the <tt>5G1srw3...</tt> Disclosure; since a Verifier would not have a matching
hash that would tell it where the content of the <tt>r823HFN...</tt> Disclosure should
be inserted.  If a Disclosure object is included in an SD-JWT, then the SD-JWT
<bcp14>MUST</bcp14> include any other Disclosure objects necessary to process the first
Disclosure object.  In other words, any Disclosure object in an SD-JWT must
"connect" to the claims in the issuer-signed JWT, possibly via an intermediate
Disclosure object.  In the above example, it would be illegal to include any one
of the <tt>PmnlrRj...</tt>, <tt>r823HFN...</tt>, <tt>nP5GYjw...</tt> Disclosure objects without also
including the <tt>5G1srw3...</tt> Disclosure object.</t>
        </section>
      </section>
      <section anchor="kb-jwt" numbered="true" removeInRFC="false" toc="include" pn="section-4.3">
        <name slugifiedName="name-key-binding-jwt">Key Binding JWT</name>
        <t indent="0" pn="section-4.3-1">This section defines the Key Binding JWT, which encodes a
signature over an SD-JWT by the Holder's private key.</t>
        <t indent="0" pn="section-4.3-2">The Key Binding JWT <bcp14>MUST</bcp14> be a JWT according to <xref target="RFC7519" format="default" sectionFormat="of" derivedContent="RFC7519"/>, and it <bcp14>MUST</bcp14> contain the following elements:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.3-3">
          <li pn="section-4.3-3.1">
            <t indent="0" pn="section-4.3-3.1.1">in the JOSE header,</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.3-3.1.2">
              <li pn="section-4.3-3.1.2.1">
                <tt>typ</tt>: <bcp14>REQUIRED</bcp14>. <bcp14>MUST</bcp14> be <tt>kb+jwt</tt>, which explicitly types the Key Binding JWT as recommended in <xref target="RFC8725" section="3.11" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8725#section-3.11" derivedContent="RFC8725"/>.</li>
              <li pn="section-4.3-3.1.2.2">
                <tt>alg</tt>: <bcp14>REQUIRED</bcp14>. A digital signature algorithm identifier such as per the IANA "JSON Web Signature and Encryption Algorithms" registry. It <bcp14>MUST NOT</bcp14> be "none".</li>
            </ul>
          </li>
          <li pn="section-4.3-3.2">
            <t indent="0" pn="section-4.3-3.2.1">in the JWT payload,</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.3-3.2.2">
              <li pn="section-4.3-3.2.2.1">
                <tt>iat</tt>: <bcp14>REQUIRED</bcp14>. The value of this claim <bcp14>MUST</bcp14> be the time at which the Key Binding JWT was issued using the syntax defined in <xref target="RFC7519" format="default" sectionFormat="of" derivedContent="RFC7519"/>.</li>
              <li pn="section-4.3-3.2.2.2">
                <tt>aud</tt>: <bcp14>REQUIRED</bcp14>. The value <bcp14>MUST</bcp14> be a single string that identifies the intended receiver of the Key Binding JWT. How the value is represented is up to the protocol used and is out of scope for this specification.</li>
              <li pn="section-4.3-3.2.2.3">"nonce": <bcp14>REQUIRED</bcp14>. Ensures the freshness of the signature or its binding to the given transaction. The value type of this claim <bcp14>MUST</bcp14> be a string. How this value is obtained is up to the protocol used and is out of scope for this specification.</li>
              <li pn="section-4.3-3.2.2.4">
                <tt>sd_hash</tt>: <bcp14>REQUIRED</bcp14>. The base64url-encoded hash value over the Issuer-signed JWT and the selected Disclosures as defined below.</li>
            </ul>
          </li>
        </ul>
        <t indent="0" pn="section-4.3-4">The general extensibility model of JWT means that additional claims and header parameters can be added to the Key Binding JWT.
However, unless there is a compelling reason, this <bcp14>SHOULD</bcp14> be avoided, as it may harm interoperability and burden conceptual integrity.</t>
        <section anchor="integrity-protection-of-the-presentation" numbered="true" removeInRFC="false" toc="include" pn="section-4.3.1">
          <name slugifiedName="name-binding-to-an-sd-jwt">Binding to an SD-JWT</name>
          <t indent="0" pn="section-4.3.1-1">The hash value in the <tt>sd_hash</tt> claim binds the KB-JWT to the specific SD-JWT.
The <tt>sd_hash</tt> value <bcp14>MUST</bcp14> be computed over the US-ASCII bytes of the
encoded SD-JWT, 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:</t>
          <artwork align="left" pn="section-4.3.1-2">
&lt;Issuer-signed JWT&gt;~&lt;Disclosure 1&gt;~&lt;Disclosure 2&gt;~...~&lt;Disclosure N&gt;~
</artwork>
          <t indent="0" pn="section-4.3.1-3">The bytes of the digest <bcp14>MUST</bcp14> then be base64url encoded.</t>
          <t indent="0" pn="section-4.3.1-4">The same hash algorithm as for the Disclosures <bcp14>MUST</bcp14> be used (defined by
the <tt>_sd_alg</tt> element in the Issuer-signed JWT or the default value, as defined
in <xref target="hash_function_claim" format="default" sectionFormat="of" derivedContent="Section 4.1.1"/>).</t>
        </section>
        <section anchor="validating-the-key-binding-jwt" numbered="true" removeInRFC="false" toc="include" pn="section-4.3.2">
          <name slugifiedName="name-validating-the-key-binding-">Validating the Key Binding JWT</name>
          <t indent="0" pn="section-4.3.2-1">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
<xref target="key_binding_security" format="default" sectionFormat="of" derivedContent="Section 9.5"/> for security considerations.</t>
          <t indent="0" pn="section-4.3.2-2">If the Verifier requires Key Binding, the Verifier <bcp14>MUST</bcp14> ensure that the key with which it validates the signature on
the Key Binding JWT is the key specified in the SD-JWT as the Holder's public
key.  For example, if the SD-JWT contains a <tt>cnf</tt> value with a <tt>jwk</tt> member, the
Verifier would parse the provided JWK and use it to verify the Key Binding JWT.</t>
          <t indent="0" pn="section-4.3.2-3">Details of the validation process are defined in <xref target="verifier_verification" format="default" sectionFormat="of" derivedContent="Section 7.3"/>.</t>
        </section>
      </section>
    </section>
    <section anchor="main-example" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-example-sd-jwt">Example SD-JWT</name>
      <t indent="0" pn="section-5-1">In this example, a simple SD-JWT is demonstrated. This example is split into issuance and presentation.</t>
      <aside pn="section-5-2">
        <t indent="0" pn="section-5-2.1">Note: Throughout the examples in this document, line breaks were added to
JSON strings and base64-encoded strings to adhere to the line-length limit 
in RFCs and for readability. JSON does not allow line breaks within strings.</t>
      </aside>
      <section anchor="issuance" numbered="true" removeInRFC="false" toc="include" pn="section-5.1">
        <name slugifiedName="name-issuance">Issuance</name>
        <t indent="0" pn="section-5.1-1">The following data about the user comprises the input JWT Claims Set used by the Issuer:</t>
        <sourcecode type="json" markers="false" pn="section-5.1-2">
{
  "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"
  ]
}
</sourcecode>
        <t indent="0" pn="section-5.1-3">In this example, the following decisions were made by the Issuer in constructing the SD-JWT:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1-4">
          <li pn="section-5.1-4.1">The <tt>nationalities</tt> array is always visible, but its contents are selectively disclosable.</li>
          <li pn="section-5.1-4.2">The <tt>sub</tt> element as well as essential verification data (<tt>iss</tt>, <tt>exp</tt>, <tt>cnf</tt>, etc.) are always visible.</li>
          <li pn="section-5.1-4.3">All other claims are selectively disclosable.</li>
          <li pn="section-5.1-4.4">For <tt>address</tt>, the Issuer is using a flat structure, i.e., all the claims
in the <tt>address</tt> claim can only be disclosed in full. Other options are
discussed in <xref target="nested_data" format="default" sectionFormat="of" derivedContent="Section 6"/>.</li>
        </ul>
        <t indent="0" pn="section-5.1-5">The following payload is used for the SD-JWT:</t>
        <sourcecode type="json" markers="false" pn="section-5.1-6">
{
  "_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"
    }
  }
}
</sourcecode>
        <t indent="0" pn="section-5.1-7">The respective Disclosures, created by the Issuer, are listed below.
In the text below and in other locations in this specification,
the label "SHA-256 Hash:" is used as a shorthand for the label "Base64url-Encoded SHA-256 Hash:".</t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-5.1-8">
          <li pn="section-5.1-8.1">
            <t indent="0" pn="section-5.1-8.1.1">Claim <tt>given_name</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1-8.1.2">
              <li pn="section-5.1-8.1.2.1">
                <t indent="0" pn="section-5.1-8.1.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-5.1-8.1.2.1.2"><tt>jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4</tt></t>
              </li>
              <li pn="section-5.1-8.1.2.2">
                <t indent="0" pn="section-5.1-8.1.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-5.1-8.1.2.2.2"><tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9obiJd</tt></t>
              </li>
              <li pn="section-5.1-8.1.2.3">
                <t indent="0" pn="section-5.1-8.1.2.3.1">Contents:</t>
                <t indent="0" pn="section-5.1-8.1.2.3.2"><tt>["2GLC42sKQveCfGfryNRN9w", "given_name", "John"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-5.1-8.2">
            <t indent="0" pn="section-5.1-8.2.1">Claim <tt>family_name</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1-8.2.2">
              <li pn="section-5.1-8.2.2.1">
                <t indent="0" pn="section-5.1-8.2.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-5.1-8.2.2.1.2"><tt>TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo</tt></t>
              </li>
              <li pn="section-5.1-8.2.2.2">
                <t indent="0" pn="section-5.1-8.2.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-5.1-8.2.2.2.2"><tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIkRvZSJd</tt></t>
              </li>
              <li pn="section-5.1-8.2.2.3">
                <t indent="0" pn="section-5.1-8.2.2.3.1">Contents:</t>
                <t indent="0" pn="section-5.1-8.2.2.3.2"><tt>["eluV5Og3gSNII8EYnsxA_A", "family_name", "Doe"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-5.1-8.3">
            <t indent="0" pn="section-5.1-8.3.1">Claim <tt>email</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1-8.3.2">
              <li pn="section-5.1-8.3.2.1">
                <t indent="0" pn="section-5.1-8.3.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-5.1-8.3.2.1.2"><tt>JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYlSE</tt></t>
              </li>
              <li pn="section-5.1-8.3.2.2">
                <t indent="0" pn="section-5.1-8.3.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-5.1-8.3.2.2.2"><tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImVtYWlsIiwgImpvaG5kb2VAZXhhbXBsZS5jb20iXQ</tt></t>
              </li>
              <li pn="section-5.1-8.3.2.3">
                <t indent="0" pn="section-5.1-8.3.2.3.1">Contents:</t>
                <t indent="0" pn="section-5.1-8.3.2.3.2"><tt>["6Ij7tM-a5iVPGboS5tmvVA", "email", "johndoe@example.com"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-5.1-8.4">
            <t indent="0" pn="section-5.1-8.4.1">Claim <tt>phone_number</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1-8.4.2">
              <li pn="section-5.1-8.4.2.1">
                <t indent="0" pn="section-5.1-8.4.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-5.1-8.4.2.1.2"><tt>PorFbpKuVu6xymJagvkFsFXAbRoc2JGlAUA2BA4o7cI</tt></t>
              </li>
              <li pn="section-5.1-8.4.2.2">
                <t indent="0" pn="section-5.1-8.4.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-5.1-8.4.2.2.2"><tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInBob25lX251bWJlciIsICIrMS0yMDItNTU1LTAxMDEiXQ</tt></t>
              </li>
              <li pn="section-5.1-8.4.2.3">
                <t indent="0" pn="section-5.1-8.4.2.3.1">Contents:</t>
                <t indent="0" pn="section-5.1-8.4.2.3.2"><tt>["eI8ZWm9QnKPpNPeNenHdhQ", "phone_number", "+1-202-555-0101"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-5.1-8.5">
            <t indent="0" pn="section-5.1-8.5.1">Claim <tt>phone_number_verified</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1-8.5.2">
              <li pn="section-5.1-8.5.2.1">
                <t indent="0" pn="section-5.1-8.5.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-5.1-8.5.2.1.2"><tt>XQ_3kPKt1XyX7KANkqVR6yZ2Va5NrPIvPYbyMvRKBMM</tt></t>
              </li>
              <li pn="section-5.1-8.5.2.2">
                <t indent="0" pn="section-5.1-8.5.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-5.1-8.5.2.2.2"><tt>WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJlcl92ZXJpZmllZCIsIHRydWVd</tt></t>
              </li>
              <li pn="section-5.1-8.5.2.3">
                <t indent="0" pn="section-5.1-8.5.2.3.1">Contents:</t>
                <t indent="0" pn="section-5.1-8.5.2.3.2"><tt>["Qg_O64zqAxe412a108iroA", "phone_number_verified", true]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-5.1-8.6">
            <t indent="0" pn="section-5.1-8.6.1">Claim <tt>address</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1-8.6.2">
              <li pn="section-5.1-8.6.2.1">
                <t indent="0" pn="section-5.1-8.6.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-5.1-8.6.2.1.2"><tt>XzFrzwscM6Gn6CJDc6vVK8BkMnfG8vOSKfpPIZdAfdE</tt></t>
              </li>
              <li pn="section-5.1-8.6.2.2">
                <t indent="0" pn="section-5.1-8.6.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-5.1-8.6.2.2.2"><tt>WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImFkZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRvd24iLCAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0</tt></t>
              </li>
              <li pn="section-5.1-8.6.2.3">
                <t indent="0" pn="section-5.1-8.6.2.3.1">Contents:</t>
                <t indent="0" pn="section-5.1-8.6.2.3.2"><tt>["AJx-095VPrpTtN4QMOqROA", "address", {"street_address": "123 Main St", "locality": "Anytown", "region": "Anystate", "country": "US"}]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-5.1-8.7">
            <t indent="0" pn="section-5.1-8.7.1">Claim <tt>birthdate</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1-8.7.2">
              <li pn="section-5.1-8.7.2.1">
                <t indent="0" pn="section-5.1-8.7.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-5.1-8.7.2.1.2"><tt>gbOsI4Edq2x2Kw-w5wPEzakob9hV1cRD0ATN3oQL9JM</tt></t>
              </li>
              <li pn="section-5.1-8.7.2.2">
                <t indent="0" pn="section-5.1-8.7.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-5.1-8.7.2.2.2"><tt>WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImJpcnRoZGF0ZSIsICIxOTQwLTAxLTAxIl0</tt></t>
              </li>
              <li pn="section-5.1-8.7.2.3">
                <t indent="0" pn="section-5.1-8.7.2.3.1">Contents:</t>
                <t indent="0" pn="section-5.1-8.7.2.3.2"><tt>["Pc33JM2LchcU_lHggv_ufQ", "birthdate", "1940-01-01"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-5.1-8.8">
            <t indent="0" pn="section-5.1-8.8.1">Claim <tt>updated_at</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1-8.8.2">
              <li pn="section-5.1-8.8.2.1">
                <t indent="0" pn="section-5.1-8.8.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-5.1-8.8.2.1.2"><tt>CrQe7S5kqBAHt-nMYXgc6bdt2SH5aTY1sU_M-PgkjPI</tt></t>
              </li>
              <li pn="section-5.1-8.8.2.2">
                <t indent="0" pn="section-5.1-8.8.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-5.1-8.8.2.2.2"><tt>WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInVwZGF0ZWRfYXQiLCAxNTcwMDAwMDAwXQ</tt></t>
              </li>
              <li pn="section-5.1-8.8.2.3">
                <t indent="0" pn="section-5.1-8.8.2.3.1">Contents:</t>
                <t indent="0" pn="section-5.1-8.8.2.3.2"><tt>["G02NSrQfjFXQ7Io09syajA", "updated_at", 1570000000]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-5.1-8.9">
            <t indent="0" pn="section-5.1-8.9.1">Array Entry:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1-8.9.2">
              <li pn="section-5.1-8.9.2.1">
                <t indent="0" pn="section-5.1-8.9.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-5.1-8.9.2.1.2"><tt>pFndjkZ_VCzmyTa6UjlZo3dh-ko8aIKQc9DlGzhaVYo</tt></t>
              </li>
              <li pn="section-5.1-8.9.2.2">
                <t indent="0" pn="section-5.1-8.9.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-5.1-8.9.2.2.2"><tt>WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIlVTIl0</tt></t>
              </li>
              <li pn="section-5.1-8.9.2.3">
                <t indent="0" pn="section-5.1-8.9.2.3.1">Contents:</t>
                <t indent="0" pn="section-5.1-8.9.2.3.2"><tt>["lklxF5jMYlGTPUovMNIvCA", "US"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-5.1-8.10">
            <t indent="0" pn="section-5.1-8.10.1">Array Entry:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1-8.10.2">
              <li pn="section-5.1-8.10.2.1">
                <t indent="0" pn="section-5.1-8.10.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-5.1-8.10.2.1.2"><tt>7Cf6JkPudry3lcbwHgeZ8khAv1U1OSlerP0VkBJrWZ0</tt></t>
              </li>
              <li pn="section-5.1-8.10.2.2">
                <t indent="0" pn="section-5.1-8.10.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-5.1-8.10.2.2.2"><tt>WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIkRFIl0</tt></t>
              </li>
              <li pn="section-5.1-8.10.2.3">
                <t indent="0" pn="section-5.1-8.10.2.3.1">Contents:</t>
                <t indent="0" pn="section-5.1-8.10.2.3.2"><tt>["nPuoQnkRFq3BIeAm7AnXFA", "DE"]</tt></t>
              </li>
            </ul>
          </li>
        </ul>
        <t indent="0" pn="section-5.1-9">The payload is then signed by the Issuer to create the following Issuer-signed JWT:</t>
        <sourcecode type="" markers="false" pn="section-5.1-10">
eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb
IkNyUWU3UzVrcUJBSHQtbk1ZWGdjNmJkdDJTSDVhVFkxc1VfTS1QZ2tqUEkiLCAiSnpZ
akg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQWWxTRSIsICJQb3JGYnBL
dVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1
SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAiWFFfM2tQS3QxWHlYN0tB
TmtxVlI2eVoyVmE1TnJQSXZQWWJ5TXZSS0JNTSIsICJYekZyendzY002R242Q0pEYzZ2
Vks4QmtNbmZHOHZPU0tmcFBJWmRBZmRFIiwgImdiT3NJNEVkcTJ4Mkt3LXc1d1BFemFr
b2I5aFYxY1JEMEFUTjNvUUw5Sk0iLCAianN1OXlWdWx3UVFsaEZsTV8zSmx6TWFTRnpn
bGhRRzBEcGZheVF3TFVLNCJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu
Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAic3ViIjog
InVzZXJfNDIiLCAibmF0aW9uYWxpdGllcyI6IFt7Ii4uLiI6ICJwRm5kamtaX1ZDem15
VGE2VWpsWm8zZGgta284YUlLUWM5RGxHemhhVllvIn0sIHsiLi4uIjogIjdDZjZKa1B1
ZHJ5M2xjYndIZ2VaOGtoQXYxVTFPU2xlclAwVmtCSnJXWjAifV0sICJfc2RfYWxnIjog
InNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0y
NTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VH
ZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlG
MkhaUSJ9fX0.MczwjBFGtzf-6WMT-hIvYbkb11NrV1WMO-jTijpMPNbswNzZ87wY2uHz
-CXo6R04b7jYrpj9mNRAvVssXou1iw
</sourcecode>
        <t indent="0" pn="section-5.1-11">Adding the Disclosures produces the SD-JWT:</t>
        <sourcecode type="" markers="false" pn="section-5.1-12">
eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb
IkNyUWU3UzVrcUJBSHQtbk1ZWGdjNmJkdDJTSDVhVFkxc1VfTS1QZ2tqUEkiLCAiSnpZ
akg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQWWxTRSIsICJQb3JGYnBL
dVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1
SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAiWFFfM2tQS3QxWHlYN0tB
TmtxVlI2eVoyVmE1TnJQSXZQWWJ5TXZSS0JNTSIsICJYekZyendzY002R242Q0pEYzZ2
Vks4QmtNbmZHOHZPU0tmcFBJWmRBZmRFIiwgImdiT3NJNEVkcTJ4Mkt3LXc1d1BFemFr
b2I5aFYxY1JEMEFUTjNvUUw5Sk0iLCAianN1OXlWdWx3UVFsaEZsTV8zSmx6TWFTRnpn
bGhRRzBEcGZheVF3TFVLNCJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu
Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAic3ViIjog
InVzZXJfNDIiLCAibmF0aW9uYWxpdGllcyI6IFt7Ii4uLiI6ICJwRm5kamtaX1ZDem15
VGE2VWpsWm8zZGgta284YUlLUWM5RGxHemhhVllvIn0sIHsiLi4uIjogIjdDZjZKa1B1
ZHJ5M2xjYndIZ2VaOGtoQXYxVTFPU2xlclAwVmtCSnJXWjAifV0sICJfc2RfYWxnIjog
InNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0y
NTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VH
ZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlG
MkhaUSJ9fX0.MczwjBFGtzf-6WMT-hIvYbkb11NrV1WMO-jTijpMPNbswNzZ87wY2uHz
-CXo6R04b7jYrpj9mNRAvVssXou1iw~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgI
mdpdmVuX25hbWUiLCAiSm9obiJd~WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZh
bWlseV9uYW1lIiwgIkRvZSJd~WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImVtYWl
sIiwgImpvaG5kb2VAZXhhbXBsZS5jb20iXQ~WyJlSThaV205UW5LUHBOUGVOZW5IZGhR
IiwgInBob25lX251bWJlciIsICIrMS0yMDItNTU1LTAxMDEiXQ~WyJRZ19PNjR6cUF4Z
TQxMmExMDhpcm9BIiwgInBob25lX251bWJlcl92ZXJpZmllZCIsIHRydWVd~WyJBSngt
MDk1VlBycFR0TjRRTU9xUk9BIiwgImFkZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjog
IjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRvd24iLCAicmVnaW9uIjogIkFu
eXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0~WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZR
IiwgImJpcnRoZGF0ZSIsICIxOTQwLTAxLTAxIl0~WyJHMDJOU3JRZmpGWFE3SW8wOXN5
YWpBIiwgInVwZGF0ZWRfYXQiLCAxNTcwMDAwMDAwXQ~WyJsa2x4RjVqTVlsR1RQVW92T
U5JdkNBIiwgIlVTIl0~WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIkRFIl0~
</sourcecode>
      </section>
      <section anchor="presentation" numbered="true" removeInRFC="false" toc="include" pn="section-5.2">
        <name slugifiedName="name-presentation">Presentation</name>
        <t indent="0" pn="section-5.2-1">The following non-normative example shows an SD-JWT+KB as
it would be sent from the Holder to the Verifier. Note that it consists of six
tilde-separated parts, with the Issuer-signed JWT as shown above in the beginning,
four Disclosures (for the claims <tt>given_name</tt>, <tt>family_name</tt>, <tt>address</tt>, and one of the
<tt>nationalities</tt>) in the middle, and the Key Binding JWT as the last element.</t>
        <sourcecode type="" markers="false" pn="section-5.2-2">
eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb
IkNyUWU3UzVrcUJBSHQtbk1ZWGdjNmJkdDJTSDVhVFkxc1VfTS1QZ2tqUEkiLCAiSnpZ
akg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQWWxTRSIsICJQb3JGYnBL
dVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1
SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAiWFFfM2tQS3QxWHlYN0tB
TmtxVlI2eVoyVmE1TnJQSXZQWWJ5TXZSS0JNTSIsICJYekZyendzY002R242Q0pEYzZ2
Vks4QmtNbmZHOHZPU0tmcFBJWmRBZmRFIiwgImdiT3NJNEVkcTJ4Mkt3LXc1d1BFemFr
b2I5aFYxY1JEMEFUTjNvUUw5Sk0iLCAianN1OXlWdWx3UVFsaEZsTV8zSmx6TWFTRnpn
bGhRRzBEcGZheVF3TFVLNCJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu
Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAic3ViIjog
InVzZXJfNDIiLCAibmF0aW9uYWxpdGllcyI6IFt7Ii4uLiI6ICJwRm5kamtaX1ZDem15
VGE2VWpsWm8zZGgta284YUlLUWM5RGxHemhhVllvIn0sIHsiLi4uIjogIjdDZjZKa1B1
ZHJ5M2xjYndIZ2VaOGtoQXYxVTFPU2xlclAwVmtCSnJXWjAifV0sICJfc2RfYWxnIjog
InNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0y
NTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VH
ZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlG
MkhaUSJ9fX0.MczwjBFGtzf-6WMT-hIvYbkb11NrV1WMO-jTijpMPNbswNzZ87wY2uHz
-CXo6R04b7jYrpj9mNRAvVssXou1iw~WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgI
mZhbWlseV9uYW1lIiwgIkRvZSJd~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImFk
ZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5
IjogIkFueXRvd24iLCAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMi
fV0~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9obiJd
~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIlVTIl0~eyJhbGciOiAiRVMyNTYiLCA
idHlwIjogImtiK2p3dCJ9.eyJub25jZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodH
RwczovL3ZlcmlmaWVyLmV4YW1wbGUub3JnIiwgImlhdCI6IDE3NDg1MzcyNDQsICJzZF
9oYXNoIjogIjBfQWYtMkItRWhMV1g1eWRoX3cyeHp3bU82aU02NkJfMlFDRWFuSTRmVV
kifQ.T3SIus2OidNl41nmVkTZVCKKhOAX97aOldMyHFiYjHm261eLiJ1YiuONFiMN8Ql
CmYzDlBLAdPvrXh52KaLgUQ
</sourcecode>
        <t indent="0" pn="section-5.2-3">The following Key Binding JWT payload was created and signed for this presentation by the Holder:</t>
        <sourcecode type="json" markers="false" pn="section-5.2-4">
{
  "nonce": "1234567890",
  "aud": "https://verifier.example.org",
  "iat": 1748537244,
  "sd_hash": "0_Af-2B-EhLWX5ydh_w2xzwmO6iM66B_2QCEanI4fUY"
}
</sourcecode>
        <t indent="0" pn="section-5.2-5">If the Verifier did not require Key Binding, then the Holder could have
presented the SD-JWT with selected Disclosures directly, instead of encapsulating it in
an SD-JWT+KB.</t>
        <t indent="0" pn="section-5.2-6">After validation, the Verifier will have the following Processed SD-JWT Payload available for further handling:</t>
        <sourcecode type="json" markers="false" pn="section-5.2-7">
{
  "iss": "https://issuer.example.com",
  "iat": 1683000000,
  "exp": 1883000000,
  "sub": "user_42",
  "nationalities": [
    "US"
  ],
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
      "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
    }
  },
  "family_name": "Doe",
  "address": {
    "street_address": "123 Main St",
    "locality": "Anytown",
    "region": "Anystate",
    "country": "US"
  },
  "given_name": "John"
}
</sourcecode>
      </section>
    </section>
    <section anchor="nested_data" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-considerations-on-nested-da">Considerations on Nested Data in SD-JWTs</name>
      <t indent="0" pn="section-6-1">Being JSON, an object in an SD-JWT payload <bcp14>MAY</bcp14> contain name/value pairs where the value is another object or objects <bcp14>MAY</bcp14> be elements in arrays. In SD-JWT, the Issuer decides for each claim individually, on each level of the JSON, whether or not the claim should be selectively disclosable. This choice can be made on each level independent of whether keys higher in the hierarchy are selectively disclosable.</t>
      <t indent="0" pn="section-6-2">From this it follows that the <tt>_sd</tt> key containing digests <bcp14>MAY</bcp14> appear multiple
times in an SD-JWT, and likewise, there <bcp14>MAY</bcp14> be multiple arrays within the
hierarchy with each having selectively disclosable elements. Digests of
selectively disclosable claims <bcp14>MAY</bcp14> even appear within other Disclosures.</t>
      <t indent="0" pn="section-6-3">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 operating environment requirements. For more examples with nested structures, see Appendices <xref target="example-simple_structured" format="counter" sectionFormat="of" derivedContent="A.1"/> and <xref target="example-complex-structured-sd-jwt" format="counter" sectionFormat="of" derivedContent="A.2"/>.</t>
      <t indent="0" pn="section-6-4">The following input JWT Claims Set is used as an example throughout this section:</t>
      <sourcecode type="json" markers="false" pn="section-6-5">
{
  "sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c",
  "address": {
    "street_address": "Schulstr. 12",
    "locality": "Schulpforta",
    "region": "Sachsen-Anhalt",
    "country": "DE"
  }
}
</sourcecode>
      <aside pn="section-6-6">
        <t indent="0" pn="section-6-6.1">Note: 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 <tt>address</tt> claim can be represented in an SD-JWT.</t>
      </aside>
      <section anchor="example-flat-sd-jwt" numbered="true" removeInRFC="false" toc="include" pn="section-6.1">
        <name slugifiedName="name-example-flat-sd-jwt">Example: Flat SD-JWT</name>
        <t indent="0" pn="section-6.1-1">The Issuer can decide to treat the <tt>address</tt> claim as a block that can either be disclosed completely or not at all. The following example shows that in this case, the entire <tt>address</tt> claim is treated as an object in the Disclosure.</t>
        <sourcecode type="json" markers="false" pn="section-6.1-2">
{
  "_sd": [
    "fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do"
  ],
  "iss": "https://issuer.example.com",
  "iat": 1683000000,
  "exp": 1883000000,
  "sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c",
  "_sd_alg": "sha-256"
}
</sourcecode>
        <t indent="0" pn="section-6.1-3">The Issuer would create the following Disclosure referenced by the one hash in the SD-JWT:</t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-6.1-4">
          <li pn="section-6.1-4.1">
            <t indent="0" pn="section-6.1-4.1.1">Claim <tt>address</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.1-4.1.2">
              <li pn="section-6.1-4.1.2.1">
                <t indent="0" pn="section-6.1-4.1.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-6.1-4.1.2.1.2"><tt>fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do</tt></t>
              </li>
              <li pn="section-6.1-4.1.2.2">
                <t indent="0" pn="section-6.1-4.1.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-6.1-4.1.2.2.2"><tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImFkZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjogIlNjaHVsc3RyLiAxMiIsICJsb2NhbGl0eSI6ICJTY2h1bHBmb3J0YSIsICJyZWdpb24iOiAiU2FjaHNlbi1BbmhhbHQiLCAiY291bnRyeSI6ICJERSJ9XQ</tt></t>
              </li>
              <li pn="section-6.1-4.1.2.3">
                <t indent="0" pn="section-6.1-4.1.2.3.1">Contents:</t>
                <t indent="0" pn="section-6.1-4.1.2.3.2"><tt>["2GLC42sKQveCfGfryNRN9w", "address", {"street_address": "Schulstr. 12", "locality": "Schulpforta", "region": "Sachsen-Anhalt", "country": "DE"}]</tt></t>
              </li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="example-structured-sd-jwt" numbered="true" removeInRFC="false" toc="include" pn="section-6.2">
        <name slugifiedName="name-example-structured-sd-jwt">Example: Structured SD-JWT</name>
        <t indent="0" pn="section-6.2-1">The Issuer may instead decide to make the <tt>address</tt> claim contents selectively disclosable individually:</t>
        <sourcecode type="json" markers="false" pn="section-6.2-2">
{
  "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"
}
</sourcecode>
        <t indent="0" pn="section-6.2-3">In this case, the Issuer would use the following data in the Disclosures for the <tt>address</tt> sub-claims:</t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-6.2-4">
          <li pn="section-6.2-4.1">
            <t indent="0" pn="section-6.2-4.1.1">Claim <tt>street_address</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.2-4.1.2">
              <li pn="section-6.2-4.1.2.1">
                <t indent="0" pn="section-6.2-4.1.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-6.2-4.1.2.1.2"><tt>9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM</tt></t>
              </li>
              <li pn="section-6.2-4.1.2.2">
                <t indent="0" pn="section-6.2-4.1.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-6.2-4.1.2.2.2"><tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN0cmVldF9hZGRyZXNzIiwgIlNjaHVsc3RyLiAxMiJd</tt></t>
              </li>
              <li pn="section-6.2-4.1.2.3">
                <t indent="0" pn="section-6.2-4.1.2.3.1">Contents:</t>
                <t indent="0" pn="section-6.2-4.1.2.3.2"><tt>["2GLC42sKQveCfGfryNRN9w", "street_address", "Schulstr. 12"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-6.2-4.2">
            <t indent="0" pn="section-6.2-4.2.1">Claim <tt>locality</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.2-4.2.2">
              <li pn="section-6.2-4.2.2.1">
                <t indent="0" pn="section-6.2-4.2.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-6.2-4.2.2.1.2"><tt>6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0</tt></t>
              </li>
              <li pn="section-6.2-4.2.2.2">
                <t indent="0" pn="section-6.2-4.2.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-6.2-4.2.2.2.2"><tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImxvY2FsaXR5IiwgIlNjaHVscGZvcnRhIl0</tt></t>
              </li>
              <li pn="section-6.2-4.2.2.3">
                <t indent="0" pn="section-6.2-4.2.2.3.1">Contents:</t>
                <t indent="0" pn="section-6.2-4.2.2.3.2"><tt>["eluV5Og3gSNII8EYnsxA_A", "locality", "Schulpforta"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-6.2-4.3">
            <t indent="0" pn="section-6.2-4.3.1">Claim <tt>region</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.2-4.3.2">
              <li pn="section-6.2-4.3.2.1">
                <t indent="0" pn="section-6.2-4.3.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-6.2-4.3.2.1.2"><tt>KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88</tt></t>
              </li>
              <li pn="section-6.2-4.3.2.2">
                <t indent="0" pn="section-6.2-4.3.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-6.2-4.3.2.2.2"><tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInJlZ2lvbiIsICJTYWNoc2VuLUFuaGFsdCJd</tt></t>
              </li>
              <li pn="section-6.2-4.3.2.3">
                <t indent="0" pn="section-6.2-4.3.2.3.1">Contents:</t>
                <t indent="0" pn="section-6.2-4.3.2.3.2"><tt>["6Ij7tM-a5iVPGboS5tmvVA", "region", "Sachsen-Anhalt"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-6.2-4.4">
            <t indent="0" pn="section-6.2-4.4.1">Claim <tt>country</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.2-4.4.2">
              <li pn="section-6.2-4.4.2.1">
                <t indent="0" pn="section-6.2-4.4.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-6.2-4.4.2.1.2"><tt>WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM</tt></t>
              </li>
              <li pn="section-6.2-4.4.2.2">
                <t indent="0" pn="section-6.2-4.4.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-6.2-4.4.2.2.2"><tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImNvdW50cnkiLCAiREUiXQ</tt></t>
              </li>
              <li pn="section-6.2-4.4.2.3">
                <t indent="0" pn="section-6.2-4.4.2.3.1">Contents:</t>
                <t indent="0" pn="section-6.2-4.4.2.3.2"><tt>["eI8ZWm9QnKPpNPeNenHdhQ", "country", "DE"]</tt></t>
              </li>
            </ul>
          </li>
        </ul>
        <t indent="0" pn="section-6.2-5">The Issuer may also make one sub-claim of <tt>address</tt> permanently disclosed and hide only the other sub-claims:</t>
        <sourcecode type="json" markers="false" pn="section-6.2-6">
{
  "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"
}
</sourcecode>
        <t indent="0" pn="section-6.2-7">In this case, there would be no Disclosure for <tt>country</tt>, since it is provided in the clear.</t>
      </section>
      <section anchor="example-sd-jwt-with-recursive-disclosures" numbered="true" removeInRFC="false" toc="include" pn="section-6.3">
        <name slugifiedName="name-example-sd-jwt-with-recursi">Example: SD-JWT with Recursive Disclosures</name>
        <t indent="0" pn="section-6.3-1">The Issuer may also decide to make the <tt>address</tt> claim contents selectively disclosable recursively, i.e., the <tt>address</tt> claim is made selectively disclosable as well as its sub-claims:</t>
        <sourcecode type="json" markers="false" pn="section-6.3-2">
{
  "_sd": [
    "HvrKX6fPV0v9K_yCVFBiLFHsMaxcD_114Em6VT8x1lg"
  ],
  "iss": "https://issuer.example.com",
  "iat": 1683000000,
  "exp": 1883000000,
  "sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c",
  "_sd_alg": "sha-256"
}
</sourcecode>
        <t indent="0" pn="section-6.3-3">The Issuer first creates Disclosures for the sub-claims and then includes their digests in the Disclosure for the <tt>address</tt> claim:</t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-6.3-4">
          <li pn="section-6.3-4.1">
            <t indent="0" pn="section-6.3-4.1.1">Claim <tt>street_address</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.3-4.1.2">
              <li pn="section-6.3-4.1.2.1">
                <t indent="0" pn="section-6.3-4.1.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-6.3-4.1.2.1.2"><tt>9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM</tt></t>
              </li>
              <li pn="section-6.3-4.1.2.2">
                <t indent="0" pn="section-6.3-4.1.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-6.3-4.1.2.2.2"><tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN0cmVldF9hZGRyZXNzIiwgIlNjaHVsc3RyLiAxMiJd</tt></t>
              </li>
              <li pn="section-6.3-4.1.2.3">
                <t indent="0" pn="section-6.3-4.1.2.3.1">Contents:</t>
                <t indent="0" pn="section-6.3-4.1.2.3.2"><tt>["2GLC42sKQveCfGfryNRN9w", "street_address", "Schulstr. 12"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-6.3-4.2">
            <t indent="0" pn="section-6.3-4.2.1">Claim <tt>locality</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.3-4.2.2">
              <li pn="section-6.3-4.2.2.1">
                <t indent="0" pn="section-6.3-4.2.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-6.3-4.2.2.1.2"><tt>6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0</tt></t>
              </li>
              <li pn="section-6.3-4.2.2.2">
                <t indent="0" pn="section-6.3-4.2.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-6.3-4.2.2.2.2"><tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImxvY2FsaXR5IiwgIlNjaHVscGZvcnRhIl0</tt></t>
              </li>
              <li pn="section-6.3-4.2.2.3">
                <t indent="0" pn="section-6.3-4.2.2.3.1">Contents:</t>
                <t indent="0" pn="section-6.3-4.2.2.3.2"><tt>["eluV5Og3gSNII8EYnsxA_A", "locality", "Schulpforta"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-6.3-4.3">
            <t indent="0" pn="section-6.3-4.3.1">Claim <tt>region</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.3-4.3.2">
              <li pn="section-6.3-4.3.2.1">
                <t indent="0" pn="section-6.3-4.3.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-6.3-4.3.2.1.2"><tt>KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88</tt></t>
              </li>
              <li pn="section-6.3-4.3.2.2">
                <t indent="0" pn="section-6.3-4.3.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-6.3-4.3.2.2.2"><tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInJlZ2lvbiIsICJTYWNoc2VuLUFuaGFsdCJd</tt></t>
              </li>
              <li pn="section-6.3-4.3.2.3">
                <t indent="0" pn="section-6.3-4.3.2.3.1">Contents:</t>
                <t indent="0" pn="section-6.3-4.3.2.3.2"><tt>["6Ij7tM-a5iVPGboS5tmvVA", "region", "Sachsen-Anhalt"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-6.3-4.4">
            <t indent="0" pn="section-6.3-4.4.1">Claim <tt>country</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.3-4.4.2">
              <li pn="section-6.3-4.4.2.1">
                <t indent="0" pn="section-6.3-4.4.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-6.3-4.4.2.1.2"><tt>WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM</tt></t>
              </li>
              <li pn="section-6.3-4.4.2.2">
                <t indent="0" pn="section-6.3-4.4.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-6.3-4.4.2.2.2"><tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImNvdW50cnkiLCAiREUiXQ</tt></t>
              </li>
              <li pn="section-6.3-4.4.2.3">
                <t indent="0" pn="section-6.3-4.4.2.3.1">Contents:</t>
                <t indent="0" pn="section-6.3-4.4.2.3.2"><tt>["eI8ZWm9QnKPpNPeNenHdhQ", "country", "DE"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-6.3-4.5">
            <t indent="0" pn="section-6.3-4.5.1">Claim <tt>address</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.3-4.5.2">
              <li pn="section-6.3-4.5.2.1">
                <t indent="0" pn="section-6.3-4.5.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-6.3-4.5.2.1.2"><tt>HvrKX6fPV0v9K_yCVFBiLFHsMaxcD_114Em6VT8x1lg</tt></t>
              </li>
              <li pn="section-6.3-4.5.2.2">
                <t indent="0" pn="section-6.3-4.5.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-6.3-4.5.2.2.2"><tt>WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImFkZHJlc3MiLCB7Il9zZCI6IFsiNnZoOWJxLXpTNEdLTV83R3BnZ1ZiWXp6dTZvT0dYcm1OVkdQSFA3NVVkMCIsICI5Z2pWdVh0ZEZST0NnUnJ0TmNHVVhtRjY1cmRlemlfNkVyX2o3NmttWXlNIiwgIktVUkRQaDRaQzE5LTN0aXotRGYzOVY4ZWlkeTFvVjNhM0gxRGEyTjBnODgiLCAiV045cjlkQ0JKOEhUQ3NTMmpLQVN4VGpFeVc1bTV4NjVfWl8ycm8yamZYTSJdfV0</tt></t>
              </li>
              <li pn="section-6.3-4.5.2.3">
                <t indent="0" pn="section-6.3-4.5.2.3.1">Contents:</t>
                <t indent="0" pn="section-6.3-4.5.2.3.2"><tt>["Qg_O64zqAxe412a108iroA", "address", {"_sd": ["6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0", "9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM", "KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88", "WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM"]}]</tt></t>
              </li>
            </ul>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="verification-1" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-verification-and-processing">Verification and Processing</name>
      <section anchor="sd_jwt_verification" numbered="true" removeInRFC="false" toc="include" pn="section-7.1">
        <name slugifiedName="name-verification-of-the-sd-jwt">Verification of the SD-JWT</name>
        <t indent="0" pn="section-7.1-1">Upon receiving an SD-JWT, either directly or as a component of an SD-JWT+KB, a Holder
or Verifier needs to ensure that:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7.1-2">
          <li pn="section-7.1-2.1">the Issuer-signed JWT is valid, and</li>
          <li pn="section-7.1-2.2">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).</li>
        </ul>
        <t indent="0" pn="section-7.1-3">The Holder or the Verifier <bcp14>MUST</bcp14> perform the following checks when receiving
an SD-JWT to validate the SD-JWT and extract the payload:</t>
        <ol type="1" spacing="normal" indent="adaptive" start="1" pn="section-7.1-4">
<li pn="section-7.1-4.1" derivedCounter="1.">Separate the SD-JWT into the Issuer-signed JWT and the Disclosures (if any).</li>
          <li pn="section-7.1-4.2" derivedCounter="2.">
            <t indent="0" pn="section-7.1-4.2.1">Validate the Issuer-signed JWT:</t>
            <ol type="a" spacing="normal" indent="adaptive" start="1" pn="section-7.1-4.2.2">
<li pn="section-7.1-4.2.2.1" derivedCounter="a.">Ensure that the used signing algorithm was deemed secure for the application. Refer to <xref target="RFC8725" format="default" sectionFormat="of" derivedContent="RFC8725"/>, Sections <xref target="RFC8725" section="3.1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8725#section-3.1" derivedContent="RFC8725"/> and <xref target="RFC8725" section="3.2" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8725#section-3.2" derivedContent="RFC8725"/> for details. The "none" algorithm <bcp14>MUST NOT</bcp14> be accepted.</li>
              <li pn="section-7.1-4.2.2.2" derivedCounter="b.">Validate the signature over the Issuer-signed JWT per <xref target="RFC7515" section="5.2" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc7515#section-5.2" derivedContent="RFC7515"/>.</li>
              <li pn="section-7.1-4.2.2.3" derivedCounter="c.">Validate the Issuer and that the signing key belongs to this Issuer.</li>
              <li pn="section-7.1-4.2.2.4" derivedCounter="d.">Check that the <tt>_sd_alg</tt> claim value is understood and the hash algorithm is deemed secure according to the Holder or Verifier's policy (see <xref target="hash_function_claim" format="default" sectionFormat="of" derivedContent="Section 4.1.1"/>).</li>
            </ol>
          </li>
          <li pn="section-7.1-4.3" derivedCounter="3.">
            <t indent="0" pn="section-7.1-4.3.1">Process the Disclosures and embedded digests in the Issuer-signed JWT as follows:</t>
            <ol type="a" spacing="normal" indent="adaptive" start="1" pn="section-7.1-4.3.2">
<li pn="section-7.1-4.3.2.1" derivedCounter="a.">
                <t indent="0" pn="section-7.1-4.3.2.1.1">For each Disclosure provided:</t>
                <ol type="i" spacing="normal" indent="adaptive" start="1" pn="section-7.1-4.3.2.1.2">
<li pn="section-7.1-4.3.2.1.2.1" derivedCounter="i.">Calculate the digest over the base64url-encoded string as described in <xref target="hashing_disclosures" format="default" sectionFormat="of" derivedContent="Section 4.2.3"/>.</li>
                </ol>
              </li>
              <li pn="section-7.1-4.3.2.2" derivedCounter="b.">
                <t indent="0" pn="section-7.1-4.3.2.2.1">(*) Identify all embedded digests in the Issuer-signed JWT as follows:</t>
                <ol type="i" spacing="normal" indent="adaptive" start="1" pn="section-7.1-4.3.2.2.2">
<li pn="section-7.1-4.3.2.2.2.1" derivedCounter="i.">Find all objects having an <tt>_sd</tt> key that refers to an array of strings.</li>
                  <li pn="section-7.1-4.3.2.2.2.2" derivedCounter="ii.">Find all array elements that are objects with one key, that key being <tt>...</tt> and referring to a string.</li>
                </ol>
              </li>
              <li pn="section-7.1-4.3.2.3" derivedCounter="c.">
                <t indent="0" pn="section-7.1-4.3.2.3.1">(**) For each embedded digest found in the previous step:</t>
                <ol type="i" spacing="normal" indent="adaptive" start="1" pn="section-7.1-4.3.2.3.2">
<li pn="section-7.1-4.3.2.3.2.1" derivedCounter="i.">Compare the value with the digests calculated previously and find the matching Disclosure. If no such Disclosure can be found, the digest <bcp14>MUST</bcp14> be ignored.</li>
                  <li pn="section-7.1-4.3.2.3.2.2" derivedCounter="ii.">
                    <t indent="0" pn="section-7.1-4.3.2.3.2.2.1">If the digest was found in an object's <tt>_sd</tt> key:</t>
                    <ol type="1" spacing="normal" indent="adaptive" start="1" pn="section-7.1-4.3.2.3.2.2.2">
<li pn="section-7.1-4.3.2.3.2.2.2.1" derivedCounter="1.">If the contents of the respective Disclosure is not a JSON array of three elements (salt, claim name, claim value), the SD-JWT <bcp14>MUST</bcp14> be rejected.</li>
                      <li pn="section-7.1-4.3.2.3.2.2.2.2" derivedCounter="2.">If the claim name is <tt>_sd</tt> or <tt>...</tt>, the SD-JWT <bcp14>MUST</bcp14> be rejected.</li>
                      <li pn="section-7.1-4.3.2.3.2.2.2.3" derivedCounter="3.">If the claim name already exists at the level of the <tt>_sd</tt> key, the SD-JWT <bcp14>MUST</bcp14> be rejected.</li>
                      <li pn="section-7.1-4.3.2.3.2.2.2.4" derivedCounter="4.">Insert, at the level of the <tt>_sd</tt> key, a new claim using the claim name and claim value from the Disclosure.</li>
                      <li pn="section-7.1-4.3.2.3.2.2.2.5" derivedCounter="5.">Recursively process the value using the steps described in (*) and (**).</li>
                    </ol>
                  </li>
                  <li pn="section-7.1-4.3.2.3.2.3" derivedCounter="iii.">
                    <t indent="0" pn="section-7.1-4.3.2.3.2.3.1">If the digest was found in an array element:</t>
                    <ol type="1" spacing="normal" indent="adaptive" start="1" pn="section-7.1-4.3.2.3.2.3.2">
<li pn="section-7.1-4.3.2.3.2.3.2.1" derivedCounter="1.">If the contents of the respective Disclosure is not a JSON array of two elements (salt, value), the SD-JWT <bcp14>MUST</bcp14> be rejected.</li>
                      <li pn="section-7.1-4.3.2.3.2.3.2.2" derivedCounter="2.">Replace the array element with the value from the Disclosure.</li>
                      <li pn="section-7.1-4.3.2.3.2.3.2.3" derivedCounter="3.">Recursively process the value using the steps described in (*) and (**).</li>
                    </ol>
                  </li>
                </ol>
              </li>
              <li pn="section-7.1-4.3.2.4" derivedCounter="d.">Remove all array elements for which the digest was not found in the previous step.</li>
              <li pn="section-7.1-4.3.2.5" derivedCounter="e.">Remove all <tt>_sd</tt> keys and their contents from the Issuer-signed JWT payload. If this results in an object with no properties, it should be represented as an empty object <tt>{}</tt>.</li>
              <li pn="section-7.1-4.3.2.6" derivedCounter="f.">Remove the claim <tt>_sd_alg</tt> from the SD-JWT payload.</li>
            </ol>
          </li>
          <li pn="section-7.1-4.4" derivedCounter="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 <bcp14>MUST</bcp14> be rejected.</li>
          <li pn="section-7.1-4.5" derivedCounter="5.">If any Disclosure was not referenced by digest value in the Issuer-signed JWT (directly or recursively via other Disclosures), the SD-JWT <bcp14>MUST</bcp14> be rejected.</li>
          <li pn="section-7.1-4.6" derivedCounter="6.">Check that the SD-JWT is valid using claims such as <tt>nbf</tt>, <tt>exp</tt>, and <tt>aud</tt> in the processed payload, if present. If a required validity-controlling claim is missing (see <xref target="sd-validity-claims" format="default" sectionFormat="of" derivedContent="Section 9.7"/>), the SD-JWT <bcp14>MUST</bcp14> be rejected.</li>
        </ol>
        <t indent="0" pn="section-7.1-5">If any step fails, the SD-JWT is not valid, and processing <bcp14>MUST</bcp14> be aborted. Otherwise, the JSON document resulting from the preceding processing and verification steps, herein referred to as the "Processed SD-JWT Payload", can be made available to the application to be used for its intended purpose.</t>
        <aside pn="section-7.1-6">
          <t indent="0" pn="section-7.1-6.1">Note that these processing steps do not yield any guarantees to the Holder about having received a complete set of Disclosures. That is, for some digest values in the Issuer-signed JWT (which are not decoy digests), there may be no corresponding Disclosures, for example, if the message from the Issuer was truncated.
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 user when needed.</t>
        </aside>
      </section>
      <section anchor="holder_verification" numbered="true" removeInRFC="false" toc="include" pn="section-7.2">
        <name slugifiedName="name-processing-by-the-holder">Processing by the Holder</name>
        <t indent="0" pn="section-7.2-1">The Issuer provides the Holder with an SD-JWT, not an SD-JWT+KB.  If the Holder
receives an SD-JWT+KB, it <bcp14>MUST</bcp14> be rejected.</t>
        <t indent="0" pn="section-7.2-2">When receiving an SD-JWT, the Holder <bcp14>MUST</bcp14> do the following:</t>
        <ol type="1" spacing="normal" indent="adaptive" start="1" pn="section-7.2-3">
<li pn="section-7.2-3.1" derivedCounter="1.">Process the SD-JWT as defined in <xref target="sd_jwt_verification" format="default" sectionFormat="of" derivedContent="Section 7.1"/> to validate it and extract the payload.</li>
          <li pn="section-7.2-3.2" derivedCounter="2.">Ensure that the contents of claims in the payload are acceptable (depending on the application; for example, check that any values the Holder can check are correct).</li>
        </ol>
        <t indent="0" pn="section-7.2-4">For presentation to a Verifier, the Holder <bcp14>MUST</bcp14> perform the following (or equivalent) steps (in addition to the checks described in <xref target="sd_jwt_verification" format="default" sectionFormat="of" derivedContent="Section 7.1"/> performed after receiving the SD-JWT):</t>
        <ol type="1" spacing="normal" indent="adaptive" start="1" pn="section-7.2-5">
<li pn="section-7.2-5.1" derivedCounter="1.">Decide which Disclosures to release to the Verifier, obtaining consent if necessary (note that if and how consent is attained is out of scope for this document).</li>
          <li pn="section-7.2-5.2" derivedCounter="2.">
            <t indent="0" pn="section-7.2-5.2.1">Verify that each selected Disclosure satisfies one of the two following conditions:</t>
            <ol type="a" spacing="normal" indent="adaptive" start="1" pn="section-7.2-5.2.2">
<li pn="section-7.2-5.2.2.1" derivedCounter="a.">The hash of the Disclosure is contained in the Issuer-signed JWT claims.</li>
              <li pn="section-7.2-5.2.2.2" derivedCounter="b.">The hash of the Disclosure is contained in the claim value of another selected Disclosure.</li>
            </ol>
          </li>
          <li pn="section-7.2-5.3" derivedCounter="3.">Assemble the SD-JWT, including the Issuer-signed JWT and the selected Disclosures (see <xref target="data_formats" format="default" sectionFormat="of" derivedContent="Section 4"/> for the format).</li>
          <li pn="section-7.2-5.4" derivedCounter="4.">
            <t indent="0" pn="section-7.2-5.4.1">If Key Binding is not required:</t>
            <ol type="a" spacing="normal" indent="adaptive" start="1" pn="section-7.2-5.4.2">
<li pn="section-7.2-5.4.2.1" derivedCounter="a.">Send the SD-JWT to the Verifier.</li>
            </ol>
          </li>
          <li pn="section-7.2-5.5" derivedCounter="5.">
            <t indent="0" pn="section-7.2-5.5.1">If Key Binding is required:</t>
            <ol type="a" spacing="normal" indent="adaptive" start="1" pn="section-7.2-5.5.2">
<li pn="section-7.2-5.5.2.1" derivedCounter="a.">Create a Key Binding JWT tied to the SD-JWT.</li>
              <li pn="section-7.2-5.5.2.2" derivedCounter="b.">Assemble the SD-JWT+KB by concatenating the SD-JWT and the Key Binding JWT.</li>
              <li pn="section-7.2-5.5.2.3" derivedCounter="c.">Send the SD-JWT+KB to the Verifier.</li>
            </ol>
          </li>
        </ol>
      </section>
      <section anchor="verifier_verification" numbered="true" removeInRFC="false" toc="include" pn="section-7.3">
        <name slugifiedName="name-verification-by-the-verifie">Verification by the Verifier</name>
        <t indent="0" pn="section-7.3-1">Upon receiving a presentation from a Holder, in the form of either an SD-JWT or
an SD-JWT+KB, in addition to the checks described in <xref target="sd_jwt_verification" format="default" sectionFormat="of" derivedContent="Section 7.1"/>, Verifiers need to ensure that</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7.3-2">
          <li pn="section-7.3-2.1">if Key Binding is required, then the Holder has provided an SD-JWT+KB, and</li>
          <li pn="section-7.3-2.2">the Key Binding JWT is signed by the Holder and valid.</li>
        </ul>
        <t indent="0" pn="section-7.3-3">To this end, Verifiers <bcp14>MUST</bcp14> follow the following steps (or equivalent):</t>
        <ol type="1" spacing="normal" indent="adaptive" start="1" pn="section-7.3-4">
<li pn="section-7.3-4.1" derivedCounter="1.">Determine if Key Binding is to be checked according to the Verifier's policy
for the use case at hand. This decision <bcp14>MUST NOT</bcp14> be based on whether
or not a Key Binding JWT is provided by the Holder. Refer to <xref target="key_binding_security" format="default" sectionFormat="of" derivedContent="Section 9.5"/> for
details.</li>
          <li pn="section-7.3-4.2" derivedCounter="2.">If Key Binding is required and the Holder has provided an SD-JWT (without Key Binding), the Verifier <bcp14>MUST</bcp14> reject the presentation.</li>
          <li pn="section-7.3-4.3" derivedCounter="3.">If the Holder has provided an SD-JWT+KB, parse it into an SD-JWT and a Key Binding JWT.</li>
          <li pn="section-7.3-4.4" derivedCounter="4.">Process the SD-JWT as defined in <xref target="sd_jwt_verification" format="default" sectionFormat="of" derivedContent="Section 7.1"/> to validate the presentation and extract the payload.</li>
          <li pn="section-7.3-4.5" derivedCounter="5.">
            <t indent="0" pn="section-7.3-4.5.1">If Key Binding is required:</t>
            <ol type="a" spacing="normal" indent="adaptive" start="1" pn="section-7.3-4.5.2">
<li pn="section-7.3-4.5.2.1" derivedCounter="a.">Determine the public key for the Holder from the SD-JWT (see <xref target="key_binding" format="default" sectionFormat="of" derivedContent="Section 4.1.2"/>).</li>
              <li pn="section-7.3-4.5.2.2" derivedCounter="b.">Ensure that a signing algorithm was used that was deemed secure for the application. Refer to <xref target="RFC8725" format="default" sectionFormat="of" derivedContent="RFC8725"/>, Sections <xref target="RFC8725" section="3.1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8725#section-3.1" derivedContent="RFC8725"/> and <xref target="RFC8725" section="3.2" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8725#section-3.2" derivedContent="RFC8725"/> for details. The "none" algorithm <bcp14>MUST NOT</bcp14> be accepted.</li>
              <li pn="section-7.3-4.5.2.3" derivedCounter="c.">Validate the signature over the Key Binding JWT per <xref target="RFC7515" section="5.2" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc7515#section-5.2" derivedContent="RFC7515"/>.</li>
              <li pn="section-7.3-4.5.2.4" derivedCounter="d.">Check that the <tt>typ</tt> of the Key Binding JWT is <tt>kb+jwt</tt> (see <xref target="kb-jwt" format="default" sectionFormat="of" derivedContent="Section 4.3"/>).</li>
              <li pn="section-7.3-4.5.2.5" derivedCounter="e.">Check that the creation time of the Key Binding JWT, as determined by the <tt>iat</tt> claim, is within an acceptable window.</li>
              <li pn="section-7.3-4.5.2.6" derivedCounter="f.">Determine that the Key Binding JWT is bound to the current transaction and was created for this Verifier (replay detection) by validating <tt>nonce</tt> and <tt>aud</tt> claims.</li>
              <li pn="section-7.3-4.5.2.7" derivedCounter="g.">Calculate the digest over the Issuer-signed JWT and Disclosures as defined in <xref target="integrity-protection-of-the-presentation" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/> and verify that it matches the value of the <tt>sd_hash</tt> claim in the Key Binding JWT.</li>
              <li pn="section-7.3-4.5.2.8" derivedCounter="h.">Check that the Key Binding JWT is a valid JWT in all other respects, per <xref target="RFC7519" format="default" sectionFormat="of" derivedContent="RFC7519"/> and <xref target="RFC8725" format="default" sectionFormat="of" derivedContent="RFC8725"/>.</li>
            </ol>
          </li>
        </ol>
        <t indent="0" pn="section-7.3-5">If any step fails, the presentation is not valid and processing <bcp14>MUST</bcp14> be aborted.</t>
        <t indent="0" pn="section-7.3-6">Otherwise, the Processed SD-JWT Payload can be passed to the application to be used for the intended purpose.</t>
      </section>
    </section>
    <section anchor="json_serialization" numbered="true" removeInRFC="false" toc="include" pn="section-8">
      <name slugifiedName="name-jws-json-serialization">JWS JSON Serialization</name>
      <t indent="0" pn="section-8-1">This section describes an alternative format for SD-JWTs and SD-JWT+KBs using the JWS JSON
Serialization from <xref target="RFC7515" format="default" sectionFormat="of" derivedContent="RFC7515"/>. Supporting this format is <bcp14>OPTIONAL</bcp14>.</t>
      <section anchor="json_serialization_unprotected_headers" numbered="true" removeInRFC="false" toc="include" pn="section-8.1">
        <name slugifiedName="name-new-unprotected-header-para">New Unprotected Header Parameters</name>
        <t indent="0" pn="section-8.1-1">For both the General and Flattened JSON Serialization, the SD-JWT or SD-JWT+KB is represented
as a JSON object according to <xref target="RFC7515" section="7.2" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc7515#section-7.2" derivedContent="RFC7515"/>. The following new
unprotected header parameters are defined:</t>
        <dl spacing="normal" indent="3" newline="false" pn="section-8.1-2">
          <dt pn="section-8.1-2.1"><tt>disclosures</tt>:</dt>
          <dd pn="section-8.1-2.2">An array of strings where each element is an individual
Disclosure as described in <xref target="creating_disclosures" format="default" sectionFormat="of" derivedContent="Section 4.2"/>.</dd>
          <dt pn="section-8.1-2.3"><tt>kb_jwt</tt>:</dt>
          <dd pn="section-8.1-2.4">Present only in an SD-JWT+KB, the Key Binding JWT as described in <xref target="kb-jwt" format="default" sectionFormat="of" derivedContent="Section 4.3"/>.</dd>
        </dl>
        <t indent="0" pn="section-8.1-3">In an SD-JWT+KB, <tt>kb_jwt</tt> <bcp14>MUST</bcp14> be present when using the JWS JSON Serialization,
and the digest in the <tt>sd_hash</tt> claim <bcp14>MUST</bcp14> be computed over the SD-JWT as described
in <xref target="integrity-protection-of-the-presentation" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>. This means that even when using
the JWS JSON Serialization, the representation as a regular SD-JWT Compact Serialization <bcp14>MUST</bcp14> be
created temporarily to calculate the digest. In detail, the SD-JWT Compact Serialization part is built
by concatenating the protected header, the payload, and the signature of the JWS
JSON serialized SD-JWT using a <tt>.</tt> character as a separator, and using the
Disclosures from the <tt>disclosures</tt> member of the unprotected header.</t>
        <t indent="0" pn="section-8.1-4">Unprotected headers other than <tt>disclosures</tt> are not covered by the digest, and
therefore, as usual, are not protected against tampering.</t>
      </section>
      <section anchor="flattened-json-serialization" numbered="true" removeInRFC="false" toc="include" pn="section-8.2">
        <name slugifiedName="name-flattened-json-serializatio">Flattened JSON Serialization</name>
        <t indent="0" pn="section-8.2-1">In the case of Flattened JSON Serialization, there is only one unprotected
header.</t>
        <t indent="0" pn="section-8.2-2">The following is a non-normative example of a JWS JSON serialized SD-JWT as
issued using the Flattened JSON Serialization:</t>
        <sourcecode type="json" markers="false" pn="section-8.2-3">
{
  "header": {
    "disclosures": [
      "WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN1YiIsICJqb2huX2RvZV80M
        iJd",
      "WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiSm9ob
        iJd",
      "WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIkRvZ
        SJd",
      "WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImJpcnRoZGF0ZSIsICIxOTQwL
        TAxLTAxIl0"
    ]
  },
  "payload": "eyJfc2QiOiBbIjRIQm42YUlZM1d0dUdHV1R4LXFVajZjZGs2V0JwWn
    lnbHRkRmF2UGE3TFkiLCAiOHNtMVFDZjAyMXBObkhBQ0k1c1A0bTRLWmd5Tk9PQV
    ljVGo5SE5hQzF3WSIsICJjZ0ZkaHFQbzgzeFlObEpmYWNhQ2FhN3VQOVJDUjUwVk
    U1UjRMQVE5aXFVIiwgImpNQ1hWei0tOWI4eDM3WWNvRGZYUWluencxd1pjY2NmRl
    JCQ0ZHcWRHMm8iXSwgImlzcyI6ICJodHRwczovL2lzc3Vlci5leGFtcGxlLmNvbS
    IsICJpYXQiOiAxNjgzMDAwMDAwLCAiZXhwIjogMTg4MzAwMDAwMCwgIl9zZF9hbG
    ciOiAic2hhLTI1NiIsICJjbmYiOiB7Imp3ayI6IHsia3R5IjogIkVDIiwgImNydi
    I6ICJQLTI1NiIsICJ4IjogIlRDQUVSMTladnUzT0hGNGo0VzR2ZlNWb0hJUDFJTG
    lsRGxzN3ZDZUdlbWMiLCAieSI6ICJaeGppV1diWk1RR0hWV0tWUTRoYlNJaXJzVm
    Z1ZWNDRTZ0NGpUOUYySFpRIn19fQ",
  "protected":
    "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0",
  "signature": "3oOtvPxU3QdDWUmfGexVB5rWyON2f1atg5rL825bvvD1g7ywjKDK
    y2UHqHoH2QS4FA99JbG5qnlqFaGXFChfjQ"
}
</sourcecode>
        <t indent="0" pn="section-8.2-4">The following is an SD-JWT+KB with two Disclosures:</t>
        <sourcecode type="json" markers="false" pn="section-8.2-5">
{
  "header": {
    "disclosures": [
      "WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIkRvZ
        SJd",
      "WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiSm9ob
        iJd"
    ],
    "kb_jwt": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dCJ9.eyJub25j
      ZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaWVyLmV4YW
      1wbGUub3JnIiwgImlhdCI6IDE3NDg1MzcyNDQsICJzZF9oYXNoIjogIlZqdFBz
      Z1pwUVRSeEtKdkRwU0otblhsWktFOVo5TGdENEZ5Q3d3b05NUncifQ.GrDvJ2j
      hYNmUvqdwVEIrxeTFEuI5qKSM7I6P95JmA6Wko-FBB5vPGQn0wvmdgjLCE2iDR
      h1r82zchjmABQ3V8w"
  },
  "payload": "eyJfc2QiOiBbIjRIQm42YUlZM1d0dUdHV1R4LXFVajZjZGs2V0JwWn
    lnbHRkRmF2UGE3TFkiLCAiOHNtMVFDZjAyMXBObkhBQ0k1c1A0bTRLWmd5Tk9PQV
    ljVGo5SE5hQzF3WSIsICJjZ0ZkaHFQbzgzeFlObEpmYWNhQ2FhN3VQOVJDUjUwVk
    U1UjRMQVE5aXFVIiwgImpNQ1hWei0tOWI4eDM3WWNvRGZYUWluencxd1pjY2NmRl
    JCQ0ZHcWRHMm8iXSwgImlzcyI6ICJodHRwczovL2lzc3Vlci5leGFtcGxlLmNvbS
    IsICJpYXQiOiAxNjgzMDAwMDAwLCAiZXhwIjogMTg4MzAwMDAwMCwgIl9zZF9hbG
    ciOiAic2hhLTI1NiIsICJjbmYiOiB7Imp3ayI6IHsia3R5IjogIkVDIiwgImNydi
    I6ICJQLTI1NiIsICJ4IjogIlRDQUVSMTladnUzT0hGNGo0VzR2ZlNWb0hJUDFJTG
    lsRGxzN3ZDZUdlbWMiLCAieSI6ICJaeGppV1diWk1RR0hWV0tWUTRoYlNJaXJzVm
    Z1ZWNDRTZ0NGpUOUYySFpRIn19fQ",
  "protected":
    "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0",
  "signature": "3oOtvPxU3QdDWUmfGexVB5rWyON2f1atg5rL825bvvD1g7ywjKDK
    y2UHqHoH2QS4FA99JbG5qnlqFaGXFChfjQ"
}
</sourcecode>
      </section>
      <section anchor="general-json-serialization" numbered="true" removeInRFC="false" toc="include" pn="section-8.3">
        <name slugifiedName="name-general-json-serialization">General JSON Serialization</name>
        <t indent="0" pn="section-8.3-1">In the case of General JSON Serialization, there are multiple unprotected
headers (one per signature). If present, <tt>disclosures</tt> and <tt>kb_jwt</tt> <bcp14>MUST</bcp14> be
included in the first unprotected header and <bcp14>MUST NOT</bcp14> be present in any
following unprotected headers.</t>
        <t indent="0" pn="section-8.3-2">The following is a non-normative example of a presentation of a JWS JSON
serialized SD-JWT, including a Key Binding JWT using the General JSON
Serialization:</t>
        <sourcecode type="json" markers="false" pn="section-8.3-3">
{
  "payload": "eyJfc2QiOiBbIjRIQm42YUlZM1d0dUdHV1R4LXFVajZjZGs2V0JwWn
    lnbHRkRmF2UGE3TFkiLCAiOHNtMVFDZjAyMXBObkhBQ0k1c1A0bTRLWmd5Tk9PQV
    ljVGo5SE5hQzF3WSIsICJjZ0ZkaHFQbzgzeFlObEpmYWNhQ2FhN3VQOVJDUjUwVk
    U1UjRMQVE5aXFVIiwgImpNQ1hWei0tOWI4eDM3WWNvRGZYUWluencxd1pjY2NmRl
    JCQ0ZHcWRHMm8iXSwgImlzcyI6ICJodHRwczovL2lzc3Vlci5leGFtcGxlLmNvbS
    IsICJpYXQiOiAxNjgzMDAwMDAwLCAiZXhwIjogMTg4MzAwMDAwMCwgIl9zZF9hbG
    ciOiAic2hhLTI1NiIsICJjbmYiOiB7Imp3ayI6IHsia3R5IjogIkVDIiwgImNydi
    I6ICJQLTI1NiIsICJ4IjogIlRDQUVSMTladnUzT0hGNGo0VzR2ZlNWb0hJUDFJTG
    lsRGxzN3ZDZUdlbWMiLCAieSI6ICJaeGppV1diWk1RR0hWV0tWUTRoYlNJaXJzVm
    Z1ZWNDRTZ0NGpUOUYySFpRIn19fQ",
  "signatures": [
    {
      "header": {
        "disclosures": [
          "WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgI
            kRvZSJd",
          "WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiS
            m9obiJd"
        ],
        "kid": "issuer-key-1",
        "kb_jwt": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dCJ9.eyJu
          b25jZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaW
          VyLmV4YW1wbGUub3JnIiwgImlhdCI6IDE3NDg1MzcyNDQsICJzZF9oYXNo
          IjogInFieUlXUDNwaFZneEVzRFJpd2R3OVc2QkozZHhpUEx1bWNZcFBidT
          RFYjgifQ.VyZqxaVHh1XE6M-kuax_7Laq42uFDrx17lLG2jluyKgy_PqC8
          5z4DVpISdMZDdSANGs-0zN2N7xnM-E1Pg0sOw"
      },
      "protected":
        "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0",
      "signature": "dz1N3uvhVHJjldyXwppmBLieTj0vuBMbzL06rnrLIuxEQb9B
        HoIOwGrWh-UadW4orRpEiEtjf7xyHDONMJ6tBw"
    },
    {
      "header": {
        "kid": "issuer-key-2"
      },
      "protected":
        "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0",
      "signature": "kuXio_U88RH_-fihAPET4AFUjj0BpxsT6yddMFIr6pfHKtAe
        0FOJNWQxU42rfnORuNQNTgGsf2A8LjEba5inNg"
    }
  ]
}
</sourcecode>
      </section>
      <section anchor="verification-of-the-jws-json-serialized-sd-jwt" numbered="true" removeInRFC="false" toc="include" pn="section-8.4">
        <name slugifiedName="name-verification-of-the-jws-jso">Verification of the JWS JSON Serialized SD-JWT</name>
        <t indent="0" pn="section-8.4-1">Verification of the JWS JSON serialized SD-JWT follows the rules defined in
<xref target="verification" format="default" sectionFormat="of" derivedContent="Section 3.4"/>, except for the following aspects:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8.4-2">
          <li pn="section-8.4-2.1">The SD-JWT or SD-JWT+KB does not need to be split into component parts and the Disclosures
can be found in the <tt>disclosures</tt> member of the unprotected header.</li>
          <li pn="section-8.4-2.2">To verify the digest in <tt>sd_hash</tt> in the Key Binding JWT of an SD-JWT+KB, the Verifier <bcp14>MUST</bcp14>
assemble the string to be hashed as described in
<xref target="json_serialization_unprotected_headers" format="default" sectionFormat="of" derivedContent="Section 8.1"/>.</li>
        </ul>
      </section>
    </section>
    <section anchor="security_considerations" numbered="true" removeInRFC="false" toc="include" pn="section-9">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-9-1">The security considerations help achieve the following properties:</t>
      <dl spacing="normal" newline="true" indent="3" pn="section-9-2">
        <dt pn="section-9-2.1">Selective Disclosure:</dt>
        <dd pn="section-9-2.2">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.</dd>
        <dt pn="section-9-2.3">Integrity:</dt>
        <dd pn="section-9-2.4">
          <t indent="0" pn="section-9-2.4.1">A malicious Holder cannot modify
  names or values of selectively disclosable claims without detection by the
  Verifier.</t>
        </dd>
      </dl>
      <t indent="0" pn="section-9-3">Additionally, as described in <xref target="key_binding_security" format="default" sectionFormat="of" derivedContent="Section 9.5"/>, the application of Key Binding can ensure that the presenter of an SD-JWT credential is the Holder of the credential.</t>
      <section anchor="sec-is-jwt" numbered="true" removeInRFC="false" toc="include" pn="section-9.1">
        <name slugifiedName="name-mandatory-signing-of-the-is">Mandatory Signing of the Issuer-Signed JWT</name>
        <t indent="0" pn="section-9.1-1">The JWT <bcp14>MUST</bcp14> be signed by the Issuer to protect the 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).</t>
        <t indent="0" pn="section-9.1-2">The Verifier <bcp14>MUST</bcp14> always check the signature of the Issuer-signed JWT to ensure that it
has not been tampered with since its issuance. The Issuer-signed JWT <bcp14>MUST</bcp14> be rejected if the signature cannot be verified.</t>
        <t indent="0" pn="section-9.1-3">The security of the Issuer-signed JWT depends on the security of the signature algorithm.
Per the last paragraph of <xref target="RFC7515" section="5.2" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc7515#section-5.2" derivedContent="RFC7515"/>, it is an
application-specific decision to choose the appropriate JWS
algorithm from <xref target="JWS.Algs" format="default" sectionFormat="of" derivedContent="JWS.Algs"/>, including post-quantum algorithms, when they are ready.</t>
      </section>
      <section anchor="sec-disclosures" numbered="true" removeInRFC="false" toc="include" pn="section-9.2">
        <name slugifiedName="name-manipulation-of-disclosures">Manipulation of Disclosures</name>
        <t indent="0" pn="section-9.2-1">Holders can manipulate the Disclosures by changing the values of the claims
before sending them to the Verifier. The Verifier <bcp14>MUST</bcp14> 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.</t>
        <t indent="0" pn="section-9.2-2">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.</t>
        <t indent="0" pn="section-9.2-3">The steps described in <xref target="verifier_verification" format="default" sectionFormat="of" derivedContent="Section 7.3"/> ensure that the Verifier
checks the Disclosures correctly.</t>
      </section>
      <section anchor="salt-entropy" numbered="true" removeInRFC="false" toc="include" pn="section-9.3">
        <name slugifiedName="name-entropy-of-the-salt">Entropy of the Salt</name>
        <t indent="0" pn="section-9.3-1">The security model that conceals the plaintext claims relies on the high entropy
random data of the salt as additional input to the hash function. The randomness
ensures that the same plaintext claim value does not produce the same digest value. It also
makes it infeasible to guess the preimage of the digest (thereby learning the
plaintext claim value) by enumerating the potential value
space for a claim into the hash function to search for a matching digest value.
It is therefore vitally important that unrevealed salts cannot be learned or guessed,
even if other salts have been revealed. As such, each salt <bcp14>MUST</bcp14> be created
in such a manner that it is cryptographically random, sufficiently long, and
has high enough entropy that it is infeasible to guess. A
new salt <bcp14>MUST</bcp14> be chosen for each claim independently of other salts.
See "Randomness Requirements for Security" <xref target="RFC4086" format="default" sectionFormat="of" derivedContent="RFC4086"/> for considerations
on generating random values.</t>
        <t indent="0" pn="section-9.3-2">The <bcp14>RECOMMENDED</bcp14> minimum length of the randomly generated portion of the salt is 128 bits.</t>
        <t indent="0" pn="section-9.3-3">The Issuer <bcp14>MUST</bcp14> 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 the example in <xref target="example-complex-structured-sd-jwt" format="default" sectionFormat="of" derivedContent="Appendix A.2"/>,
where multiple claims with the name <tt>type</tt> appear, but each of them has
a different salt.</t>
      </section>
      <section anchor="choice-of-a-hash-algorithm" numbered="true" removeInRFC="false" toc="include" pn="section-9.4">
        <name slugifiedName="name-choice-of-a-hash-algorithm">Choice of a Hash Algorithm</name>
        <t indent="0" pn="section-9.4-1">To ensure privacy of claims that are selectively disclosable but are not being disclosed in a given presentation,
the hash function <bcp14>MUST</bcp14> 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 <bcp14>MUST</bcp14>
be preimage resistant and 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
needs to be computationally hiding.</t>
        <t indent="0" pn="section-9.4-2">To ensure the integrity of selectively disclosable claims, the hash function <bcp14>MUST</bcp14> 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 results in the same digest.</t>
        <t indent="0" pn="section-9.4-3">The hash function <bcp14>SHOULD</bcp14> 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 <bcp14>SHOULD</bcp14>
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.</t>
        <t indent="0" pn="section-9.4-4">Inclusion in the "Named Information Hash Algorithm Registry" <xref target="Hash.Algs" format="default" sectionFormat="of" derivedContent="Hash.Algs"/>
alone does not indicate a hash algorithm's suitability for use in SD-JWT (it contains several
heavily truncated digests, such as <tt>sha-256-32</tt> and <tt>sha-256-64</tt>, which are unfit for security
applications).</t>
      </section>
      <section anchor="key_binding_security" numbered="true" removeInRFC="false" toc="include" pn="section-9.5">
        <name slugifiedName="name-key-binding-2">Key Binding</name>
        <t indent="0" pn="section-9.5-1">Key Binding aims to ensure that the presenter of an SD-JWT credential is actually the Holder of the credential.
An SD-JWT compatible 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.</t>
        <t indent="0" pn="section-9.5-2">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 the credential was leaked to an attacker, the attacker can
present the credential to any Verifier that does not require a
binding. 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.</t>
        <t indent="0" pn="section-9.5-3">Verifiers <bcp14>MUST</bcp14> 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.</t>
        <t indent="0" pn="section-9.5-4">It is important that a Verifier not make its security policy
decisions based on data that can be influenced by an attacker. For this reason, when deciding whether or not Key
Binding is required, Verifiers <bcp14>MUST NOT</bcp14> take into account
whether the Holder has provided an SD-JWT+KB or a bare SD-JWT; otherwise, an
attacker could strip the KB-JWT from an SD-JWT+KB and present the resultant SD-JWT.</t>
        <t indent="0" pn="section-9.5-5">Furthermore, Verifiers should be aware that Key Binding information may have been added to an SD-JWT in a format that they do not recognize and therefore may not be able to tell whether or not the SD-JWT supports Key Binding.</t>
        <t indent="0" pn="section-9.5-6">If a Verifier determines that Key Binding is required for a
particular use case and the Holder presents either a bare SD-JWT or an SD-JWT+KB with
an invalid Key Binding JWT, then the Verifier will reject the presentation
when following the verification steps described in <xref target="verifier_verification" format="default" sectionFormat="of" derivedContent="Section 7.3"/>.</t>
      </section>
      <section anchor="concealing-claim-names" numbered="true" removeInRFC="false" toc="include" pn="section-9.6">
        <name slugifiedName="name-concealing-claim-names">Concealing Claim Names</name>
        <t indent="0" pn="section-9.6-1">SD-JWT ensures that names of claims that are selectively disclosable are
always concealed unless the claim's value is disclosed. This prevents an attacker from learning the names of such
claims. However, the names of the claims that are permanently
disclosed are not hidden. This includes the keys of objects that themselves
are not concealed, but contain concealed claims. This limitation
needs to be taken into account by Issuers when creating the structure of
the SD-JWT.</t>
      </section>
      <section anchor="sd-validity-claims" numbered="true" removeInRFC="false" toc="include" pn="section-9.7">
        <name slugifiedName="name-selectively-disclosable-val">Selectively Disclosable Validity Claims</name>
        <t indent="0" pn="section-9.7-1">An Issuer <bcp14>MUST NOT</bcp14> 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 <bcp14>SHOULD</bcp14> be listed by any application-specific profiles of SD-JWT.
The following is a list of registered JWT claim names that <bcp14>SHOULD</bcp14> be considered as
security critical:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-9.7-2">
          <li pn="section-9.7-2.1">
            <tt>iss</tt> (Issuer)</li>
          <li pn="section-9.7-2.2">
            <tt>aud</tt> (Audience), although issuers <bcp14>MAY</bcp14> allow individual entries in the array to be selectively disclosable</li>
          <li pn="section-9.7-2.3">
            <tt>exp</tt> (Expiration Time)</li>
          <li pn="section-9.7-2.4">
            <tt>nbf</tt> (Not Before)</li>
          <li pn="section-9.7-2.5">
            <tt>cnf</tt> (Confirmation Key)</li>
        </ul>
        <t indent="0" pn="section-9.7-3">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 will do so. Therefore, Verifiers cannot
reliably depend on that and need to operate as though security-critical claims might be
selectively disclosable.</t>
        <t indent="0" pn="section-9.7-4">Verifiers therefore <bcp14>MUST</bcp14> 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 <xref target="sd_jwt_verification" format="default" sectionFormat="of" derivedContent="Section 7.1"/>.</t>
        <t indent="0" pn="section-9.7-5">The precise set of required validity claims will typically be defined by
operating environment rules, an application-specific profile, or the credential format, and <bcp14>MAY</bcp14> include claims other than
those listed herein.</t>
      </section>
      <section anchor="issuer_signature_key_distribution" numbered="true" removeInRFC="false" toc="include" pn="section-9.8">
        <name slugifiedName="name-distribution-and-rotation-o">Distribution and Rotation of Issuer Signature Verification Key</name>
        <t indent="0" pn="section-9.8-1">This specification does not define how signature verification keys of
Issuers are distributed to Verifiers. However, it is <bcp14>RECOMMENDED</bcp14> 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 <xref target="RFC7517" format="default" sectionFormat="of" derivedContent="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.</t>
      </section>
      <section anchor="forwarding-credentials" numbered="true" removeInRFC="false" toc="include" pn="section-9.9">
        <name slugifiedName="name-forwarding-credentials">Forwarding Credentials</name>
        <t indent="0" pn="section-9.9-1">Any entity in possession of an SD-JWT (including an SD-JWT extracted from an SD-JWT+KB) can forward it to any third party
that does not enforce Key Binding.
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.</t>
        <t indent="0" pn="section-9.9-2">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.</t>
        <t indent="0" pn="section-9.9-3">In some scenarios, this behavior could be desirable;
if it is not, Issuers need to support and Verifiers need to enforce Key Binding.</t>
      </section>
      <section anchor="integrity-of-sd-jwts-and-sd-jwt-kbs" numbered="true" removeInRFC="false" toc="include" pn="section-9.10">
        <name slugifiedName="name-integrity-of-sd-jwts-and-sd">Integrity of SD-JWTs and SD-JWT+KBs</name>
        <t indent="0" pn="section-9.10-1">With an SD-JWT, the Issuer-signed JWT is integrity protected by the Issuer's
signature, and the values of the Disclosures are integrity protected by the digests
included therein. The specific set of Disclosures, however,
is not integrity protected; the SD-JWT can be modified by adding or
removing Disclosures and still be valid.</t>
        <t indent="0" pn="section-9.10-2">With an SD-JWT+KB, the set of selected Disclosures is integrity protected.
The signature in the Key Binding JWT covers a
specific SD-JWT, with a specific Issuer-signed JWT and a specific set of
Disclosures.  Thus, the signature on the Key Binding JWT, in addition to proving
Key Binding, also assures the authenticity and integrity of the set of
Disclosures the Holder disclosed.  The set of Disclosures in an SD-JWT+KB is the set
that the Holder intended to send; no intermediate party has added, removed, or
modified the list of Disclosures.</t>
      </section>
      <section anchor="explicit_typing" numbered="true" removeInRFC="false" toc="include" pn="section-9.11">
        <name slugifiedName="name-explicit-typing">Explicit Typing</name>
        <t indent="0" pn="section-9.11-1"><xref target="RFC8725" sectionFormat="of" section="3.11" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8725#section-3.11" derivedContent="RFC8725"/> describes the use of explicit typing as one mechanism to prevent confusion attacks
(described in <xref target="RFC8725" sectionFormat="of" section="2.8" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8725#section-2.8" derivedContent="RFC8725"/>) in which one kind of JWT is mistaken for another. SD-JWTs are also potentially
subject to such confusion attacks, so in the absence of other techniques, it is <bcp14>RECOMMENDED</bcp14> that application profiles of SD-JWT specify an explicit type
by including the <tt>typ</tt> header parameter when the SD-JWT is issued, and that Verifiers check this value.</t>
        <t indent="0" pn="section-9.11-2">When explicit typing using the <tt>typ</tt> header is employed for an SD-JWT, it is <bcp14>RECOMMENDED</bcp14> that a media type name of the format
"application/example+sd-jwt" be used, where "example" is replaced by the identifier for the specific kind of SD-JWT.
The definition of <tt>typ</tt> in <xref target="RFC7515" section="4.1.9" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc7515#section-4.1.9" derivedContent="RFC7515"/> recommends that the "application/" prefix be omitted, so
"example+sd-jwt" would be the value of the <tt>typ</tt> header parameter.</t>
        <t indent="0" pn="section-9.11-3">Use of the <tt>cty</tt> content type header parameter to indicate the content type of the SD-JWT payload can also be used to distinguish different types of JSON objects or different kinds of JWT Claim Sets.</t>
      </section>
      <section anchor="key-pair-generation-and-lifecycle-management" numbered="true" removeInRFC="false" toc="include" pn="section-9.12">
        <name slugifiedName="name-key-pair-generation-and-lif">Key Pair Generation and Lifecycle Management</name>
        <t indent="0" pn="section-9.12-1">Implementations of SD-JWT rely on asymmetric cryptographic keys and must therefore ensure that key pair generation,
handling, storage, and lifecycle management are performed securely.</t>
        <t indent="0" pn="section-9.12-2">While the specific mechanisms for secure key management are out of scope for this document, implementers
should follow established best practices, such as those outlined in NIST SP 800-57 Part 1 <xref target="NIST.SP.800-57pt1r5" format="default" sectionFormat="of" derivedContent="NIST.SP.800-57pt1r5"/>.
This includes:</t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-9.12-3">
          <li pn="section-9.12-3.1">Secure Generation: Using cryptographically secure methods and random number generators.</li>
          <li pn="section-9.12-3.2">Secure Storage: Protecting private keys from unauthorized access.</li>
          <li pn="section-9.12-3.3">Lifecycle Management: Ensuring secure key rotation, revocation, and disposal as needed.</li>
        </ul>
        <t indent="0" pn="section-9.12-4">Appropriate key management is essential, as any compromise can lead to unauthorized disclosure or forgery of SD-JWTs.</t>
      </section>
    </section>
    <section anchor="privacy_considerations" numbered="true" removeInRFC="false" toc="include" pn="section-10">
      <name slugifiedName="name-privacy-considerations">Privacy Considerations</name>
      <section anchor="unlinkability" numbered="true" removeInRFC="false" toc="include" pn="section-10.1">
        <name slugifiedName="name-unlinkability">Unlinkability</name>
        <t indent="0" pn="section-10.1-1">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:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-10.1-2">
          <li pn="section-10.1-2.1">Cooperating Verifiers might want to track users across services to build
advertising profiles.</li>
          <li pn="section-10.1-2.2">Issuers might want to track where users present their credentials to enable
surveillance.</li>
          <li pn="section-10.1-2.3">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.</li>
        </ul>
        <t indent="0" pn="section-10.1-3">The following types of unlinkability are discussed below:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-10.1-4">
          <li pn="section-10.1-4.1">Presentation Unlinkability: A Verifier should not be able to link two
presentations of the same credential.</li>
          <li pn="section-10.1-4.2">Verifier/Verifier Unlinkability: The presentations made to two different
Verifiers should not reveal that the same credential was presented (e.g., if the two
Verifiers collude, or if they are forced by a third party to reveal the presentations
made to them, or data leaks from one Verifier to the other).</li>
          <li pn="section-10.1-4.3">Issuer/Verifier Unlinkability (Honest Verifier): An Issuer of a credential
should not be able to know that a user presented this credential unless
the Verifier is sharing presentation data with the Issuer
accidentally, deliberately, or because it is forced to do so.</li>
          <li pn="section-10.1-4.4">Issuer/Verifier Unlinkability (Careless/Colluding/Compromised/Coerced Verifier): &gt;An Issuer of a
credential should under no circumstances be able to tell that a user presented this credential to
a certain Verifier. In particular, this includes cases when the Verifier accidentally or deliberately shares
presentation data with the Issuer or is forced to do so.</li>
        </ul>
        <t indent="0" pn="section-10.1-5">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.</t>
        <t indent="0" pn="section-10.1-6">Issuer/Verifier unlinkability with a careless, colluding, compromised, or coerced 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. To reduce the risk of revealing the data later on, <xref target="data_storage" format="default" sectionFormat="of" derivedContent="Section 10.2"/> defines
requirements to reduce the amount of data stored.</t>
        <t indent="0" pn="section-10.1-7">In considering Issuer/Verifier unlinkability, it is important to note the potential for an asymmetric power dynamic
between Issuers and Verifiers. This dynamic can compel an otherwise Honest Verifier into collusion.
For example, a governmental Issuer might have the authority to mandate that a Verifier report back information
about the credentials presented to it. Legal requirements could further enforce this, explicitly undermining
Issuer/Verifier unlinkability. Similarly, a large service provider issuing credentials might implicitly pressure
Verifiers into collusion by incentivizing participation in their larger operating environment.
Deployers of SD-JWT must be aware of these potential power dynamics,
mitigate them as much as possible, and/or make the risks transparent to the user.</t>
        <t indent="0" pn="section-10.1-8">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 need to be executed in a manner that
preserves privacy and does not disclose details about the credential to the Issuer
(the mechanism described in <xref target="I-D.ietf-oauth-status-list" format="default" sectionFormat="of" derivedContent="TSL"/> is an example of an approach
that discloses minimal information towards the Issuer). It is
important to note that the timing of such requests could potentially serve as a side channel.</t>
        <t indent="0" pn="section-10.1-9">Verifier/Verifier unlinkability and presentation unlinkability 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 <bcp14>MUST</bcp14> 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 <tt>iat</tt>, <tt>exp</tt>, and <tt>nbf</tt>, <bcp14>MUST</bcp14> either be randomized within a
time period considered appropriate (e.g., randomize <tt>iat</tt> within the last 24
hours and calculate <tt>exp</tt> accordingly) or rounded (e.g., rounded down to the
beginning of the day).</t>
        <t indent="0" pn="section-10.1-10">SD-JWT only conceals the value of claims that are not revealed.
It does not meet the security properties for anonymous credentials <xref target="CL01" format="default" sectionFormat="of" derivedContent="CL01"/>. In
particular, colluding Verifiers and Issuers can know when they have seen the same
credential no matter what fields have been disclosed, even when none have been disclosed.
This behavior may not align with what users naturally anticipate or are guided to
expect from user-interface interactions, potentially causing them to make decisions
they might not otherwise make. Workarounds such as batch issuance, as
described above, help with keeping
Verifiers from linking different presentations, but cannot work for Issuer/Verifier unlinkability.
This issue applies to all salted hash-based approaches,
including mDL/mDoc <xref target="ISO.18013-5" format="default" sectionFormat="of" derivedContent="ISO.18013-5"/> and SD-CWT <xref target="I-D.ietf-spice-sd-cwt" format="default" sectionFormat="of" derivedContent="SD-CWT"/>.</t>
      </section>
      <section anchor="data_storage" numbered="true" removeInRFC="false" toc="include" pn="section-10.2">
        <name slugifiedName="name-storage-of-user-data">Storage of User Data</name>
        <t indent="0" pn="section-10.2-1">Wherever 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 <xref target="OpenID.Core" format="default" sectionFormat="of" derivedContent="OpenID.Core"/>,
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.</t>
        <t indent="0" pn="section-10.2-2">Not surprisingly, a leak of such data risks revealing private data of users
to third parties. Signed user data, the authenticity of which
can be easily verified by third parties, further exacerbates the risk.
As discussed in <xref target="key_binding_security" format="default" sectionFormat="of" derivedContent="Section 9.5"/>, 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.</t>
        <t indent="0" pn="section-10.2-3">Due to these risks, and the risks described in <xref target="unlinkability" format="default" sectionFormat="of" derivedContent="Section 10.1"/>, systems implementing SD-JWT <bcp14>SHOULD</bcp14> be designed to minimize
the amount of data that is stored. All involved parties <bcp14>SHOULD NOT</bcp14> store SD-JWTs
longer than strictly necessary, including in log files.</t>
        <t indent="0" pn="section-10.2-4">After Issuance, Issuers <bcp14>SHOULD NOT</bcp14> store the Issuer-signed JWT or the respective
Disclosures.</t>
        <t indent="0" pn="section-10.2-5">Holders <bcp14>SHOULD</bcp14> 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 user devices, <bcp14>SHOULD</bcp14> be preferred for user
credentials over centralized storage. Expired SD-JWTs <bcp14>SHOULD</bcp14> be deleted
as soon as possible.</t>
        <t indent="0" pn="section-10.2-6">After Verification, Verifiers <bcp14>SHOULD NOT</bcp14> store the Issuer-signed JWT or the
respective Disclosures. It may be
sufficient to store the result of the verification and any user data that is
needed for the application.</t>
        <t indent="0" pn="section-10.2-7">Exceptions from the rules above can be made if there are strong requirements to do
so (e.g., functional requirements or legal audit requirements), secure storage can
be ensured, and the privacy impact has been assessed.</t>
      </section>
      <section anchor="confidentiality-during-transport" numbered="true" removeInRFC="false" toc="include" pn="section-10.3">
        <name slugifiedName="name-confidentiality-during-tran">Confidentiality During Transport</name>
        <t indent="0" pn="section-10.3-1">If an SD-JWT or SD-JWT+KB is transmitted over an insecure
channel during issuance or presentation, an adversary may be able to
intercept and read the user's personal data or correlate the information with previous uses.</t>
        <t indent="0" pn="section-10.3-2">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.</t>
        <t indent="0" pn="section-10.3-3">This specification therefore considers the confidentiality of the data to be
provided by the transport protocol and does not specify any encryption
mechanism.</t>
        <t indent="0" pn="section-10.3-4">Implementers <bcp14>MUST</bcp14> ensure that the transport protocol provides confidentiality
if the privacy of user data or correlation attacks by passive observers are a concern.</t>
        <t indent="0" pn="section-10.3-5">To encrypt an SD-JWT or SD-JWT+KB during transit over potentially insecure or leakage-prone channels, implementers <bcp14>MAY</bcp14> use JSON Web Encryption (JWE) <xref target="RFC7516" format="default" sectionFormat="of" derivedContent="RFC7516"/>, encapsulating the SD-JWT or SD-JWT+KB as the plaintext payload of the 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 <bcp14>SHOULD</bcp14> be encrypted using JWE.</t>
      </section>
      <section anchor="decoy_digests_privacy" numbered="true" removeInRFC="false" toc="include" pn="section-10.4">
        <name slugifiedName="name-decoy-digests-2">Decoy Digests</name>
        <t indent="0" pn="section-10.4-1">The use of decoy digests is <bcp14>RECOMMENDED</bcp14> 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 user is a member of a group), the Issuer <bcp14>SHOULD</bcp14> add decoy digests when the condition is not met.</t>
        <t indent="0" pn="section-10.4-2">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 user's data.</t>
      </section>
      <section anchor="issuer-identifier" numbered="true" removeInRFC="false" toc="include" pn="section-10.5">
        <name slugifiedName="name-issuer-identifier">Issuer Identifier</name>
        <t indent="0" pn="section-10.5-1">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.</t>
        <t indent="0" pn="section-10.5-2">For example, if a cancer research 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.</t>
        <t indent="0" pn="section-10.5-3">Moreover, the Issuer identifier alone may reveal information about the user.</t>
        <t indent="0" pn="section-10.5-4">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.</t>
        <t indent="0" pn="section-10.5-5">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.</t>
      </section>
    </section>
    <section anchor="iana_considerations" numbered="true" removeInRFC="false" toc="include" pn="section-11">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <section anchor="json-web-token-claims-registration" numbered="true" removeInRFC="false" toc="include" pn="section-11.1">
        <name slugifiedName="name-json-web-token-claims-regis">JSON Web Token Claims Registration</name>
        <t indent="0" pn="section-11.1-1">IANA has registered the following Claims in the
"JSON Web Token Claims" registry <xref target="JWT.Claims" format="default" sectionFormat="of" derivedContent="JWT.Claims"/> established by <xref target="RFC7519" format="default" sectionFormat="of" derivedContent="RFC7519"/>.</t>
        <dl spacing="compact" newline="false" indent="3" pn="section-11.1-2">
          <dt pn="section-11.1-2.1">Claim Name:</dt>
          <dd pn="section-11.1-2.2">
            <tt>_sd</tt></dd>
          <dt pn="section-11.1-2.3">Claim Description:</dt>
          <dd pn="section-11.1-2.4">Digests of Disclosures for object properties</dd>
          <dt pn="section-11.1-2.5">Change Controller:</dt>
          <dd pn="section-11.1-2.6">IETF</dd>
          <dt pn="section-11.1-2.7">Specification Document(s):</dt>
          <dd pn="section-11.1-2.8">
            <xref target="embedding_object_properties" format="default" sectionFormat="of" derivedContent="Section 4.2.4.1"/> of RFC 9901</dd>
        </dl>
        <dl spacing="compact" newline="false" indent="3" pn="section-11.1-3">
          <dt pn="section-11.1-3.1">Claim Name:</dt>
          <dd pn="section-11.1-3.2">
            <tt>...</tt></dd>
          <dt pn="section-11.1-3.3">Claim Description:</dt>
          <dd pn="section-11.1-3.4">Digest of the Disclosure for an array element</dd>
          <dt pn="section-11.1-3.5">Change Controller:</dt>
          <dd pn="section-11.1-3.6">IETF</dd>
          <dt pn="section-11.1-3.7">Specification Document(s):</dt>
          <dd pn="section-11.1-3.8">
            <xref target="embedding_array_elements" format="default" sectionFormat="of" derivedContent="Section 4.2.4.2"/> of RFC 9901</dd>
        </dl>
        <dl spacing="compact" newline="false" indent="3" pn="section-11.1-4">
          <dt pn="section-11.1-4.1">Claim Name:</dt>
          <dd pn="section-11.1-4.2">
            <tt>_sd_alg</tt></dd>
          <dt pn="section-11.1-4.3">Claim Description:</dt>
          <dd pn="section-11.1-4.4">Hash algorithm used to generate Disclosure digests and digest over presentation</dd>
          <dt pn="section-11.1-4.5">Change Controller:</dt>
          <dd pn="section-11.1-4.6">IETF</dd>
          <dt pn="section-11.1-4.7">Specification Document(s):</dt>
          <dd pn="section-11.1-4.8">
            <xref target="hash_function_claim" format="default" sectionFormat="of" derivedContent="Section 4.1.1"/> of RFC 9901</dd>
        </dl>
        <dl spacing="compact" newline="false" indent="3" pn="section-11.1-5">
          <dt pn="section-11.1-5.1">Claim Name:</dt>
          <dd pn="section-11.1-5.2">
            <tt>sd_hash</tt></dd>
          <dt pn="section-11.1-5.3">Claim Description:</dt>
          <dd pn="section-11.1-5.4">Digest of the SD-JWT to which the KB-JWT is tied</dd>
          <dt pn="section-11.1-5.5">Change Controller:</dt>
          <dd pn="section-11.1-5.6">IETF</dd>
          <dt pn="section-11.1-5.7">Specification Document(s):</dt>
          <dd pn="section-11.1-5.8">
            <xref target="kb-jwt" format="default" sectionFormat="of" derivedContent="Section 4.3"/> of RFC 9901</dd>
        </dl>
      </section>
      <section anchor="media-type-registration" numbered="true" removeInRFC="false" toc="include" pn="section-11.2">
        <name slugifiedName="name-media-type-registrations">Media Type Registrations</name>
        <t indent="0" pn="section-11.2-1">IANA has registered the following media types <xref target="RFC2046" format="default" sectionFormat="of" derivedContent="RFC2046"/> in
the "Media Types" registry <xref target="MediaTypes" format="default" sectionFormat="of" derivedContent="MediaTypes"/> in the manner described
in <xref target="RFC6838" format="default" sectionFormat="of" derivedContent="RFC6838"/>.</t>
        <aside pn="section-11.2-2">
          <t indent="0" pn="section-11.2-2.1">Note: For the media type value used in the <tt>typ</tt> header in the Issuer-signed JWT
itself, see <xref target="explicit_typing" format="default" sectionFormat="of" derivedContent="Section 9.11"/>.</t>
        </aside>
        <section toc="exclude" anchor="sj-jwt-content" numbered="true" removeInRFC="false" pn="section-11.2.1">
          <name slugifiedName="name-sd-jwt-content">SD-JWT Content</name>
          <t indent="0" pn="section-11.2.1-1">To indicate that the content is an SD-JWT:</t>
          <dl spacing="normal" indent="3" newline="false" pn="section-11.2.1-2">
            <dt pn="section-11.2.1-2.1">Type name:</dt>
            <dd pn="section-11.2.1-2.2">application</dd>
            <dt pn="section-11.2.1-2.3">Subtype name:</dt>
            <dd pn="section-11.2.1-2.4">sd-jwt</dd>
            <dt pn="section-11.2.1-2.5">Required parameters:</dt>
            <dd pn="section-11.2.1-2.6">n/a</dd>
            <dt pn="section-11.2.1-2.7">Optional parameters:</dt>
            <dd pn="section-11.2.1-2.8">n/a</dd>
            <dt pn="section-11.2.1-2.9">Encoding considerations:</dt>
            <dd pn="section-11.2.1-2.10">binary; application/sd-jwt values are a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') and tilde ('~') characters.</dd>
            <dt pn="section-11.2.1-2.11">Security considerations:</dt>
            <dd pn="section-11.2.1-2.12">See the Security Considerations sections of RFC 9901, <xref target="RFC7519" format="default" sectionFormat="of" derivedContent="RFC7519"/>, and <xref target="RFC8725" format="default" sectionFormat="of" derivedContent="RFC8725"/>.</dd>
            <dt pn="section-11.2.1-2.13">Interoperability considerations:</dt>
            <dd pn="section-11.2.1-2.14">n/a</dd>
            <dt pn="section-11.2.1-2.15">Published specification:</dt>
            <dd pn="section-11.2.1-2.16">RFC 9901</dd>
            <dt pn="section-11.2.1-2.17">Applications that use this media type:</dt>
            <dd pn="section-11.2.1-2.18">Applications requiring selective disclosure of integrity-protected content.</dd>
            <dt pn="section-11.2.1-2.19">Fragment identifier considerations:</dt>
            <dd pn="section-11.2.1-2.20">n/a</dd>
            <dt pn="section-11.2.1-2.21">Additional information:</dt>
            <dd pn="section-11.2.1-2.22">
              <t indent="0" pn="section-11.2.1-2.22.1"><br/></t>
              <dl spacing="compact" indent="3" newline="false" pn="section-11.2.1-2.22.2">
                <dt pn="section-11.2.1-2.22.2.1">Magic number(s):</dt>
                <dd pn="section-11.2.1-2.22.2.2">n/a</dd>
                <dt pn="section-11.2.1-2.22.2.3">File extension(s):</dt>
                <dd pn="section-11.2.1-2.22.2.4">n/a</dd>
                <dt pn="section-11.2.1-2.22.2.5">Macintosh file type code(s):</dt>
                <dd pn="section-11.2.1-2.22.2.6">n/a</dd>
              </dl>
            </dd>
            <dt pn="section-11.2.1-2.23">Person &amp; email address to contact for further information:</dt>
            <dd pn="section-11.2.1-2.24">Daniel Fett, mail@danielfett.de</dd>
            <dt pn="section-11.2.1-2.25">Intended usage:</dt>
            <dd pn="section-11.2.1-2.26">COMMON</dd>
            <dt pn="section-11.2.1-2.27">Restrictions on usage:</dt>
            <dd pn="section-11.2.1-2.28">none</dd>
            <dt pn="section-11.2.1-2.29">Author:</dt>
            <dd pn="section-11.2.1-2.30">Daniel Fett, mail@danielfett.de</dd>
            <dt pn="section-11.2.1-2.31">Change Controller:</dt>
            <dd pn="section-11.2.1-2.32">IETF</dd>
          </dl>
        </section>
        <section toc="exclude" anchor="jws-json-content" numbered="true" removeInRFC="false" pn="section-11.2.2">
          <name slugifiedName="name-jws-json-serialized-sd-jwt-">JWS JSON Serialized SD-JWT Content</name>
          <t indent="0" pn="section-11.2.2-1">To indicate that the content is a JWS JSON serialized SD-JWT:</t>
          <dl spacing="normal" indent="3" newline="false" pn="section-11.2.2-2">
            <dt pn="section-11.2.2-2.1">Type name:</dt>
            <dd pn="section-11.2.2-2.2">application</dd>
            <dt pn="section-11.2.2-2.3">Subtype name:</dt>
            <dd pn="section-11.2.2-2.4">sd-jwt+json</dd>
            <dt pn="section-11.2.2-2.5">Required parameters:</dt>
            <dd pn="section-11.2.2-2.6">n/a</dd>
            <dt pn="section-11.2.2-2.7">Optional parameters:</dt>
            <dd pn="section-11.2.2-2.8">n/a</dd>
            <dt pn="section-11.2.2-2.9">Encoding considerations:</dt>
            <dd pn="section-11.2.2-2.10">binary; application/sd-jwt+json values are represented as a JSON Object.</dd>
            <dt pn="section-11.2.2-2.11">Security considerations:</dt>
            <dd pn="section-11.2.2-2.12">See the Security Considerations sections of RFC 9901 and <xref target="RFC7515" format="default" sectionFormat="of" derivedContent="RFC7515"/>.</dd>
            <dt pn="section-11.2.2-2.13">Interoperability considerations:</dt>
            <dd pn="section-11.2.2-2.14">n/a</dd>
            <dt pn="section-11.2.2-2.15">Published specification:</dt>
            <dd pn="section-11.2.2-2.16">RFC 9901</dd>
            <dt pn="section-11.2.2-2.17">Applications that use this media type:</dt>
            <dd pn="section-11.2.2-2.18">Applications requiring selective disclosure of content protected by ETSI JAdES compliant signatures.</dd>
            <dt pn="section-11.2.2-2.19">Fragment identifier considerations:</dt>
            <dd pn="section-11.2.2-2.20">n/a</dd>
            <dt pn="section-11.2.2-2.21">Additional information:</dt>
            <dd pn="section-11.2.2-2.22">
              <t indent="0" pn="section-11.2.2-2.22.1"><br/></t>
              <dl spacing="compact" indent="3" newline="false" pn="section-11.2.2-2.22.2">
                <dt pn="section-11.2.2-2.22.2.1">Magic number(s):</dt>
                <dd pn="section-11.2.2-2.22.2.2">n/a</dd>
                <dt pn="section-11.2.2-2.22.2.3">File extension(s):</dt>
                <dd pn="section-11.2.2-2.22.2.4">n/a</dd>
                <dt pn="section-11.2.2-2.22.2.5">Macintosh file type code(s):</dt>
                <dd pn="section-11.2.2-2.22.2.6">n/a</dd>
              </dl>
            </dd>
            <dt pn="section-11.2.2-2.23">Person &amp; email address to contact for further information:</dt>
            <dd pn="section-11.2.2-2.24">Daniel Fett, mail@danielfett.de</dd>
            <dt pn="section-11.2.2-2.25">Intended usage:</dt>
            <dd pn="section-11.2.2-2.26">COMMON</dd>
            <dt pn="section-11.2.2-2.27">Restrictions on usage:</dt>
            <dd pn="section-11.2.2-2.28">none</dd>
            <dt pn="section-11.2.2-2.29">Author:</dt>
            <dd pn="section-11.2.2-2.30">Daniel Fett, mail@danielfett.de</dd>
            <dt pn="section-11.2.2-2.31">Change Controller:</dt>
            <dd pn="section-11.2.2-2.32">IETF</dd>
          </dl>
        </section>
        <section toc="exclude" anchor="kb-jwt-content" numbered="true" removeInRFC="false" pn="section-11.2.3">
          <name slugifiedName="name-key-binding-jwt-content">Key Binding JWT Content</name>
          <t indent="0" pn="section-11.2.3-1">To indicate that the content is a Key Binding JWT:</t>
          <dl spacing="normal" indent="3" newline="false" pn="section-11.2.3-2">
            <dt pn="section-11.2.3-2.1">Type name:</dt>
            <dd pn="section-11.2.3-2.2">application</dd>
            <dt pn="section-11.2.3-2.3">Subtype name:</dt>
            <dd pn="section-11.2.3-2.4">kb+jwt</dd>
            <dt pn="section-11.2.3-2.5">Required parameters:</dt>
            <dd pn="section-11.2.3-2.6">n/a</dd>
            <dt pn="section-11.2.3-2.7">Optional parameters:</dt>
            <dd pn="section-11.2.3-2.8">n/a</dd>
            <dt pn="section-11.2.3-2.9">Encoding considerations:</dt>
            <dd pn="section-11.2.3-2.10">binary; A Key Binding JWT is a JWT; JWT values are encoded as a series of base64url-encoded values separated by period ('.') characters.</dd>
            <dt pn="section-11.2.3-2.11">Security considerations:</dt>
            <dd pn="section-11.2.3-2.12">See the Security Considerations sections of RFC 9901, <xref target="RFC7519" format="default" sectionFormat="of" derivedContent="RFC7519"/>, and <xref target="RFC8725" format="default" sectionFormat="of" derivedContent="RFC8725"/>.</dd>
            <dt pn="section-11.2.3-2.13">Interoperability considerations:</dt>
            <dd pn="section-11.2.3-2.14">n/a</dd>
            <dt pn="section-11.2.3-2.15">Published specification:</dt>
            <dd pn="section-11.2.3-2.16">RFC 9901</dd>
            <dt pn="section-11.2.3-2.17">Applications that use this media type:</dt>
            <dd pn="section-11.2.3-2.18">Applications utilizing a JWT-based proof-of-possession mechanism.</dd>
            <dt pn="section-11.2.3-2.19">Fragment identifier considerations:</dt>
            <dd pn="section-11.2.3-2.20">n/a</dd>
            <dt pn="section-11.2.3-2.21">Additional information:</dt>
            <dd pn="section-11.2.3-2.22">
              <t indent="0" pn="section-11.2.3-2.22.1"><br/></t>
              <dl spacing="compact" indent="3" newline="false" pn="section-11.2.3-2.22.2">
                <dt pn="section-11.2.3-2.22.2.1">Magic number(s):</dt>
                <dd pn="section-11.2.3-2.22.2.2">n/a</dd>
                <dt pn="section-11.2.3-2.22.2.3">File extension(s):</dt>
                <dd pn="section-11.2.3-2.22.2.4">n/a</dd>
                <dt pn="section-11.2.3-2.22.2.5">Macintosh file type code(s):</dt>
                <dd pn="section-11.2.3-2.22.2.6">n/a</dd>
              </dl>
            </dd>
            <dt pn="section-11.2.3-2.23">Person &amp; email address to contact for further information:</dt>
            <dd pn="section-11.2.3-2.24">Daniel Fett, mail@danielfett.de</dd>
            <dt pn="section-11.2.3-2.25">Intended usage:</dt>
            <dd pn="section-11.2.3-2.26">COMMON</dd>
            <dt pn="section-11.2.3-2.27">Restrictions on usage:</dt>
            <dd pn="section-11.2.3-2.28">none</dd>
            <dt pn="section-11.2.3-2.29">Author:</dt>
            <dd pn="section-11.2.3-2.30">Daniel Fett, mail@danielfett.de</dd>
            <dt pn="section-11.2.3-2.31">Change Controller:</dt>
            <dd pn="section-11.2.3-2.32">IETF</dd>
          </dl>
        </section>
      </section>
      <section anchor="structured-syntax-suffix-registration" numbered="true" removeInRFC="false" toc="include" pn="section-11.3">
        <name slugifiedName="name-structured-syntax-suffixes-">Structured Syntax Suffixes Registration</name>
        <t indent="0" pn="section-11.3-1">IANA has registered "+sd-jwt" in
the "Structured Syntax Suffixes" registry <xref target="StructuredSuffix" format="default" sectionFormat="of" derivedContent="StructuredSuffix"/> in
the manner described in <xref target="RFC6838" format="default" sectionFormat="of" derivedContent="RFC6838"/>, which can be used to indicate that
the media type is encoded as an SD-JWT.</t>
        <dl spacing="normal" indent="3" newline="false" pn="section-11.3-2">
          <dt pn="section-11.3-2.1">Name:</dt>
          <dd pn="section-11.3-2.2">SD-JWT</dd>
          <dt pn="section-11.3-2.3">+suffix:</dt>
          <dd pn="section-11.3-2.4">+sd-jwt</dd>
          <dt pn="section-11.3-2.5">References:</dt>
          <dd pn="section-11.3-2.6">RFC 9901</dd>
          <dt pn="section-11.3-2.7">Encoding considerations:</dt>
          <dd pn="section-11.3-2.8">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.</dd>
          <dt pn="section-11.3-2.9">Interoperability considerations:</dt>
          <dd pn="section-11.3-2.10">n/a</dd>
          <dt pn="section-11.3-2.11">Fragment identifier considerations:</dt>
          <dd pn="section-11.3-2.12">n/a</dd>
          <dt pn="section-11.3-2.13">Security considerations:</dt>
          <dd pn="section-11.3-2.14">See the Security Considerations sections of RFC 9901, <xref target="RFC7519" format="default" sectionFormat="of" derivedContent="RFC7519"/>, and <xref target="RFC8725" format="default" sectionFormat="of" derivedContent="RFC8725"/>.</dd>
          <dt pn="section-11.3-2.15">Contact:</dt>
          <dd pn="section-11.3-2.16">Daniel Fett, mail@danielfett.de</dd>
          <dt pn="section-11.3-2.17">Author/Change controller:</dt>
          <dd pn="section-11.3-2.18">IETF</dd>
        </dl>
      </section>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-oauth-sd-jwt-vc" to="SD-JWT-VC"/>
    <displayreference target="I-D.ietf-oauth-status-list" to="TSL"/>
    <displayreference target="I-D.ietf-spice-sd-cwt" to="SD-CWT"/>
    <references pn="section-12">
      <name slugifiedName="name-references">References</name>
      <references pn="section-12.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5234" quoteTitle="true" derivedAnchor="RFC5234">
          <front>
            <title>Augmented BNF for Syntax Specifications: ABNF</title>
            <author fullname="D. Crocker" initials="D." role="editor" surname="Crocker"/>
            <author fullname="P. Overell" initials="P." surname="Overell"/>
            <date month="January" year="2008"/>
            <abstract>
              <t indent="0">Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="68"/>
          <seriesInfo name="RFC" value="5234"/>
          <seriesInfo name="DOI" value="10.17487/RFC5234"/>
        </reference>
        <reference anchor="RFC6838" target="https://www.rfc-editor.org/info/rfc6838" quoteTitle="true" derivedAnchor="RFC6838">
          <front>
            <title>Media Type Specifications and Registration Procedures</title>
            <author fullname="N. Freed" initials="N." surname="Freed"/>
            <author fullname="J. Klensin" initials="J." surname="Klensin"/>
            <author fullname="T. Hansen" initials="T." surname="Hansen"/>
            <date month="January" year="2013"/>
            <abstract>
              <t indent="0">This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="13"/>
          <seriesInfo name="RFC" value="6838"/>
          <seriesInfo name="DOI" value="10.17487/RFC6838"/>
        </reference>
        <reference anchor="RFC7515" target="https://www.rfc-editor.org/info/rfc7515" quoteTitle="true" derivedAnchor="RFC7515">
          <front>
            <title>JSON Web Signature (JWS)</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <author fullname="J. Bradley" initials="J." surname="Bradley"/>
            <author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
            <date month="May" year="2015"/>
            <abstract>
              <t indent="0">JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7515"/>
          <seriesInfo name="DOI" value="10.17487/RFC7515"/>
        </reference>
        <reference anchor="RFC7516" target="https://www.rfc-editor.org/info/rfc7516" quoteTitle="true" derivedAnchor="RFC7516">
          <front>
            <title>JSON Web Encryption (JWE)</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <author fullname="J. Hildebrand" initials="J." surname="Hildebrand"/>
            <date month="May" year="2015"/>
            <abstract>
              <t indent="0">JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7516"/>
          <seriesInfo name="DOI" value="10.17487/RFC7516"/>
        </reference>
        <reference anchor="RFC7519" target="https://www.rfc-editor.org/info/rfc7519" quoteTitle="true" derivedAnchor="RFC7519">
          <front>
            <title>JSON Web Token (JWT)</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <author fullname="J. Bradley" initials="J." surname="Bradley"/>
            <author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
            <date month="May" year="2015"/>
            <abstract>
              <t indent="0">JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7519"/>
          <seriesInfo name="DOI" value="10.17487/RFC7519"/>
        </reference>
        <reference anchor="RFC7800" target="https://www.rfc-editor.org/info/rfc7800" quoteTitle="true" derivedAnchor="RFC7800">
          <front>
            <title>Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <author fullname="J. Bradley" initials="J." surname="Bradley"/>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
            <date month="April" year="2016"/>
            <abstract>
              <t indent="0">This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7800"/>
          <seriesInfo name="DOI" value="10.17487/RFC7800"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8725" target="https://www.rfc-editor.org/info/rfc8725" quoteTitle="true" derivedAnchor="RFC8725">
          <front>
            <title>JSON Web Token Best Current Practices</title>
            <author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
            <author fullname="D. Hardt" initials="D." surname="Hardt"/>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <date month="February" year="2020"/>
            <abstract>
              <t indent="0">JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="225"/>
          <seriesInfo name="RFC" value="8725"/>
          <seriesInfo name="DOI" value="10.17487/RFC8725"/>
        </reference>
      </references>
      <references pn="section-12.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="CL01" target="https://eprint.iacr.org/2001/019.pdf" quoteTitle="true" derivedAnchor="CL01">
          <front>
            <title>An Efficient System for Non-Transferable Anonymous Credentials with Optional Anonymity Revocation</title>
            <author fullname="Jan Camenisch" initials="J." surname="Camenisch">
              <organization showOnFrontPage="true">IBM Research</organization>
            </author>
            <author fullname="Anna Lysyanskaya" initials="A." surname="Lysyanskaya">
              <organization showOnFrontPage="true">MIT</organization>
            </author>
            <date year="2001"/>
          </front>
          <refcontent>Cryptology ePrint Archive, Paper 2001/019</refcontent>
        </reference>
        <reference anchor="Hash.Algs" target="https://www.iana.org/assignments/named-information" quoteTitle="true" derivedAnchor="Hash.Algs">
          <front>
            <title>Named Information Hash Algorithm Registry</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="ISO.18013-5" target="https://www.iso.org/standard/69084.html" quoteTitle="true" derivedAnchor="ISO.18013-5">
          <front>
            <title>Personal identification - ISO-compliant driving license - Part 5: Mobile driving license (mDL) application</title>
            <author>
              <organization showOnFrontPage="true">ISO/IEC</organization>
            </author>
            <date month="September" year="2021"/>
          </front>
          <seriesInfo name="ISO/IEC" value="18013-5:2021"/>
        </reference>
        <reference anchor="JWS.Algs" target="https://www.iana.org/assignments/jose" quoteTitle="true" derivedAnchor="JWS.Algs">
          <front>
            <title>JSON Web Signature and Encryption Algorithms</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="JWT.Claims" target="https://www.iana.org/assignments/jwt" quoteTitle="true" derivedAnchor="JWT.Claims">
          <front>
            <title>JSON Web Token Claims</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="MediaTypes" target="https://www.iana.org/assignments/media-types" quoteTitle="true" derivedAnchor="MediaTypes">
          <front>
            <title>Media Types</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="NIST.SP.800-57pt1r5" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf" quoteTitle="true" derivedAnchor="NIST.SP.800-57pt1r5">
          <front>
            <title>Recommendation for Key Management: Part 1 - General</title>
            <author fullname="Elaine Barker" surname="Barker">
              <organization showOnFrontPage="true">Information Technology Laboratory</organization>
            </author>
            <date year="2020" month="May"/>
          </front>
          <seriesInfo name="NIST SP" value="800-57pt1r5"/>
          <seriesInfo name="DOI" value="10.6028/NIST.SP.800-57pt1r5"/>
        </reference>
        <reference anchor="OIDC.IDA" target="https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html" quoteTitle="true" derivedAnchor="OIDC.IDA">
          <front>
            <title>OpenID Connect for Identity Assurance 1.0</title>
            <author fullname="Torsten Lodderstedt" initials="T." surname="Lodderstedt">
              <organization showOnFrontPage="true">yes.com</organization>
            </author>
            <author fullname="Daniel Fett" initials="D." surname="Fett">
              <organization showOnFrontPage="true">yes.com</organization>
            </author>
            <author fullname="Mark Haine" initials="M." surname="Haine">
              <organization showOnFrontPage="true">Considrd.Consulting Ltd</organization>
            </author>
            <author fullname="Alberto Pulido" initials="A." surname="Pulido">
              <organization showOnFrontPage="true">Santander</organization>
            </author>
            <author fullname="Kai Lehmann" initials="K." surname="Lehmann">
              <organization showOnFrontPage="true">1&amp;1 Mail &amp; Media Development &amp; Technology GmbH</organization>
            </author>
            <author fullname="Kosuke Koiwai" initials="K." surname="Koiwai">
              <organization showOnFrontPage="true">KDDI Corporation</organization>
            </author>
            <date year="2024" month="Oct" day="1"/>
          </front>
        </reference>
        <reference anchor="OpenID.Core" target="https://openid.net/specs/openid-connect-core-1_0.html" quoteTitle="true" derivedAnchor="OpenID.Core">
          <front>
            <title>OpenID Connect Core 1.0 incorporating errata set 2</title>
            <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
              <organization abbrev="NAT.Consulting (was at NRI)" showOnFrontPage="true">NAT.Consulting</organization>
            </author>
            <author fullname="John Bradley" initials="J." surname="Bradley">
              <organization abbrev="Yubico (was at Ping Identity)" showOnFrontPage="true">Yubico</organization>
            </author>
            <author fullname="Mike Jones" initials="M." surname="Jones">
              <organization abbrev="Self-Issued Consulting (was at Microsoft)" showOnFrontPage="true">Self-Issued Consulting</organization>
            </author>
            <author fullname="Breno de Medeiros" initials="B." surname="de Medeiros">
              <organization showOnFrontPage="true">Google</organization>
            </author>
            <author fullname="Chuck Mortimore" initials="C." surname="Mortimore">
              <organization abbrev="Disney (was at Salesforce)" showOnFrontPage="true">Disney</organization>
            </author>
            <date year="2023" month="Dec" day="15"/>
          </front>
        </reference>
        <reference anchor="RFC2046" target="https://www.rfc-editor.org/info/rfc2046" quoteTitle="true" derivedAnchor="RFC2046">
          <front>
            <title>Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title>
            <author fullname="N. Freed" initials="N." surname="Freed"/>
            <author fullname="N. Borenstein" initials="N." surname="Borenstein"/>
            <date month="November" year="1996"/>
            <abstract>
              <t indent="0">This second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2046"/>
          <seriesInfo name="DOI" value="10.17487/RFC2046"/>
        </reference>
        <reference anchor="RFC4086" target="https://www.rfc-editor.org/info/rfc4086" quoteTitle="true" derivedAnchor="RFC4086">
          <front>
            <title>Randomness Requirements for Security</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <author fullname="J. Schiller" initials="J." surname="Schiller"/>
            <author fullname="S. Crocker" initials="S." surname="Crocker"/>
            <date month="June" year="2005"/>
            <abstract>
              <t indent="0">Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.</t>
              <t indent="0">Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="106"/>
          <seriesInfo name="RFC" value="4086"/>
          <seriesInfo name="DOI" value="10.17487/RFC4086"/>
        </reference>
        <reference anchor="RFC7517" target="https://www.rfc-editor.org/info/rfc7517" quoteTitle="true" derivedAnchor="RFC7517">
          <front>
            <title>JSON Web Key (JWK)</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <date month="May" year="2015"/>
            <abstract>
              <t indent="0">A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7517"/>
          <seriesInfo name="DOI" value="10.17487/RFC7517"/>
        </reference>
        <reference anchor="RFC8785" target="https://www.rfc-editor.org/info/rfc8785" quoteTitle="true" derivedAnchor="RFC8785">
          <front>
            <title>JSON Canonicalization Scheme (JCS)</title>
            <author fullname="A. Rundgren" initials="A." surname="Rundgren"/>
            <author fullname="B. Jordan" initials="B." surname="Jordan"/>
            <author fullname="S. Erdtman" initials="S." surname="Erdtman"/>
            <date month="June" year="2020"/>
            <abstract>
              <t indent="0">Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results.</t>
              <t indent="0">This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8785"/>
          <seriesInfo name="DOI" value="10.17487/RFC8785"/>
        </reference>
        <reference anchor="I-D.ietf-spice-sd-cwt" target="https://datatracker.ietf.org/doc/html/draft-ietf-spice-sd-cwt-05" quoteTitle="true" derivedAnchor="SD-CWT">
          <front>
            <title>Selective Disclosure CBOR Web Tokens (SD-CWT)</title>
            <author fullname="Michael Prorock" initials="M." surname="Prorock">
              <organization showOnFrontPage="true">mesur.io</organization>
            </author>
            <author fullname="Orie Steele" initials="O." surname="Steele">
              <organization showOnFrontPage="true">Tradeverifyd</organization>
            </author>
            <author fullname="Henk Birkholz" initials="H." surname="Birkholz">
              <organization showOnFrontPage="true">Fraunhofer SIT</organization>
            </author>
            <author fullname="Rohan Mahy" initials="R." surname="Mahy"/>
            <date day="20" month="October" year="2025"/>
            <abstract>
              <t indent="0">This specification describes a data minimization technique for use with CBOR Web Tokens (CWTs). The approach is based on the Selective Disclosure JSON Web Token (SD-JWT), with changes to align with CBOR Object Signing and Encryption (COSE) and CWTs.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-spice-sd-cwt-05"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.ietf-oauth-sd-jwt-vc" target="https://datatracker.ietf.org/doc/html/draft-ietf-oauth-sd-jwt-vc-13" quoteTitle="true" derivedAnchor="SD-JWT-VC">
          <front>
            <title>SD-JWT-based Verifiable Credentials (SD-JWT VC)</title>
            <author fullname="Oliver Terbu" initials="O." surname="Terbu">
              <organization showOnFrontPage="true">MATTR</organization>
            </author>
            <author fullname="Daniel Fett" initials="D." surname="Fett">
              <organization showOnFrontPage="true">Authlete Inc.</organization>
            </author>
            <author fullname="Brian Campbell" initials="B." surname="Campbell">
              <organization showOnFrontPage="true">Ping Identity</organization>
            </author>
            <date day="6" month="November" year="2025"/>
            <abstract>
              <t indent="0">This specification describes data formats as well as validation and processing rules to express Verifiable Credentials with JSON payloads with and without selective disclosure based on the SD-JWT [I-D.ietf-oauth-selective-disclosure-jwt] format.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-oauth-sd-jwt-vc-13"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="StructuredSuffix" target="https://www.iana.org/assignments/media-type-structured-suffix" quoteTitle="true" derivedAnchor="StructuredSuffix">
          <front>
            <title>Structured Syntax Suffixes</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="I-D.ietf-oauth-status-list" target="https://datatracker.ietf.org/doc/html/draft-ietf-oauth-status-list-13" quoteTitle="true" derivedAnchor="TSL">
          <front>
            <title>Token Status List (TSL)</title>
            <author fullname="Tobias Looker" initials="T." surname="Looker">
              <organization showOnFrontPage="true">MATTR</organization>
            </author>
            <author fullname="Paul Bastian" initials="P." surname="Bastian">
              <organization showOnFrontPage="true">Bundesdruckerei</organization>
            </author>
            <author fullname="Christian Bormann" initials="C." surname="Bormann">
              <organization showOnFrontPage="true">SPRIND</organization>
            </author>
            <date day="20" month="October" year="2025"/>
            <abstract>
              <t indent="0">This specification defines a mechanism called Token Status List (abbreviated TSL), data structures and processing rules for representing the status of tokens secured by JSON Object Signing and Encryption (JOSE) or CBOR Object Signing and Encryption (COSE), such as JWT, SD-JWT VC, CBOR Web Token and ISO mdoc. It also defines an extension point and a registry for future status mechanisms.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-oauth-status-list-13"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="VC_DATA_v2.0" target="https://www.w3.org/TR/vc-data-model-2.0/" quoteTitle="true" derivedAnchor="VC_DATA_v2.0">
          <front>
            <title>Verifiable Credentials Data Model 2.0</title>
            <author fullname="Manu Sporny" role="editor">
              <organization showOnFrontPage="true">Digital Bazaar</organization>
            </author>
            <author fullname="Ted Thiboeau" role="editor">
              <organization showOnFrontPage="true">OpenLink Software</organization>
            </author>
            <author fullname="Michael B. Jones" role="editor">
              <organization showOnFrontPage="true">Invited Expert</organization>
            </author>
            <author fullname="Gabe Cohen" role="editor">
              <organization showOnFrontPage="true">Block</organization>
            </author>
            <author fullname="Ivan Herman" role="editor">
              <organization showOnFrontPage="true">W3C</organization>
            </author>
            <date year="2025" month="May"/>
          </front>
          <refcontent>W3C Recommendation</refcontent>
        </reference>
      </references>
    </references>
    <section anchor="additional-examples" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-additional-examples">Additional Examples</name>
      <t indent="0" pn="section-appendix.a-1">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.</t>
      <t indent="0" pn="section-appendix.a-2">Line breaks have been added for readability.</t>
      <section anchor="example-simple_structured" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.1">
        <name slugifiedName="name-simple-structured-sd-jwt">Simple Structured SD-JWT</name>
        <t indent="0" pn="section-appendix.a.1-1">In this example, in contrast to <xref target="main-example" format="default" sectionFormat="of" derivedContent="Section 5"/>, the Issuer decided to create a structured object for the <tt>address</tt> claim, allowing individual members of the claim to be disclosed separately. 
</t>
        <t indent="0" pn="section-appendix.a.1-2">The following data about the user comprises the input JWT Claims Set used by the Issuer:</t>
        <sourcecode type="json" markers="false" pn="section-appendix.a.1-3">
{
  "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": "東京都港区芝公園４丁目２−８",
    "locality": "東京都",
    "region": "港区",
    "country": "JP"
  },
  "birthdate": "1940-01-01"
}
</sourcecode>
        <t indent="0" pn="section-appendix.a.1-4">The Issuer also decided to add decoy digests to prevent the Verifier from deducing the true number of claims.</t>
        <t indent="0" pn="section-appendix.a.1-5">The following payload is used for the SD-JWT:</t>
        <sourcecode type="json" markers="false" pn="section-appendix.a.1-6">
{
  "_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"
}
</sourcecode>
        <t indent="0" pn="section-appendix.a.1-7">The digests in the SD-JWT payload reference the following Disclosures:</t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-appendix.a.1-8">
          <li pn="section-appendix.a.1-8.1">
            <t indent="0" pn="section-appendix.a.1-8.1.1">Claim <tt>sub</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.1-8.1.2">
              <li pn="section-appendix.a.1-8.1.2.1">
                <t indent="0" pn="section-appendix.a.1-8.1.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.1-8.1.2.1.2"><tt>X6ZAYOII2vPN40V7xExZwVwz7yRmLNcVwt5DL8RLv4g</tt></t>
              </li>
              <li pn="section-appendix.a.1-8.1.2.2">
                <t indent="0" pn="section-appendix.a.1-8.1.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.1-8.1.2.2.2"><tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN1YiIsICI2YzVjMGE0OS1iNTg5LTQzMWQtYmFlNy0yMTkxMjJhOWVjMmMiXQ</tt></t>
              </li>
              <li pn="section-appendix.a.1-8.1.2.3">
                <t indent="0" pn="section-appendix.a.1-8.1.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.1-8.1.2.3.2"><tt>["2GLC42sKQveCfGfryNRN9w", "sub", "6c5c0a49-b589-431d-bae7-219122a9ec2c"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.1-8.2">
            <t indent="0" pn="section-appendix.a.1-8.2.1">Claim <tt>given_name</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.1-8.2.2">
              <li pn="section-appendix.a.1-8.2.2.1">
                <t indent="0" pn="section-appendix.a.1-8.2.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.1-8.2.2.1.2"><tt>ommFAicVT8LGHCB0uywx7fYuo3MHYKO15cz-RZEYM5Q</tt></t>
              </li>
              <li pn="section-appendix.a.1-8.2.2.2">
                <t indent="0" pn="section-appendix.a.1-8.2.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.1-8.2.2.2.2"><tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiXHU1OTJhXHU5MGNlIl0</tt></t>
              </li>
              <li pn="section-appendix.a.1-8.2.2.3">
                <t indent="0" pn="section-appendix.a.1-8.2.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.1-8.2.2.3.2"><tt>["eluV5Og3gSNII8EYnsxA_A", "given_name", "\u592a\u90ce"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.1-8.3">
            <t indent="0" pn="section-appendix.a.1-8.3.1">Claim <tt>family_name</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.1-8.3.2">
              <li pn="section-appendix.a.1-8.3.2.1">
                <t indent="0" pn="section-appendix.a.1-8.3.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.1-8.3.2.1.2"><tt>C9inp6YoRaEXR427zYJP7Qrk1WH_8bdwOA_YUrUnGQU</tt></t>
              </li>
              <li pn="section-appendix.a.1-8.3.2.2">
                <t indent="0" pn="section-appendix.a.1-8.3.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.1-8.3.2.2.2"><tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIlx1NWM3MVx1NzUzMCJd</tt></t>
              </li>
              <li pn="section-appendix.a.1-8.3.2.3">
                <t indent="0" pn="section-appendix.a.1-8.3.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.1-8.3.2.3.2"><tt>["6Ij7tM-a5iVPGboS5tmvVA", "family_name", "\u5c71\u7530"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.1-8.4">
            <t indent="0" pn="section-appendix.a.1-8.4.1">Claim <tt>email</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.1-8.4.2">
              <li pn="section-appendix.a.1-8.4.2.1">
                <t indent="0" pn="section-appendix.a.1-8.4.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.1-8.4.2.1.2"><tt>Kuet1yAa0HIQvYnOVd59hcViO9Ug6J2kSfqYRBeowvE</tt></t>
              </li>
              <li pn="section-appendix.a.1-8.4.2.2">
                <t indent="0" pn="section-appendix.a.1-8.4.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.1-8.4.2.2.2"><tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImVtYWlsIiwgIlwidW51c3VhbCBlbWFpbCBhZGRyZXNzXCJAZXhhbXBsZS5qcCJd</tt></t>
              </li>
              <li pn="section-appendix.a.1-8.4.2.3">
                <t indent="0" pn="section-appendix.a.1-8.4.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.1-8.4.2.3.2"><tt>["eI8ZWm9QnKPpNPeNenHdhQ", "email", "\"unusual email address\"@example.jp"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.1-8.5">
            <t indent="0" pn="section-appendix.a.1-8.5.1">Claim <tt>phone_number</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.1-8.5.2">
              <li pn="section-appendix.a.1-8.5.2.1">
                <t indent="0" pn="section-appendix.a.1-8.5.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.1-8.5.2.1.2"><tt>s0BKYsLWxQQeU8tVlltM7MKsIRTrEIa1PkJmqxBBf5U</tt></t>
              </li>
              <li pn="section-appendix.a.1-8.5.2.2">
                <t indent="0" pn="section-appendix.a.1-8.5.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.1-8.5.2.2.2"><tt>WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJlciIsICIrODEtODAtMTIzNC01Njc4Il0</tt></t>
              </li>
              <li pn="section-appendix.a.1-8.5.2.3">
                <t indent="0" pn="section-appendix.a.1-8.5.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.1-8.5.2.3.2"><tt>["Qg_O64zqAxe412a108iroA", "phone_number", "+81-80-1234-5678"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.1-8.6">
            <t indent="0" pn="section-appendix.a.1-8.6.1">Claim <tt>street_address</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.1-8.6.2">
              <li pn="section-appendix.a.1-8.6.2.1">
                <t indent="0" pn="section-appendix.a.1-8.6.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.1-8.6.2.1.2"><tt>6aUhzYhZ7SJ1kVmagQAO3u2ETN2CC1aHheZpKnaF0_E</tt></t>
              </li>
              <li pn="section-appendix.a.1-8.6.2.2">
                <t indent="0" pn="section-appendix.a.1-8.6.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.1-8.6.2.2.2"><tt>WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInN0cmVldF9hZGRyZXNzIiwgIlx1Njc3MVx1NGVhY1x1OTBmZFx1NmUyZlx1NTMzYVx1ODI5ZFx1NTE2Y1x1NTcxMlx1ZmYxNFx1NGUwMVx1NzZlZVx1ZmYxMlx1MjIxMlx1ZmYxOCJd</tt></t>
              </li>
              <li pn="section-appendix.a.1-8.6.2.3">
                <t indent="0" pn="section-appendix.a.1-8.6.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.1-8.6.2.3.2"><tt>["AJx-095VPrpTtN4QMOqROA", "street_address", "\u6771\u4eac\u90fd\u6e2f\u533a\u829d\u516c\u5712\uff14\u4e01\u76ee\uff12\u2212\uff18"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.1-8.7">
            <t indent="0" pn="section-appendix.a.1-8.7.1">Claim <tt>locality</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.1-8.7.2">
              <li pn="section-appendix.a.1-8.7.2.1">
                <t indent="0" pn="section-appendix.a.1-8.7.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.1-8.7.2.1.2"><tt>rvJd6iq6T5ejmsBMoGwuNXh9qAAFATAci40oidEeVsA</tt></t>
              </li>
              <li pn="section-appendix.a.1-8.7.2.2">
                <t indent="0" pn="section-appendix.a.1-8.7.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.1-8.7.2.2.2"><tt>WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImxvY2FsaXR5IiwgIlx1Njc3MVx1NGVhY1x1OTBmZCJd</tt></t>
              </li>
              <li pn="section-appendix.a.1-8.7.2.3">
                <t indent="0" pn="section-appendix.a.1-8.7.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.1-8.7.2.3.2"><tt>["Pc33JM2LchcU_lHggv_ufQ", "locality", "\u6771\u4eac\u90fd"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.1-8.8">
            <t indent="0" pn="section-appendix.a.1-8.8.1">Claim <tt>region</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.1-8.8.2">
              <li pn="section-appendix.a.1-8.8.2.1">
                <t indent="0" pn="section-appendix.a.1-8.8.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.1-8.8.2.1.2"><tt>PzzcVu0qbMuBGSjulfewzkesD9zutOExn5EWNwkrQ-k</tt></t>
              </li>
              <li pn="section-appendix.a.1-8.8.2.2">
                <t indent="0" pn="section-appendix.a.1-8.8.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.1-8.8.2.2.2"><tt>WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInJlZ2lvbiIsICJcdTZlMmZcdTUzM2EiXQ</tt></t>
              </li>
              <li pn="section-appendix.a.1-8.8.2.3">
                <t indent="0" pn="section-appendix.a.1-8.8.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.1-8.8.2.3.2"><tt>["G02NSrQfjFXQ7Io09syajA", "region", "\u6e2f\u533a"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.1-8.9">
            <t indent="0" pn="section-appendix.a.1-8.9.1">Claim <tt>country</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.1-8.9.2">
              <li pn="section-appendix.a.1-8.9.2.1">
                <t indent="0" pn="section-appendix.a.1-8.9.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.1-8.9.2.1.2"><tt>uNHoWYhXsZhVJCNE2Dqy-zqt7t69gJKy5QaFv7GrMX4</tt></t>
              </li>
              <li pn="section-appendix.a.1-8.9.2.2">
                <t indent="0" pn="section-appendix.a.1-8.9.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.1-8.9.2.2.2"><tt>WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImNvdW50cnkiLCAiSlAiXQ</tt></t>
              </li>
              <li pn="section-appendix.a.1-8.9.2.3">
                <t indent="0" pn="section-appendix.a.1-8.9.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.1-8.9.2.3.2"><tt>["lklxF5jMYlGTPUovMNIvCA", "country", "JP"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.1-8.10">
            <t indent="0" pn="section-appendix.a.1-8.10.1">Claim <tt>birthdate</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.1-8.10.2">
              <li pn="section-appendix.a.1-8.10.2.1">
                <t indent="0" pn="section-appendix.a.1-8.10.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.1-8.10.2.1.2"><tt>MMldOFFzB2d0umlmpTIaGerhWdU_PpYfLvKhh_f_9aY</tt></t>
              </li>
              <li pn="section-appendix.a.1-8.10.2.2">
                <t indent="0" pn="section-appendix.a.1-8.10.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.1-8.10.2.2.2"><tt>WyJ5eXRWYmRBUEdjZ2wyckk0QzlHU29nIiwgImJpcnRoZGF0ZSIsICIxOTQwLTAxLTAxIl0</tt></t>
              </li>
              <li pn="section-appendix.a.1-8.10.2.3">
                <t indent="0" pn="section-appendix.a.1-8.10.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.1-8.10.2.3.2"><tt>["yytVbdAPGcgl2rI4C9GSog", "birthdate", "1940-01-01"]</tt></t>
              </li>
            </ul>
          </li>
        </ul>
        <t indent="0" pn="section-appendix.a.1-9">The following decoy digests are added:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.1-10">
          <li pn="section-appendix.a.1-10.1">
            <tt>AzLlFobkJ2xiaupREPyoJz-9-NSldB6Cgjr7fUyoHzg</tt></li>
          <li pn="section-appendix.a.1-10.2">
            <tt>cPYJHIZ8Vu-f9CCyVub2UfgEk8jvvXezwK1p_JneeXQ</tt></li>
          <li pn="section-appendix.a.1-10.3">
            <tt>glT3hrSU7fSWgwF5UDZmWwBTw32gnUldIhi8hGVCaV4</tt></li>
          <li pn="section-appendix.a.1-10.4">
            <tt>b2Dkw0jcIF9rGg8_PF8ZcvncW7zwZj5ryBWvXfrpzek</tt></li>
          <li pn="section-appendix.a.1-10.5">
            <tt>fyGp0WTwwPv2JDQln1lSiaeobZsMWA10bQ5989-9DTs</tt></li>
          <li pn="section-appendix.a.1-10.6">
            <tt>Y34zmIo0QLLOtdMpXGwjBgLvr17yEhhYT0FGofR-aIE</tt></li>
        </ul>
        <t indent="0" pn="section-appendix.a.1-11">The following is a presentation of the SD-JWT that discloses only <tt>region</tt>
and <tt>country</tt> of the <tt>address</tt> property:</t>
        <sourcecode type="" markers="false" pn="section-appendix.a.1-12">
eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb
IkM5aW5wNllvUmFFWFI0Mjd6WUpQN1FyazFXSF84YmR3T0FfWVVyVW5HUVUiLCAiS3Vl
dDF5QWEwSElRdlluT1ZkNTloY1ZpTzlVZzZKMmtTZnFZUkJlb3d2RSIsICJNTWxkT0ZG
ekIyZDB1bWxtcFRJYUdlcmhXZFVfUHBZZkx2S2hoX2ZfOWFZIiwgIlg2WkFZT0lJMnZQ
TjQwVjd4RXhad1Z3ejd5Um1MTmNWd3Q1REw4Ukx2NGciLCAiWTM0em1JbzBRTExPdGRN
cFhHd2pCZ0x2cjE3eUVoaFlUMEZHb2ZSLWFJRSIsICJmeUdwMFdUd3dQdjJKRFFsbjFs
U2lhZW9iWnNNV0ExMGJRNTk4OS05RFRzIiwgIm9tbUZBaWNWVDhMR0hDQjB1eXd4N2ZZ
dW8zTUhZS08xNWN6LVJaRVlNNVEiLCAiczBCS1lzTFd4UVFlVTh0VmxsdE03TUtzSVJU
ckVJYTFQa0ptcXhCQmY1VSJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu
Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAiYWRkcmVz
cyI6IHsiX3NkIjogWyI2YVVoelloWjdTSjFrVm1hZ1FBTzN1MkVUTjJDQzFhSGhlWnBL
bmFGMF9FIiwgIkF6TGxGb2JrSjJ4aWF1cFJFUHlvSnotOS1OU2xkQjZDZ2pyN2ZVeW9I
emciLCAiUHp6Y1Z1MHFiTXVCR1NqdWxmZXd6a2VzRDl6dXRPRXhuNUVXTndrclEtayIs
ICJiMkRrdzBqY0lGOXJHZzhfUEY4WmN2bmNXN3p3Wmo1cnlCV3ZYZnJwemVrIiwgImNQ
WUpISVo4VnUtZjlDQ3lWdWIyVWZnRWs4anZ2WGV6d0sxcF9KbmVlWFEiLCAiZ2xUM2hy
U1U3ZlNXZ3dGNVVEWm1Xd0JUdzMyZ25VbGRJaGk4aEdWQ2FWNCIsICJydkpkNmlxNlQ1
ZWptc0JNb0d3dU5YaDlxQUFGQVRBY2k0MG9pZEVlVnNBIiwgInVOSG9XWWhYc1poVkpD
TkUyRHF5LXpxdDd0NjlnSkt5NVFhRnY3R3JNWDQiXX0sICJfc2RfYWxnIjogInNoYS0y
NTYifQ.EOZa2YqK8j4i7cqBDkfPcTMaFsgPwcx3aYJkFoMfvV46LxL-PPqrWsIyNukB4
x8Y2LT31eIHDc4Wg4XNzaqu4w~WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInJlZ2
lvbiIsICJcdTZlMmZcdTUzM2EiXQ~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImN
vdW50cnkiLCAiSlAiXQ~
</sourcecode>
        <t indent="0" pn="section-appendix.a.1-13">After validation, the Verifier will have the following Processed SD-JWT Payload available for further handling:</t>
        <sourcecode type="json" markers="false" pn="section-appendix.a.1-14">
{
  "iss": "https://issuer.example.com",
  "iat": 1683000000,
  "exp": 1883000000,
  "address": {
    "region": "港区",
    "country": "JP"
  }
}
</sourcecode>
      </section>
      <section anchor="example-complex-structured-sd-jwt" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.2">
        <name slugifiedName="name-complex-structured-sd-jwt">Complex Structured SD-JWT</name>
        <t indent="0" pn="section-appendix.a.2-1">In this example, an SD-JWT with a complex object is represented. The data
structures defined in OpenID Connect for Identity Assurance <xref target="OIDC.IDA" format="default" sectionFormat="of" derivedContent="OIDC.IDA"/> are used.</t>
        <t indent="0" pn="section-appendix.a.2-2">The Issuer is using the following user data as the input JWT Claims Set:</t>
        <sourcecode type="json" markers="false" pn="section-appendix.a.2-3">
{
  "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"
}
</sourcecode>
        <t indent="0" pn="section-appendix.a.2-4">The following payload is used for the SD-JWT:</t>
        <sourcecode type="json" markers="false" pn="section-appendix.a.2-5">
{
  "_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"
}
</sourcecode>
        <t indent="0" pn="section-appendix.a.2-6">The digests in the SD-JWT payload reference the following Disclosures:</t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-appendix.a.2-7">
          <li pn="section-appendix.a.2-7.1">
            <t indent="0" pn="section-appendix.a.2-7.1.1">Claim <tt>time</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.2-7.1.2">
              <li pn="section-appendix.a.2-7.1.2.1">
                <t indent="0" pn="section-appendix.a.2-7.1.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.2-7.1.2.1.2"><tt>vTwe3raHIFYgFA3xaUD2aMxFz5oDo8iBu05qKlOg9Lw</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.1.2.2">
                <t indent="0" pn="section-appendix.a.2-7.1.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.2-7.1.2.2.2"><tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInRpbWUiLCAiMjAxMi0wNC0yM1QxODoyNVoiXQ</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.1.2.3">
                <t indent="0" pn="section-appendix.a.2-7.1.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.2-7.1.2.3.2"><tt>["2GLC42sKQveCfGfryNRN9w", "time", "2012-04-23T18:25Z"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.2-7.2">
            <t indent="0" pn="section-appendix.a.2-7.2.1">Claim <tt>verification_process</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.2-7.2.2">
              <li pn="section-appendix.a.2-7.2.2.1">
                <t indent="0" pn="section-appendix.a.2-7.2.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.2-7.2.2.1.2"><tt>7h4UE9qScvDKodXVCuoKfKBJpVBfXMF_TmAGVaZe3Sc</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.2.2.2">
                <t indent="0" pn="section-appendix.a.2-7.2.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.2-7.2.2.2.2"><tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgInZlcmlmaWNhdGlvbl9wcm9jZXNzIiwgImYyNGM2Zi02ZDNmLTRlYzUtOTczZS1iMGQ4NTA2ZjNiYzciXQ</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.2.2.3">
                <t indent="0" pn="section-appendix.a.2-7.2.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.2-7.2.2.3.2"><tt>["eluV5Og3gSNII8EYnsxA_A", "verification_process", "f24c6f-6d3f-4ec5-973e-b0d8506f3bc7"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.2-7.3">
            <t indent="0" pn="section-appendix.a.2-7.3.1">Claim <tt>type</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.2-7.3.2">
              <li pn="section-appendix.a.2-7.3.2.1">
                <t indent="0" pn="section-appendix.a.2-7.3.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.2-7.3.2.1.2"><tt>G5EnhOAOoU9X_6QMNvzFXjpEA_Rc-AEtm1bG_wcaKIk</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.3.2.2">
                <t indent="0" pn="section-appendix.a.2-7.3.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.2-7.3.2.2.2"><tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInR5cGUiLCAiZG9jdW1lbnQiXQ</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.3.2.3">
                <t indent="0" pn="section-appendix.a.2-7.3.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.2-7.3.2.3.2"><tt>["6Ij7tM-a5iVPGboS5tmvVA", "type", "document"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.2-7.4">
            <t indent="0" pn="section-appendix.a.2-7.4.1">Claim <tt>method</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.2-7.4.2">
              <li pn="section-appendix.a.2-7.4.2.1">
                <t indent="0" pn="section-appendix.a.2-7.4.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.2-7.4.2.1.2"><tt>WpxQ4HSoEtcTmCCKOeDslB_emucYLz2oO8oHNr1bEVQ</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.4.2.2">
                <t indent="0" pn="section-appendix.a.2-7.4.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.2-7.4.2.2.2"><tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm1ldGhvZCIsICJwaXBwIl0</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.4.2.3">
                <t indent="0" pn="section-appendix.a.2-7.4.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.2-7.4.2.3.2"><tt>["eI8ZWm9QnKPpNPeNenHdhQ", "method", "pipp"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.2-7.5">
            <t indent="0" pn="section-appendix.a.2-7.5.1">Claim <tt>time</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.2-7.5.2">
              <li pn="section-appendix.a.2-7.5.2.1">
                <t indent="0" pn="section-appendix.a.2-7.5.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.2-7.5.2.1.2"><tt>9wpjVPWuD7PK0nsQDL8B06lmdgV3LVybhHydQpTNyLI</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.5.2.2">
                <t indent="0" pn="section-appendix.a.2-7.5.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.2-7.5.2.2.2"><tt>WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInRpbWUiLCAiMjAxMi0wNC0yMlQxMTozMFoiXQ</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.5.2.3">
                <t indent="0" pn="section-appendix.a.2-7.5.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.2-7.5.2.3.2"><tt>["Qg_O64zqAxe412a108iroA", "time", "2012-04-22T11:30Z"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.2-7.6">
            <t indent="0" pn="section-appendix.a.2-7.6.1">Claim <tt>document</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.2-7.6.2">
              <li pn="section-appendix.a.2-7.6.2.1">
                <t indent="0" pn="section-appendix.a.2-7.6.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.2-7.6.2.1.2"><tt>IhwFrWUB63RcZq9yvgZ0XPc7Gowh3O2kqXeBIswg1B4</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.6.2.2">
                <t indent="0" pn="section-appendix.a.2-7.6.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.2-7.6.2.2.2"><tt>WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRvY3VtZW50IiwgeyJ0eXBlIjogImlkY2FyZCIsICJpc3N1ZXIiOiB7Im5hbWUiOiAiU3RhZHQgQXVnc2J1cmciLCAiY291bnRyeSI6ICJERSJ9LCAibnVtYmVyIjogIjUzNTU0NTU0IiwgImRhdGVfb2ZfaXNzdWFuY2UiOiAiMjAxMC0wMy0yMyIsICJkYXRlX29mX2V4cGlyeSI6ICIyMDIwLTAzLTIyIn1d</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.6.2.3">
                <t indent="0" pn="section-appendix.a.2-7.6.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.2-7.6.2.3.2"><tt>["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"}]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.2-7.7">
            <t indent="0" pn="section-appendix.a.2-7.7.1">Array Entry:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.2-7.7.2">
              <li pn="section-appendix.a.2-7.7.2.1">
                <t indent="0" pn="section-appendix.a.2-7.7.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.2-7.7.2.1.2"><tt>tYJ0TDucyZZCRMbROG4qRO5vkPSFRxFhUELc18CSl3k</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.7.2.2">
                <t indent="0" pn="section-appendix.a.2-7.7.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.2-7.7.2.2.2"><tt>WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgeyJfc2QiOiBbIjl3cGpWUFd1RDdQSzBuc1FETDhCMDZsbWRnVjNMVnliaEh5ZFFwVE55TEkiLCAiRzVFbmhPQU9vVTlYXzZRTU52ekZYanBFQV9SYy1BRXRtMWJHX3djYUtJayIsICJJaHdGcldVQjYzUmNacTl5dmdaMFhQYzdHb3doM08ya3FYZUJJc3dnMUI0IiwgIldweFE0SFNvRXRjVG1DQ0tPZURzbEJfZW11Y1lMejJvTzhvSE5yMWJFVlEiXX1d</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.7.2.3">
                <t indent="0" pn="section-appendix.a.2-7.7.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.2-7.7.2.3.2"><tt>["Pc33JM2LchcU_lHggv_ufQ", {"_sd": ["9wpjVPWuD7PK0nsQDL8B06lmdgV3LVybhHydQpTNyLI", "G5EnhOAOoU9X_6QMNvzFXjpEA_Rc-AEtm1bG_wcaKIk", "IhwFrWUB63RcZq9yvgZ0XPc7Gowh3O2kqXeBIswg1B4", "WpxQ4HSoEtcTmCCKOeDslB_emucYLz2oO8oHNr1bEVQ"]}]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.2-7.8">
            <t indent="0" pn="section-appendix.a.2-7.8.1">Claim <tt>given_name</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.2-7.8.2">
              <li pn="section-appendix.a.2-7.8.2.1">
                <t indent="0" pn="section-appendix.a.2-7.8.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.2-7.8.2.1.2"><tt>S_498bbpKzB6Eanftss0xc7cOaoneRr3pKr7NdRmsMo</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.8.2.2">
                <t indent="0" pn="section-appendix.a.2-7.8.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.2-7.8.2.2.2"><tt>WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdpdmVuX25hbWUiLCAiTWF4Il0</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.8.2.3">
                <t indent="0" pn="section-appendix.a.2-7.8.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.2-7.8.2.3.2"><tt>["G02NSrQfjFXQ7Io09syajA", "given_name", "Max"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.2-7.9">
            <t indent="0" pn="section-appendix.a.2-7.9.1">Claim <tt>family_name</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.2-7.9.2">
              <li pn="section-appendix.a.2-7.9.2.1">
                <t indent="0" pn="section-appendix.a.2-7.9.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.2-7.9.2.1.2"><tt>Wxh_sV3iRH9bgrTBJi-aYHNCLt-vjhX1sd-igOf_9lk</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.9.2.2">
                <t indent="0" pn="section-appendix.a.2-7.9.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.2-7.9.2.2.2"><tt>WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImZhbWlseV9uYW1lIiwgIk1cdTAwZmNsbGVyIl0</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.9.2.3">
                <t indent="0" pn="section-appendix.a.2-7.9.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.2-7.9.2.3.2"><tt>["lklxF5jMYlGTPUovMNIvCA", "family_name", "M\u00fcller"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.2-7.10">
            <t indent="0" pn="section-appendix.a.2-7.10.1">Claim <tt>nationalities</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.2-7.10.2">
              <li pn="section-appendix.a.2-7.10.2.1">
                <t indent="0" pn="section-appendix.a.2-7.10.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.2-7.10.2.1.2"><tt>hvDXhwmGcJQsBCA2OtjuLAcwAMpDsaU0nkovcKOqWNE</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.10.2.2">
                <t indent="0" pn="section-appendix.a.2-7.10.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.2-7.10.2.2.2"><tt>WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIm5hdGlvbmFsaXRpZXMiLCBbIkRFIl1d</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.10.2.3">
                <t indent="0" pn="section-appendix.a.2-7.10.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.2-7.10.2.3.2"><tt>["nPuoQnkRFq3BIeAm7AnXFA", "nationalities", ["DE"]]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.2-7.11">
            <t indent="0" pn="section-appendix.a.2-7.11.1">Claim <tt>birthdate</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.2-7.11.2">
              <li pn="section-appendix.a.2-7.11.2.1">
                <t indent="0" pn="section-appendix.a.2-7.11.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.2-7.11.2.1.2"><tt>WNA-UNK7F_zhsAb9syWO6IIQ1uHlTmOU8r8CvJ0cIMk</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.11.2.2">
                <t indent="0" pn="section-appendix.a.2-7.11.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.2-7.11.2.2.2"><tt>WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImJpcnRoZGF0ZSIsICIxOTU2LTAxLTI4Il0</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.11.2.3">
                <t indent="0" pn="section-appendix.a.2-7.11.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.2-7.11.2.3.2"><tt>["5bPs1IquZNa0hkaFzzzZNw", "birthdate", "1956-01-28"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.2-7.12">
            <t indent="0" pn="section-appendix.a.2-7.12.1">Claim <tt>place_of_birth</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.2-7.12.2">
              <li pn="section-appendix.a.2-7.12.2.1">
                <t indent="0" pn="section-appendix.a.2-7.12.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.2-7.12.2.1.2"><tt>RiOiCn6_w5ZHaadkQMrcQJf0Jte5RwurRs54231DTlo</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.12.2.2">
                <t indent="0" pn="section-appendix.a.2-7.12.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.2-7.12.2.2.2"><tt>WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgInBsYWNlX29mX2JpcnRoIiwgeyJjb3VudHJ5IjogIklTIiwgImxvY2FsaXR5IjogIlx1MDBkZXlra3ZhYlx1MDBlNmphcmtsYXVzdHVyIn1d</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.12.2.3">
                <t indent="0" pn="section-appendix.a.2-7.12.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.2-7.12.2.3.2"><tt>["5a2W0_NrlEZzfqmk_7Pq-w", "place_of_birth", {"country": "IS", "locality": "\u00deykkvab\u00e6jarklaustur"}]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.2-7.13">
            <t indent="0" pn="section-appendix.a.2-7.13.1">Claim <tt>address</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.2-7.13.2">
              <li pn="section-appendix.a.2-7.13.2.1">
                <t indent="0" pn="section-appendix.a.2-7.13.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.2-7.13.2.1.2"><tt>_O-wJiH3enSB4ROHntToQT8JmLtz-mhO2f1c89XoerQ</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.13.2.2">
                <t indent="0" pn="section-appendix.a.2-7.13.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.2-7.13.2.2.2"><tt>WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImFkZHJlc3MiLCB7ImxvY2FsaXR5IjogIk1heHN0YWR0IiwgInBvc3RhbF9jb2RlIjogIjEyMzQ0IiwgImNvdW50cnkiOiAiREUiLCAic3RyZWV0X2FkZHJlc3MiOiAiV2VpZGVuc3RyYVx1MDBkZmUgMjIifV0</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.13.2.3">
                <t indent="0" pn="section-appendix.a.2-7.13.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.2-7.13.2.3.2"><tt>["y1sVU5wdfJahVdgwPgS7RQ", "address", {"locality": "Maxstadt", "postal_code": "12344", "country": "DE", "street_address": "Weidenstra\u00dfe 22"}]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.2-7.14">
            <t indent="0" pn="section-appendix.a.2-7.14.1">Claim <tt>birth_middle_name</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.2-7.14.2">
              <li pn="section-appendix.a.2-7.14.2.1">
                <t indent="0" pn="section-appendix.a.2-7.14.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.2-7.14.2.1.2"><tt>otkxuT14nBiwzNJ3MPaOitOl9pVnXOaEHal_xkyNfKI</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.14.2.2">
                <t indent="0" pn="section-appendix.a.2-7.14.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.2-7.14.2.2.2"><tt>WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImJpcnRoX21pZGRsZV9uYW1lIiwgIlRpbW90aGV1cyJd</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.14.2.3">
                <t indent="0" pn="section-appendix.a.2-7.14.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.2-7.14.2.3.2"><tt>["HbQ4X8srVW3QDxnIJdqyOA", "birth_middle_name", "Timotheus"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.2-7.15">
            <t indent="0" pn="section-appendix.a.2-7.15.1">Claim <tt>salutation</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.2-7.15.2">
              <li pn="section-appendix.a.2-7.15.2.1">
                <t indent="0" pn="section-appendix.a.2-7.15.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.2-7.15.2.1.2"><tt>-aSznId9mWM8ocuQolCllsxVggq1-vHW4OtnhUtVmWw</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.15.2.2">
                <t indent="0" pn="section-appendix.a.2-7.15.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.2-7.15.2.2.2"><tt>WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgInNhbHV0YXRpb24iLCAiRHIuIl0</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.15.2.3">
                <t indent="0" pn="section-appendix.a.2-7.15.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.2-7.15.2.3.2"><tt>["C9GSoujviJquEgYfojCb1A", "salutation", "Dr."]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.2-7.16">
            <t indent="0" pn="section-appendix.a.2-7.16.1">Claim <tt>msisdn</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.2-7.16.2">
              <li pn="section-appendix.a.2-7.16.2.1">
                <t indent="0" pn="section-appendix.a.2-7.16.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.2-7.16.2.1.2"><tt>IKbrYNn3vA7WEFrysvbdBJjDDU_EvQIr0W18vTRpUSg</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.16.2.2">
                <t indent="0" pn="section-appendix.a.2-7.16.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.2-7.16.2.2.2"><tt>WyJreDVrRjE3Vi14MEptd1V4OXZndnR3IiwgIm1zaXNkbiIsICI0OTEyMzQ1Njc4OSJd</tt></t>
              </li>
              <li pn="section-appendix.a.2-7.16.2.3">
                <t indent="0" pn="section-appendix.a.2-7.16.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.2-7.16.2.3.2"><tt>["kx5kF17V-x0JmwUx9vgvtw", "msisdn", "49123456789"]</tt></t>
              </li>
            </ul>
          </li>
        </ul>
        <t indent="0" pn="section-appendix.a.2-8">The following is a presentation of the SD-JWT:</t>
        <sourcecode type="" markers="false" pn="section-appendix.a.2-9">
eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb
Ii1hU3puSWQ5bVdNOG9jdVFvbENsbHN4VmdncTEtdkhXNE90bmhVdFZtV3ciLCAiSUti
cllObjN2QTdXRUZyeXN2YmRCSmpERFVfRXZRSXIwVzE4dlRScFVTZyIsICJvdGt4dVQx
NG5CaXd6TkozTVBhT2l0T2w5cFZuWE9hRUhhbF94a3lOZktJIl0sICJpc3MiOiAiaHR0
cHM6Ly9pc3N1ZXIuZXhhbXBsZS5jb20iLCAiaWF0IjogMTY4MzAwMDAwMCwgImV4cCI6
IDE4ODMwMDAwMDAsICJ2ZXJpZmllZF9jbGFpbXMiOiB7InZlcmlmaWNhdGlvbiI6IHsi
X3NkIjogWyI3aDRVRTlxU2N2REtvZFhWQ3VvS2ZLQkpwVkJmWE1GX1RtQUdWYVplM1Nj
IiwgInZUd2UzcmFISUZZZ0ZBM3hhVUQyYU14Rno1b0RvOGlCdTA1cUtsT2c5THciXSwg
InRydXN0X2ZyYW1ld29yayI6ICJkZV9hbWwiLCAiZXZpZGVuY2UiOiBbeyIuLi4iOiAi
dFlKMFREdWN5WlpDUk1iUk9HNHFSTzV2a1BTRlJ4RmhVRUxjMThDU2wzayJ9XX0sICJj
bGFpbXMiOiB7Il9zZCI6IFsiUmlPaUNuNl93NVpIYWFka1FNcmNRSmYwSnRlNVJ3dXJS
czU0MjMxRFRsbyIsICJTXzQ5OGJicEt6QjZFYW5mdHNzMHhjN2NPYW9uZVJyM3BLcjdO
ZFJtc01vIiwgIldOQS1VTks3Rl96aHNBYjlzeVdPNklJUTF1SGxUbU9VOHI4Q3ZKMGNJ
TWsiLCAiV3hoX3NWM2lSSDliZ3JUQkppLWFZSE5DTHQtdmpoWDFzZC1pZ09mXzlsayIs
ICJfTy13SmlIM2VuU0I0Uk9IbnRUb1FUOEptTHR6LW1oTzJmMWM4OVhvZXJRIiwgImh2
RFhod21HY0pRc0JDQTJPdGp1TEFjd0FNcERzYVUwbmtvdmNLT3FXTkUiXX19LCAiX3Nk
X2FsZyI6ICJzaGEtMjU2In0.QoWYWtikm-AtjmPnNVshbGXQl5raEz15PByTmZwfTQg9
W2O3oR6j2tMmysTZZawdo6mNLR_PsZSI25qrUpiNTg~WyIyR0xDNDJzS1F2ZUNmR2Zye
U5STjl3IiwgInRpbWUiLCAiMjAxMi0wNC0yM1QxODoyNVoiXQ~WyJQYzMzSk0yTGNoY1
VfbEhnZ3ZfdWZRIiwgeyJfc2QiOiBbIjl3cGpWUFd1RDdQSzBuc1FETDhCMDZsbWRnVj
NMVnliaEh5ZFFwVE55TEkiLCAiRzVFbmhPQU9vVTlYXzZRTU52ekZYanBFQV9SYy1BRX
RtMWJHX3djYUtJayIsICJJaHdGcldVQjYzUmNacTl5dmdaMFhQYzdHb3doM08ya3FYZU
JJc3dnMUI0IiwgIldweFE0SFNvRXRjVG1DQ0tPZURzbEJfZW11Y1lMejJvTzhvSE5yMW
JFVlEiXX1d~WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm1ldGhvZCIsICJwaXBwI
l0~WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdpdmVuX25hbWUiLCAiTWF4Il0~W
yJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImZhbWlseV9uYW1lIiwgIk1cdTAwZmNsb
GVyIl0~WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImFkZHJlc3MiLCB7ImxvY2Fsa
XR5IjogIk1heHN0YWR0IiwgInBvc3RhbF9jb2RlIjogIjEyMzQ0IiwgImNvdW50cnkiO
iAiREUiLCAic3RyZWV0X2FkZHJlc3MiOiAiV2VpZGVuc3RyYVx1MDBkZmUgMjIifV0~
</sourcecode>
        <t indent="0" pn="section-appendix.a.2-10">The Verifier will have this Processed SD-JWT Payload available after validation:</t>
        <sourcecode type="json" markers="false" pn="section-appendix.a.2-11">
{
  "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"
      }
    }
  }
}
</sourcecode>
      </section>
      <section anchor="sd-jwt-based-verifiable-credentials-sd-jwt-vc" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.3">
        <name slugifiedName="name-sd-jwt-based-verifiable-cre">SD-JWT-Based Verifiable Credentials (SD-JWT VC)</name>
        <t indent="0" pn="section-appendix.a.3-1">
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) <xref target="I-D.ietf-oauth-sd-jwt-vc" format="default" sectionFormat="of" derivedContent="SD-JWT-VC"/> to represent a hypothetical identity credential with the data of a fictional German citizen.
</t>
        <t indent="0" pn="section-appendix.a.3-2">Key Binding is applied
using the Holder's public key passed in a <tt>cnf</tt> claim in the SD-JWT.</t>
        <t indent="0" pn="section-appendix.a.3-3">The following citizen data is the input JWT Claims Set:</t>
        <sourcecode type="json" markers="false" pn="section-appendix.a.3-4">
{
  "vct": "urn:eudi:pid:de:1",
  "iss": "https://pid-issuer.bund.de.example",
  "given_name": "Erika",
  "family_name": "Mustermann",
  "birthdate": "1963-08-12",
  "address": {
    "street_address": "Heidestraße 17",
    "locality": "Köln",
    "postal_code": "51147",
    "country": "DE"
  },
  "nationalities": [
    "DE"
  ],
  "sex": 2,
  "birth_family_name": "Gabler",
  "place_of_birth": {
    "locality": "Berlin",
    "country": "DE"
  },
  "age_equal_or_over": {
    "12": true,
    "14": true,
    "16": true,
    "18": true,
    "21": true,
    "65": false
  },
  "age_in_years": 62,
  "age_birth_year": 1963,
  "issuance_date": "2020-03-11",
  "expiry_date": "2030-03-12",
  "issuing_authority": "DE",
  "issuing_country": "DE"
}
</sourcecode>
        <t indent="0" pn="section-appendix.a.3-5">The following is the issued SD-JWT:</t>
        <sourcecode type="" markers="false" pn="section-appendix.a.3-6">
eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImRjK3NkLWp3dCJ9.eyJfc2QiOiBbIjBIWm1
uU0lQejMzN2tTV2U3QzM0bC0tODhnekppLWVCSjJWel9ISndBVGciLCAiMUNybjAzV21
VZVJXcDR6d1B2dkNLWGw5WmFRcC1jZFFWX2dIZGFHU1dvdyIsICIycjAwOWR6dkh1VnJ
XclJYVDVrSk1tSG5xRUhIbldlME1MVlp3OFBBVEI4IiwgIjZaTklTRHN0NjJ5bWxyT0F
rYWRqZEQ1WnVsVDVBMjk5Sjc4U0xoTV9fT3MiLCAiNzhqZzc3LUdZQmVYOElRZm9FTFB
5TDBEWVBkbWZabzBKZ1ZpVjBfbEtDTSIsICI5MENUOEFhQlBibjVYOG5SWGtlc2p1MWk
wQnFoV3FaM3dxRDRqRi1xREdrIiwgIkkwMGZjRlVvRFhDdWNwNXl5MnVqcVBzc0RWR2F
XTmlVbGlOel9hd0QwZ2MiLCAiS2pBWGdBQTlONVdIRUR0UkloNHU1TW4xWnNXaXhoaFd
BaVgtQTRRaXdnQSIsICJMYWk2SVU2ZDdHUWFnWFI3QXZHVHJuWGdTbGQzejhFSWdfZnY
zZk9aMVdnIiwgIkxlemphYlJxaVpPWHpFWW1WWmY4Uk1pOXhBa2QzX00xTFo4VTdFNHM
zdTQiLCAiUlR6M3FUbUZOSGJwV3JyT01aUzQxRjQ3NGtGcVJ2M3ZJUHF0aDZQVWhsTSI
sICJXMTRYSGJVZmZ6dVc0SUZNanBTVGIxbWVsV3hVV2Y0Tl9vMmxka2tJcWM4IiwgIld
UcEk3UmNNM2d4WnJ1UnBYemV6U2JrYk9yOTNQVkZ2V3g4d29KM2oxY0UiLCAiX29oSlZ
JUUlCc1U0dXBkTlM0X3c0S2IxTUhxSjBMOXFMR3NoV3E2SlhRcyIsICJ5NTBjemMwSVN
DaHlfYnNiYTFkTW9VdUFPUTVBTW1PU2ZHb0VlODF2MUZVIl0sICJpc3MiOiAiaHR0cHM
6Ly9waWQtaXNzdWVyLmJ1bmQuZGUuZXhhbXBsZSIsICJpYXQiOiAxNjgzMDAwMDAwLCA
iZXhwIjogMTg4MzAwMDAwMCwgInZjdCI6ICJ1cm46ZXVkaTpwaWQ6ZGU6MSIsICJfc2R
fYWxnIjogInNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnY
iOiAiUC0yNTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbER
sczd2Q2VHZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U
2dDRqVDlGMkhaUSJ9fX0.ZOZQTqmq8X1mCyFXi0wbV8xjctX1AlEa5TkdnkKOyWvLfW4
0XDb5oj9tzkgwff5s44IDnrfAdgLtmTcojs97_Q~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5S
Tjl3IiwgImdpdmVuX25hbWUiLCAiRXJpa2EiXQ~WyJlbHVWNU9nM2dTTklJOEVZbnN4Q
V9BIiwgImZhbWlseV9uYW1lIiwgIk11c3Rlcm1hbm4iXQ~WyI2SWo3dE0tYTVpVlBHYm
9TNXRtdlZBIiwgImJpcnRoZGF0ZSIsICIxOTYzLTA4LTEyIl0~WyJlSThaV205UW5LUH
BOUGVOZW5IZGhRIiwgInN0cmVldF9hZGRyZXNzIiwgIkhlaWRlc3RyYVx1MDBkZmUgMT
ciXQ~WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImxvY2FsaXR5IiwgIktcdTAwZjZ
sbiJd~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInBvc3RhbF9jb2RlIiwgIjUxMT
Q3Il0~WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImNvdW50cnkiLCAiREUiXQ~WyJ
HMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImFkZHJlc3MiLCB7Il9zZCI6IFsiQUxaRVJ
zU241V05pRVhkQ2tzVzhJNXFRdzNfTnBBblJxcFNBWkR1ZGd3OCIsICJEX19XX3VZY3Z
SejN0dlVuSUp2QkRIaVRjN0NfX3FIZDB4Tkt3SXNfdzlrIiwgImVCcENYVTFKNWRoSDJ
nNHQ4UVlOVzVFeFM5QXhVVmJsVW9kb0xZb1BobzAiLCAieE9QeTktZ0pBTEs2VWJXS0Z
MUjg1Y09CeVVEM0FiTndGZzNJM1lmUUVfSSJdfV0~WyJsa2x4RjVqTVlsR1RQVW92TU5
JdkNBIiwgIm5hdGlvbmFsaXRpZXMiLCBbIkRFIl1d~WyJuUHVvUW5rUkZxM0JJZUFtN0
FuWEZBIiwgInNleCIsIDJd~WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImJpcnRoX
2ZhbWlseV9uYW1lIiwgIkdhYmxlciJd~WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13Iiwg
ImxvY2FsaXR5IiwgIkJlcmxpbiJd~WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImN
vdW50cnkiLCAiREUiXQ~WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgInBsYWNlX29m
X2JpcnRoIiwgeyJfc2QiOiBbIktVVmlhYUxuWTVqU01MOTBHMjlPT0xFTlBiYlhmaFNq
U1BNalphR2t4QUUiLCAiWWJzVDBTNzZWcVhDVnNkMWpVU2x3S1BEZ21BTGVCMXVaY2xG
SFhmLVVTUSJdfV0~WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgIjEyIiwgdHJ1ZV0~
WyJreDVrRjE3Vi14MEptd1V4OXZndnR3IiwgIjE0IiwgdHJ1ZV0~WyJIM28xdXN3UDc2
MEZpMnllR2RWQ0VRIiwgIjE2IiwgdHJ1ZV0~WyJPQktsVFZsdkxnLUFkd3FZR2JQOFpB
IiwgIjE4IiwgdHJ1ZV0~WyJNMEpiNTd0NDF1YnJrU3V5ckRUM3hBIiwgIjIxIiwgdHJ1
ZV0~WyJEc210S05ncFY0ZEFIcGpyY2Fvc0F3IiwgIjY1IiwgZmFsc2Vd~WyJlSzVvNXB
IZmd1cFBwbHRqMXFoQUp3IiwgImFnZV9lcXVhbF9vcl9vdmVyIiwgeyJfc2QiOiBbIjF
0RWl5elBSWU9Lc2Y3U3NZR01nUFpLc09UMWxRWlJ4SFhBMHI1X0J3a2siLCAiQ1ZLbmx
5NVA5MHlKczNFd3R4UWlPdFVjemFYQ1lOQTRJY3pSYW9ock1EZyIsICJhNDQtZzJHcjh
fM0FtSncyWFo4a0kxeTBRel96ZTlpT2NXMlczUkxwWEdnIiwgImdrdnkwRnV2QkJ2ajB
oczJaTnd4Y3FPbGY4bXUyLWtDRTctTmIyUXh1QlUiLCAiaHJZNEhubUY1YjVKd0M5ZVR
6YUZDVWNlSVFBYUlkaHJxVVhRTkNXYmZaSSIsICJ5NlNGclZGUnlxNTBJYlJKdmlUWnF
xalFXejB0TGl1Q21NZU8wS3FhekdJIl19XQ~WyJqN0FEZGIwVVZiMExpMGNpUGNQMGV3
IiwgImFnZV9pbl95ZWFycyIsIDYyXQ~WyJXcHhKckZ1WDh1U2kycDRodDA5anZ3IiwgI
mFnZV9iaXJ0aF95ZWFyIiwgMTk2M10~WyJhdFNtRkFDWU1iSlZLRDA1bzNKZ3RRIiwgI
mlzc3VhbmNlX2RhdGUiLCAiMjAyMC0wMy0xMSJd~WyI0S3lSMzJvSVp0LXprV3ZGcWJV
TEtnIiwgImV4cGlyeV9kYXRlIiwgIjIwMzAtMDMtMTIiXQ~WyJjaEJDc3loeWgtSjg2S
S1hd1FEaUNRIiwgImlzc3VpbmdfYXV0aG9yaXR5IiwgIkRFIl0~WyJmbE5QMW5jTXo5T
GctYzlxTUl6XzlnIiwgImlzc3VpbmdfY291bnRyeSIsICJERSJd~
</sourcecode>
        <t indent="0" pn="section-appendix.a.3-7">The following payload is used for the SD-JWT:</t>
        <sourcecode type="json" markers="false" pn="section-appendix.a.3-8">
{
  "_sd": [
    "0HZmnSIPz337kSWe7C34l--88gzJi-eBJ2Vz_HJwATg",
    "1Crn03WmUeRWp4zwPvvCKXl9ZaQp-cdQV_gHdaGSWow",
    "2r009dzvHuVrWrRXT5kJMmHnqEHHnWe0MLVZw8PATB8",
    "6ZNISDst62ymlrOAkadjdD5ZulT5A299J78SLhM__Os",
    "78jg77-GYBeX8IQfoELPyL0DYPdmfZo0JgViV0_lKCM",
    "90CT8AaBPbn5X8nRXkesju1i0BqhWqZ3wqD4jF-qDGk",
    "I00fcFUoDXCucp5yy2ujqPssDVGaWNiUliNz_awD0gc",
    "KjAXgAA9N5WHEDtRIh4u5Mn1ZsWixhhWAiX-A4QiwgA",
    "Lai6IU6d7GQagXR7AvGTrnXgSld3z8EIg_fv3fOZ1Wg",
    "LezjabRqiZOXzEYmVZf8RMi9xAkd3_M1LZ8U7E4s3u4",
    "RTz3qTmFNHbpWrrOMZS41F474kFqRv3vIPqth6PUhlM",
    "W14XHbUffzuW4IFMjpSTb1melWxUWf4N_o2ldkkIqc8",
    "WTpI7RcM3gxZruRpXzezSbkbOr93PVFvWx8woJ3j1cE",
    "_ohJVIQIBsU4updNS4_w4Kb1MHqJ0L9qLGshWq6JXQs",
    "y50czc0ISChy_bsba1dMoUuAOQ5AMmOSfGoEe81v1FU"
  ],
  "iss": "https://pid-issuer.bund.de.example",
  "iat": 1683000000,
  "exp": 1883000000,
  "vct": "urn:eudi:pid:de:1",
  "_sd_alg": "sha-256",
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
      "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
    }
  }
}
</sourcecode>
        <t indent="0" pn="section-appendix.a.3-9">The digests in the SD-JWT payload reference the following Disclosures:</t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-appendix.a.3-10">
          <li pn="section-appendix.a.3-10.1">
            <t indent="0" pn="section-appendix.a.3-10.1.1">Claim <tt>given_name</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.3-10.1.2">
              <li pn="section-appendix.a.3-10.1.2.1">
                <t indent="0" pn="section-appendix.a.3-10.1.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.3-10.1.2.1.2"><tt>0HZmnSIPz337kSWe7C34l--88gzJi-eBJ2Vz_HJwATg</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.1.2.2">
                <t indent="0" pn="section-appendix.a.3-10.1.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.3-10.1.2.2.2"><tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiRXJpa2EiXQ</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.1.2.3">
                <t indent="0" pn="section-appendix.a.3-10.1.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.3-10.1.2.3.2"><tt>["2GLC42sKQveCfGfryNRN9w", "given_name", "Erika"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.3-10.2">
            <t indent="0" pn="section-appendix.a.3-10.2.1">Claim <tt>family_name</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.3-10.2.2">
              <li pn="section-appendix.a.3-10.2.2.1">
                <t indent="0" pn="section-appendix.a.3-10.2.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.3-10.2.2.1.2"><tt>I00fcFUoDXCucp5yy2ujqPssDVGaWNiUliNz_awD0gc</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.2.2.2">
                <t indent="0" pn="section-appendix.a.3-10.2.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.3-10.2.2.2.2"><tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIk11c3Rlcm1hbm4iXQ</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.2.2.3">
                <t indent="0" pn="section-appendix.a.3-10.2.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.3-10.2.2.3.2"><tt>["eluV5Og3gSNII8EYnsxA_A", "family_name", "Mustermann"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.3-10.3">
            <t indent="0" pn="section-appendix.a.3-10.3.1">Claim <tt>birthdate</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.3-10.3.2">
              <li pn="section-appendix.a.3-10.3.2.1">
                <t indent="0" pn="section-appendix.a.3-10.3.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.3-10.3.2.1.2"><tt>Lai6IU6d7GQagXR7AvGTrnXgSld3z8EIg_fv3fOZ1Wg</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.3.2.2">
                <t indent="0" pn="section-appendix.a.3-10.3.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.3-10.3.2.2.2"><tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImJpcnRoZGF0ZSIsICIxOTYzLTA4LTEyIl0</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.3.2.3">
                <t indent="0" pn="section-appendix.a.3-10.3.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.3-10.3.2.3.2"><tt>["6Ij7tM-a5iVPGboS5tmvVA", "birthdate", "1963-08-12"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.3-10.4">
            <t indent="0" pn="section-appendix.a.3-10.4.1">Claim <tt>street_address</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.3-10.4.2">
              <li pn="section-appendix.a.3-10.4.2.1">
                <t indent="0" pn="section-appendix.a.3-10.4.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.3-10.4.2.1.2"><tt>ALZERsSn5WNiEXdCksW8I5qQw3_NpAnRqpSAZDudgw8</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.4.2.2">
                <t indent="0" pn="section-appendix.a.3-10.4.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.3-10.4.2.2.2"><tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInN0cmVldF9hZGRyZXNzIiwgIkhlaWRlc3RyYVx1MDBkZmUgMTciXQ</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.4.2.3">
                <t indent="0" pn="section-appendix.a.3-10.4.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.3-10.4.2.3.2"><tt>["eI8ZWm9QnKPpNPeNenHdhQ", "street_address", "Heidestra\u00dfe 17"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.3-10.5">
            <t indent="0" pn="section-appendix.a.3-10.5.1">Claim <tt>locality</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.3-10.5.2">
              <li pn="section-appendix.a.3-10.5.2.1">
                <t indent="0" pn="section-appendix.a.3-10.5.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.3-10.5.2.1.2"><tt>D__W_uYcvRz3tvUnIJvBDHiTc7C__qHd0xNKwIs_w9k</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.5.2.2">
                <t indent="0" pn="section-appendix.a.3-10.5.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.3-10.5.2.2.2"><tt>WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImxvY2FsaXR5IiwgIktcdTAwZjZsbiJd</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.5.2.3">
                <t indent="0" pn="section-appendix.a.3-10.5.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.3-10.5.2.3.2"><tt>["Qg_O64zqAxe412a108iroA", "locality", "K\u00f6ln"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.3-10.6">
            <t indent="0" pn="section-appendix.a.3-10.6.1">Claim <tt>postal_code</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.3-10.6.2">
              <li pn="section-appendix.a.3-10.6.2.1">
                <t indent="0" pn="section-appendix.a.3-10.6.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.3-10.6.2.1.2"><tt>xOPy9-gJALK6UbWKFLR85cOByUD3AbNwFg3I3YfQE_I</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.6.2.2">
                <t indent="0" pn="section-appendix.a.3-10.6.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.3-10.6.2.2.2"><tt>WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInBvc3RhbF9jb2RlIiwgIjUxMTQ3Il0</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.6.2.3">
                <t indent="0" pn="section-appendix.a.3-10.6.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.3-10.6.2.3.2"><tt>["AJx-095VPrpTtN4QMOqROA", "postal_code", "51147"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.3-10.7">
            <t indent="0" pn="section-appendix.a.3-10.7.1">Claim <tt>country</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.3-10.7.2">
              <li pn="section-appendix.a.3-10.7.2.1">
                <t indent="0" pn="section-appendix.a.3-10.7.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.3-10.7.2.1.2"><tt>eBpCXU1J5dhH2g4t8QYNW5ExS9AxUVblUodoLYoPho0</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.7.2.2">
                <t indent="0" pn="section-appendix.a.3-10.7.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.3-10.7.2.2.2"><tt>WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImNvdW50cnkiLCAiREUiXQ</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.7.2.3">
                <t indent="0" pn="section-appendix.a.3-10.7.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.3-10.7.2.3.2"><tt>["Pc33JM2LchcU_lHggv_ufQ", "country", "DE"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.3-10.8">
            <t indent="0" pn="section-appendix.a.3-10.8.1">Claim <tt>address</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.3-10.8.2">
              <li pn="section-appendix.a.3-10.8.2.1">
                <t indent="0" pn="section-appendix.a.3-10.8.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.3-10.8.2.1.2"><tt>RTz3qTmFNHbpWrrOMZS41F474kFqRv3vIPqth6PUhlM</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.8.2.2">
                <t indent="0" pn="section-appendix.a.3-10.8.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.3-10.8.2.2.2"><tt>WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImFkZHJlc3MiLCB7Il9zZCI6IFsiQUxaRVJzU241V05pRVhkQ2tzVzhJNXFRdzNfTnBBblJxcFNBWkR1ZGd3OCIsICJEX19XX3VZY3ZSejN0dlVuSUp2QkRIaVRjN0NfX3FIZDB4Tkt3SXNfdzlrIiwgImVCcENYVTFKNWRoSDJnNHQ4UVlOVzVFeFM5QXhVVmJsVW9kb0xZb1BobzAiLCAieE9QeTktZ0pBTEs2VWJXS0ZMUjg1Y09CeVVEM0FiTndGZzNJM1lmUUVfSSJdfV0</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.8.2.3">
                <t indent="0" pn="section-appendix.a.3-10.8.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.3-10.8.2.3.2"><tt>["G02NSrQfjFXQ7Io09syajA", "address", {"_sd": ["ALZERsSn5WNiEXdCksW8I5qQw3_NpAnRqpSAZDudgw8", "D__W_uYcvRz3tvUnIJvBDHiTc7C__qHd0xNKwIs_w9k", "eBpCXU1J5dhH2g4t8QYNW5ExS9AxUVblUodoLYoPho0", "xOPy9-gJALK6UbWKFLR85cOByUD3AbNwFg3I3YfQE_I"]}]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.3-10.9">
            <t indent="0" pn="section-appendix.a.3-10.9.1">Claim <tt>nationalities</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.3-10.9.2">
              <li pn="section-appendix.a.3-10.9.2.1">
                <t indent="0" pn="section-appendix.a.3-10.9.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.3-10.9.2.1.2"><tt>y50czc0ISChy_bsba1dMoUuAOQ5AMmOSfGoEe81v1FU</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.9.2.2">
                <t indent="0" pn="section-appendix.a.3-10.9.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.3-10.9.2.2.2"><tt>WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIm5hdGlvbmFsaXRpZXMiLCBbIkRFIl1d</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.9.2.3">
                <t indent="0" pn="section-appendix.a.3-10.9.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.3-10.9.2.3.2"><tt>["lklxF5jMYlGTPUovMNIvCA", "nationalities", ["DE"]]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.3-10.10">
            <t indent="0" pn="section-appendix.a.3-10.10.1">Claim <tt>sex</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.3-10.10.2">
              <li pn="section-appendix.a.3-10.10.2.1">
                <t indent="0" pn="section-appendix.a.3-10.10.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.3-10.10.2.1.2"><tt>90CT8AaBPbn5X8nRXkesju1i0BqhWqZ3wqD4jF-qDGk</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.10.2.2">
                <t indent="0" pn="section-appendix.a.3-10.10.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.3-10.10.2.2.2"><tt>WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgInNleCIsIDJd</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.10.2.3">
                <t indent="0" pn="section-appendix.a.3-10.10.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.3-10.10.2.3.2"><tt>["nPuoQnkRFq3BIeAm7AnXFA", "sex", 2]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.3-10.11">
            <t indent="0" pn="section-appendix.a.3-10.11.1">Claim <tt>birth_family_name</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.3-10.11.2">
              <li pn="section-appendix.a.3-10.11.2.1">
                <t indent="0" pn="section-appendix.a.3-10.11.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.3-10.11.2.1.2"><tt>KjAXgAA9N5WHEDtRIh4u5Mn1ZsWixhhWAiX-A4QiwgA</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.11.2.2">
                <t indent="0" pn="section-appendix.a.3-10.11.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.3-10.11.2.2.2"><tt>WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImJpcnRoX2ZhbWlseV9uYW1lIiwgIkdhYmxlciJd</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.11.2.3">
                <t indent="0" pn="section-appendix.a.3-10.11.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.3-10.11.2.3.2"><tt>["5bPs1IquZNa0hkaFzzzZNw", "birth_family_name", "Gabler"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.3-10.12">
            <t indent="0" pn="section-appendix.a.3-10.12.1">Claim <tt>locality</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.3-10.12.2">
              <li pn="section-appendix.a.3-10.12.2.1">
                <t indent="0" pn="section-appendix.a.3-10.12.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.3-10.12.2.1.2"><tt>KUViaaLnY5jSML90G29OOLENPbbXfhSjSPMjZaGkxAE</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.12.2.2">
                <t indent="0" pn="section-appendix.a.3-10.12.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.3-10.12.2.2.2"><tt>WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgImxvY2FsaXR5IiwgIkJlcmxpbiJd</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.12.2.3">
                <t indent="0" pn="section-appendix.a.3-10.12.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.3-10.12.2.3.2"><tt>["5a2W0_NrlEZzfqmk_7Pq-w", "locality", "Berlin"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.3-10.13">
            <t indent="0" pn="section-appendix.a.3-10.13.1">Claim <tt>country</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.3-10.13.2">
              <li pn="section-appendix.a.3-10.13.2.1">
                <t indent="0" pn="section-appendix.a.3-10.13.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.3-10.13.2.1.2"><tt>YbsT0S76VqXCVsd1jUSlwKPDgmALeB1uZclFHXf-USQ</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.13.2.2">
                <t indent="0" pn="section-appendix.a.3-10.13.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.3-10.13.2.2.2"><tt>WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImNvdW50cnkiLCAiREUiXQ</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.13.2.3">
                <t indent="0" pn="section-appendix.a.3-10.13.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.3-10.13.2.3.2"><tt>["y1sVU5wdfJahVdgwPgS7RQ", "country", "DE"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.3-10.14">
            <t indent="0" pn="section-appendix.a.3-10.14.1">Claim <tt>place_of_birth</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.3-10.14.2">
              <li pn="section-appendix.a.3-10.14.2.1">
                <t indent="0" pn="section-appendix.a.3-10.14.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.3-10.14.2.1.2"><tt>1Crn03WmUeRWp4zwPvvCKXl9ZaQp-cdQV_gHdaGSWow</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.14.2.2">
                <t indent="0" pn="section-appendix.a.3-10.14.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.3-10.14.2.2.2"><tt>WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgInBsYWNlX29mX2JpcnRoIiwgeyJfc2QiOiBbIktVVmlhYUxuWTVqU01MOTBHMjlPT0xFTlBiYlhmaFNqU1BNalphR2t4QUUiLCAiWWJzVDBTNzZWcVhDVnNkMWpVU2x3S1BEZ21BTGVCMXVaY2xGSFhmLVVTUSJdfV0</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.14.2.3">
                <t indent="0" pn="section-appendix.a.3-10.14.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.3-10.14.2.3.2"><tt>["HbQ4X8srVW3QDxnIJdqyOA", "place_of_birth", {"_sd": ["KUViaaLnY5jSML90G29OOLENPbbXfhSjSPMjZaGkxAE", "YbsT0S76VqXCVsd1jUSlwKPDgmALeB1uZclFHXf-USQ"]}]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.3-10.15">
            <t indent="0" pn="section-appendix.a.3-10.15.1">Claim <tt>12</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.3-10.15.2">
              <li pn="section-appendix.a.3-10.15.2.1">
                <t indent="0" pn="section-appendix.a.3-10.15.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.3-10.15.2.1.2"><tt>gkvy0FuvBBvj0hs2ZNwxcqOlf8mu2-kCE7-Nb2QxuBU</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.15.2.2">
                <t indent="0" pn="section-appendix.a.3-10.15.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.3-10.15.2.2.2"><tt>WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgIjEyIiwgdHJ1ZV0</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.15.2.3">
                <t indent="0" pn="section-appendix.a.3-10.15.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.3-10.15.2.3.2"><tt>["C9GSoujviJquEgYfojCb1A", "12", true]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.3-10.16">
            <t indent="0" pn="section-appendix.a.3-10.16.1">Claim <tt>14</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.3-10.16.2">
              <li pn="section-appendix.a.3-10.16.2.1">
                <t indent="0" pn="section-appendix.a.3-10.16.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.3-10.16.2.1.2"><tt>y6SFrVFRyq50IbRJviTZqqjQWz0tLiuCmMeO0KqazGI</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.16.2.2">
                <t indent="0" pn="section-appendix.a.3-10.16.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.3-10.16.2.2.2"><tt>WyJreDVrRjE3Vi14MEptd1V4OXZndnR3IiwgIjE0IiwgdHJ1ZV0</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.16.2.3">
                <t indent="0" pn="section-appendix.a.3-10.16.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.3-10.16.2.3.2"><tt>["kx5kF17V-x0JmwUx9vgvtw", "14", true]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.3-10.17">
            <t indent="0" pn="section-appendix.a.3-10.17.1">Claim <tt>16</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.3-10.17.2">
              <li pn="section-appendix.a.3-10.17.2.1">
                <t indent="0" pn="section-appendix.a.3-10.17.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.3-10.17.2.1.2"><tt>hrY4HnmF5b5JwC9eTzaFCUceIQAaIdhrqUXQNCWbfZI</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.17.2.2">
                <t indent="0" pn="section-appendix.a.3-10.17.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.3-10.17.2.2.2"><tt>WyJIM28xdXN3UDc2MEZpMnllR2RWQ0VRIiwgIjE2IiwgdHJ1ZV0</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.17.2.3">
                <t indent="0" pn="section-appendix.a.3-10.17.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.3-10.17.2.3.2"><tt>["H3o1uswP760Fi2yeGdVCEQ", "16", true]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.3-10.18">
            <t indent="0" pn="section-appendix.a.3-10.18.1">Claim <tt>18</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.3-10.18.2">
              <li pn="section-appendix.a.3-10.18.2.1">
                <t indent="0" pn="section-appendix.a.3-10.18.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.3-10.18.2.1.2"><tt>CVKnly5P90yJs3EwtxQiOtUczaXCYNA4IczRaohrMDg</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.18.2.2">
                <t indent="0" pn="section-appendix.a.3-10.18.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.3-10.18.2.2.2"><tt>WyJPQktsVFZsdkxnLUFkd3FZR2JQOFpBIiwgIjE4IiwgdHJ1ZV0</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.18.2.3">
                <t indent="0" pn="section-appendix.a.3-10.18.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.3-10.18.2.3.2"><tt>["OBKlTVlvLg-AdwqYGbP8ZA", "18", true]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.3-10.19">
            <t indent="0" pn="section-appendix.a.3-10.19.1">Claim <tt>21</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.3-10.19.2">
              <li pn="section-appendix.a.3-10.19.2.1">
                <t indent="0" pn="section-appendix.a.3-10.19.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.3-10.19.2.1.2"><tt>1tEiyzPRYOKsf7SsYGMgPZKsOT1lQZRxHXA0r5_Bwkk</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.19.2.2">
                <t indent="0" pn="section-appendix.a.3-10.19.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.3-10.19.2.2.2"><tt>WyJNMEpiNTd0NDF1YnJrU3V5ckRUM3hBIiwgIjIxIiwgdHJ1ZV0</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.19.2.3">
                <t indent="0" pn="section-appendix.a.3-10.19.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.3-10.19.2.3.2"><tt>["M0Jb57t41ubrkSuyrDT3xA", "21", true]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.3-10.20">
            <t indent="0" pn="section-appendix.a.3-10.20.1">Claim <tt>65</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.3-10.20.2">
              <li pn="section-appendix.a.3-10.20.2.1">
                <t indent="0" pn="section-appendix.a.3-10.20.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.3-10.20.2.1.2"><tt>a44-g2Gr8_3AmJw2XZ8kI1y0Qz_ze9iOcW2W3RLpXGg</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.20.2.2">
                <t indent="0" pn="section-appendix.a.3-10.20.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.3-10.20.2.2.2"><tt>WyJEc210S05ncFY0ZEFIcGpyY2Fvc0F3IiwgIjY1IiwgZmFsc2Vd</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.20.2.3">
                <t indent="0" pn="section-appendix.a.3-10.20.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.3-10.20.2.3.2"><tt>["DsmtKNgpV4dAHpjrcaosAw", "65", false]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.3-10.21">
            <t indent="0" pn="section-appendix.a.3-10.21.1">Claim <tt>age_equal_or_over</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.3-10.21.2">
              <li pn="section-appendix.a.3-10.21.2.1">
                <t indent="0" pn="section-appendix.a.3-10.21.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.3-10.21.2.1.2"><tt>2r009dzvHuVrWrRXT5kJMmHnqEHHnWe0MLVZw8PATB8</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.21.2.2">
                <t indent="0" pn="section-appendix.a.3-10.21.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.3-10.21.2.2.2"><tt>WyJlSzVvNXBIZmd1cFBwbHRqMXFoQUp3IiwgImFnZV9lcXVhbF9vcl9vdmVyIiwgeyJfc2QiOiBbIjF0RWl5elBSWU9Lc2Y3U3NZR01nUFpLc09UMWxRWlJ4SFhBMHI1X0J3a2siLCAiQ1ZLbmx5NVA5MHlKczNFd3R4UWlPdFVjemFYQ1lOQTRJY3pSYW9ock1EZyIsICJhNDQtZzJHcjhfM0FtSncyWFo4a0kxeTBRel96ZTlpT2NXMlczUkxwWEdnIiwgImdrdnkwRnV2QkJ2ajBoczJaTnd4Y3FPbGY4bXUyLWtDRTctTmIyUXh1QlUiLCAiaHJZNEhubUY1YjVKd0M5ZVR6YUZDVWNlSVFBYUlkaHJxVVhRTkNXYmZaSSIsICJ5NlNGclZGUnlxNTBJYlJKdmlUWnFxalFXejB0TGl1Q21NZU8wS3FhekdJIl19XQ</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.21.2.3">
                <t indent="0" pn="section-appendix.a.3-10.21.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.3-10.21.2.3.2"><tt>["eK5o5pHfgupPpltj1qhAJw", "age_equal_or_over", {"_sd": ["1tEiyzPRYOKsf7SsYGMgPZKsOT1lQZRxHXA0r5_Bwkk", "CVKnly5P90yJs3EwtxQiOtUczaXCYNA4IczRaohrMDg", "a44-g2Gr8_3AmJw2XZ8kI1y0Qz_ze9iOcW2W3RLpXGg", "gkvy0FuvBBvj0hs2ZNwxcqOlf8mu2-kCE7-Nb2QxuBU", "hrY4HnmF5b5JwC9eTzaFCUceIQAaIdhrqUXQNCWbfZI", "y6SFrVFRyq50IbRJviTZqqjQWz0tLiuCmMeO0KqazGI"]}]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.3-10.22">
            <t indent="0" pn="section-appendix.a.3-10.22.1">Claim <tt>age_in_years</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.3-10.22.2">
              <li pn="section-appendix.a.3-10.22.2.1">
                <t indent="0" pn="section-appendix.a.3-10.22.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.3-10.22.2.1.2"><tt>WTpI7RcM3gxZruRpXzezSbkbOr93PVFvWx8woJ3j1cE</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.22.2.2">
                <t indent="0" pn="section-appendix.a.3-10.22.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.3-10.22.2.2.2"><tt>WyJqN0FEZGIwVVZiMExpMGNpUGNQMGV3IiwgImFnZV9pbl95ZWFycyIsIDYyXQ</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.22.2.3">
                <t indent="0" pn="section-appendix.a.3-10.22.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.3-10.22.2.3.2"><tt>["j7ADdb0UVb0Li0ciPcP0ew", "age_in_years", 62]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.3-10.23">
            <t indent="0" pn="section-appendix.a.3-10.23.1">Claim <tt>age_birth_year</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.3-10.23.2">
              <li pn="section-appendix.a.3-10.23.2.1">
                <t indent="0" pn="section-appendix.a.3-10.23.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.3-10.23.2.1.2"><tt>LezjabRqiZOXzEYmVZf8RMi9xAkd3_M1LZ8U7E4s3u4</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.23.2.2">
                <t indent="0" pn="section-appendix.a.3-10.23.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.3-10.23.2.2.2"><tt>WyJXcHhKckZ1WDh1U2kycDRodDA5anZ3IiwgImFnZV9iaXJ0aF95ZWFyIiwgMTk2M10</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.23.2.3">
                <t indent="0" pn="section-appendix.a.3-10.23.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.3-10.23.2.3.2"><tt>["WpxJrFuX8uSi2p4ht09jvw", "age_birth_year", 1963]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.3-10.24">
            <t indent="0" pn="section-appendix.a.3-10.24.1">Claim <tt>issuance_date</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.3-10.24.2">
              <li pn="section-appendix.a.3-10.24.2.1">
                <t indent="0" pn="section-appendix.a.3-10.24.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.3-10.24.2.1.2"><tt>W14XHbUffzuW4IFMjpSTb1melWxUWf4N_o2ldkkIqc8</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.24.2.2">
                <t indent="0" pn="section-appendix.a.3-10.24.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.3-10.24.2.2.2"><tt>WyJhdFNtRkFDWU1iSlZLRDA1bzNKZ3RRIiwgImlzc3VhbmNlX2RhdGUiLCAiMjAyMC0wMy0xMSJd</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.24.2.3">
                <t indent="0" pn="section-appendix.a.3-10.24.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.3-10.24.2.3.2"><tt>["atSmFACYMbJVKD05o3JgtQ", "issuance_date", "2020-03-11"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.3-10.25">
            <t indent="0" pn="section-appendix.a.3-10.25.1">Claim <tt>expiry_date</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.3-10.25.2">
              <li pn="section-appendix.a.3-10.25.2.1">
                <t indent="0" pn="section-appendix.a.3-10.25.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.3-10.25.2.1.2"><tt>78jg77-GYBeX8IQfoELPyL0DYPdmfZo0JgViV0_lKCM</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.25.2.2">
                <t indent="0" pn="section-appendix.a.3-10.25.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.3-10.25.2.2.2"><tt>WyI0S3lSMzJvSVp0LXprV3ZGcWJVTEtnIiwgImV4cGlyeV9kYXRlIiwgIjIwMzAtMDMtMTIiXQ</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.25.2.3">
                <t indent="0" pn="section-appendix.a.3-10.25.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.3-10.25.2.3.2"><tt>["4KyR32oIZt-zkWvFqbULKg", "expiry_date", "2030-03-12"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.3-10.26">
            <t indent="0" pn="section-appendix.a.3-10.26.1">Claim <tt>issuing_authority</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.3-10.26.2">
              <li pn="section-appendix.a.3-10.26.2.1">
                <t indent="0" pn="section-appendix.a.3-10.26.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.3-10.26.2.1.2"><tt>6ZNISDst62ymlrOAkadjdD5ZulT5A299J78SLhM__Os</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.26.2.2">
                <t indent="0" pn="section-appendix.a.3-10.26.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.3-10.26.2.2.2"><tt>WyJjaEJDc3loeWgtSjg2SS1hd1FEaUNRIiwgImlzc3VpbmdfYXV0aG9yaXR5IiwgIkRFIl0</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.26.2.3">
                <t indent="0" pn="section-appendix.a.3-10.26.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.3-10.26.2.3.2"><tt>["chBCsyhyh-J86I-awQDiCQ", "issuing_authority", "DE"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.3-10.27">
            <t indent="0" pn="section-appendix.a.3-10.27.1">Claim <tt>issuing_country</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.3-10.27.2">
              <li pn="section-appendix.a.3-10.27.2.1">
                <t indent="0" pn="section-appendix.a.3-10.27.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.3-10.27.2.1.2"><tt>_ohJVIQIBsU4updNS4_w4Kb1MHqJ0L9qLGshWq6JXQs</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.27.2.2">
                <t indent="0" pn="section-appendix.a.3-10.27.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.3-10.27.2.2.2"><tt>WyJmbE5QMW5jTXo5TGctYzlxTUl6XzlnIiwgImlzc3VpbmdfY291bnRyeSIsICJERSJd</tt></t>
              </li>
              <li pn="section-appendix.a.3-10.27.2.3">
                <t indent="0" pn="section-appendix.a.3-10.27.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.3-10.27.2.3.2"><tt>["flNP1ncMz9Lg-c9qMIz_9g", "issuing_country", "DE"]</tt></t>
              </li>
            </ul>
          </li>
        </ul>
        <t indent="0" pn="section-appendix.a.3-11">The following is an example of an SD-JWT+KB that discloses only nationality and the fact that the person is over 18 years old:</t>
        <sourcecode type="" markers="false" pn="section-appendix.a.3-12">
eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImRjK3NkLWp3dCJ9.eyJfc2QiOiBbIjBIWm1
uU0lQejMzN2tTV2U3QzM0bC0tODhnekppLWVCSjJWel9ISndBVGciLCAiMUNybjAzV21
VZVJXcDR6d1B2dkNLWGw5WmFRcC1jZFFWX2dIZGFHU1dvdyIsICIycjAwOWR6dkh1VnJ
XclJYVDVrSk1tSG5xRUhIbldlME1MVlp3OFBBVEI4IiwgIjZaTklTRHN0NjJ5bWxyT0F
rYWRqZEQ1WnVsVDVBMjk5Sjc4U0xoTV9fT3MiLCAiNzhqZzc3LUdZQmVYOElRZm9FTFB
5TDBEWVBkbWZabzBKZ1ZpVjBfbEtDTSIsICI5MENUOEFhQlBibjVYOG5SWGtlc2p1MWk
wQnFoV3FaM3dxRDRqRi1xREdrIiwgIkkwMGZjRlVvRFhDdWNwNXl5MnVqcVBzc0RWR2F
XTmlVbGlOel9hd0QwZ2MiLCAiS2pBWGdBQTlONVdIRUR0UkloNHU1TW4xWnNXaXhoaFd
BaVgtQTRRaXdnQSIsICJMYWk2SVU2ZDdHUWFnWFI3QXZHVHJuWGdTbGQzejhFSWdfZnY
zZk9aMVdnIiwgIkxlemphYlJxaVpPWHpFWW1WWmY4Uk1pOXhBa2QzX00xTFo4VTdFNHM
zdTQiLCAiUlR6M3FUbUZOSGJwV3JyT01aUzQxRjQ3NGtGcVJ2M3ZJUHF0aDZQVWhsTSI
sICJXMTRYSGJVZmZ6dVc0SUZNanBTVGIxbWVsV3hVV2Y0Tl9vMmxka2tJcWM4IiwgIld
UcEk3UmNNM2d4WnJ1UnBYemV6U2JrYk9yOTNQVkZ2V3g4d29KM2oxY0UiLCAiX29oSlZ
JUUlCc1U0dXBkTlM0X3c0S2IxTUhxSjBMOXFMR3NoV3E2SlhRcyIsICJ5NTBjemMwSVN
DaHlfYnNiYTFkTW9VdUFPUTVBTW1PU2ZHb0VlODF2MUZVIl0sICJpc3MiOiAiaHR0cHM
6Ly9waWQtaXNzdWVyLmJ1bmQuZGUuZXhhbXBsZSIsICJpYXQiOiAxNjgzMDAwMDAwLCA
iZXhwIjogMTg4MzAwMDAwMCwgInZjdCI6ICJ1cm46ZXVkaTpwaWQ6ZGU6MSIsICJfc2R
fYWxnIjogInNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnY
iOiAiUC0yNTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbER
sczd2Q2VHZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U
2dDRqVDlGMkhaUSJ9fX0.ZOZQTqmq8X1mCyFXi0wbV8xjctX1AlEa5TkdnkKOyWvLfW4
0XDb5oj9tzkgwff5s44IDnrfAdgLtmTcojs97_Q~WyJlSzVvNXBIZmd1cFBwbHRqMXFo
QUp3IiwgImFnZV9lcXVhbF9vcl9vdmVyIiwgeyJfc2QiOiBbIjF0RWl5elBSWU9Lc2Y3
U3NZR01nUFpLc09UMWxRWlJ4SFhBMHI1X0J3a2siLCAiQ1ZLbmx5NVA5MHlKczNFd3R4
UWlPdFVjemFYQ1lOQTRJY3pSYW9ock1EZyIsICJhNDQtZzJHcjhfM0FtSncyWFo4a0kx
eTBRel96ZTlpT2NXMlczUkxwWEdnIiwgImdrdnkwRnV2QkJ2ajBoczJaTnd4Y3FPbGY4
bXUyLWtDRTctTmIyUXh1QlUiLCAiaHJZNEhubUY1YjVKd0M5ZVR6YUZDVWNlSVFBYUlk
aHJxVVhRTkNXYmZaSSIsICJ5NlNGclZGUnlxNTBJYlJKdmlUWnFxalFXejB0TGl1Q21N
ZU8wS3FhekdJIl19XQ~WyJPQktsVFZsdkxnLUFkd3FZR2JQOFpBIiwgIjE4IiwgdHJ1Z
V0~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIm5hdGlvbmFsaXRpZXMiLCBbIkRFI
l1d~eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dCJ9.eyJub25jZSI6ICIxMjM
0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaWVyLmV4YW1wbGUub3JnIiwgIml
hdCI6IDE3NDg1MzcyNDQsICJzZF9oYXNoIjogIlBqTVlmTTA3VmJKZE14TElsdXZSTmI
4OEpGbGpTWDRuLUc0M1VjX0JTUk0ifQ.f3TeS_1BWEG78EbIJRh5wgv8nYumk7euzu6x
gbgpNB4pbQQqgRPWK-vQjlhhgU1EFGZ9LFakFX_0mgul1G_3mw
</sourcecode>
        <t indent="0" pn="section-appendix.a.3-13">This is the payload of the corresponding Key Binding JWT:</t>
        <sourcecode type="json" markers="false" pn="section-appendix.a.3-14">
{
  "nonce": "1234567890",
  "aud": "https://verifier.example.org",
  "iat": 1748537244,
  "sd_hash": "PjMYfM07VbJdMxLIluvRNb88JFljSX4n-G43Uc_BSRM"
}
</sourcecode>
        <t indent="0" pn="section-appendix.a.3-15">After validation, the Verifier will have the following Processed SD-JWT Payload available for further handling:</t>
        <sourcecode type="json" markers="false" pn="section-appendix.a.3-16">
{
  "iss": "https://pid-issuer.bund.de.example",
  "iat": 1683000000,
  "exp": 1883000000,
  "vct": "urn:eudi:pid:de:1",
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
      "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
    }
  },
  "age_equal_or_over": {
    "18": true
  },
  "nationalities": [
    "DE"
  ]
}
</sourcecode>
      </section>
      <section anchor="w3c-verifiable-credentials-data-model-v2-0" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.4">
        <name slugifiedName="name-w3c-verifiable-credentials-">W3C Verifiable Credentials Data Model v2.0</name>
        <t indent="0" pn="section-appendix.a.4-1">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 payload <xref target="VC_DATA_v2.0" format="default" sectionFormat="of" derivedContent="VC_DATA_v2.0"/>.</t>
        <t indent="0" pn="section-appendix.a.4-2">Key Binding is applied
using the Holder's public key passed in a <tt>cnf</tt> claim in the SD-JWT.</t>
        <t indent="0" pn="section-appendix.a.4-3">The following is the input JWT Claims Set:</t>
        <sourcecode type="json" markers="false" pn="section-appendix.a.4-4">
{
  "@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"
  }
}
</sourcecode>
        <t indent="0" pn="section-appendix.a.4-5">The following is the issued SD-JWT:</t>
        <sourcecode type="" markers="false" pn="section-appendix.a.4-6">
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.OZomvwO8iw4db89MYCeeomBVStXkT6u7G7FkicPWZnd2
_hGgr0l_u1NHgPVocuOt-m32Uu6kwtPmYFxKk0AOeA~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~
</sourcecode>
        <t indent="0" pn="section-appendix.a.4-7">The following payload is used for the SD-JWT:</t>
        <sourcecode type="json" markers="false" pn="section-appendix.a.4-8">
{
  "@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",
      "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
      "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
    }
  }
}
</sourcecode>
        <t indent="0" pn="section-appendix.a.4-9">The digests in the SD-JWT payload reference the following Disclosures:</t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-appendix.a.4-10">
          <li pn="section-appendix.a.4-10.1">
            <t indent="0" pn="section-appendix.a.4-10.1.1">Claim <tt>atcCode</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.4-10.1.2">
              <li pn="section-appendix.a.4-10.1.2.1">
                <t indent="0" pn="section-appendix.a.4-10.1.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.4-10.1.2.1.2"><tt>1cF5hLwkhMNIaqfWJrXI7NMWedL-9f6Y2PA52yPjSZI</tt></t>
              </li>
              <li pn="section-appendix.a.4-10.1.2.2">
                <t indent="0" pn="section-appendix.a.4-10.1.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.4-10.1.2.2.2"><tt>WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImF0Y0NvZGUiLCAiSjA3QlgwMyJd</tt></t>
              </li>
              <li pn="section-appendix.a.4-10.1.2.3">
                <t indent="0" pn="section-appendix.a.4-10.1.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.4-10.1.2.3.2"><tt>["2GLC42sKQveCfGfryNRN9w", "atcCode", "J07BX03"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.4-10.2">
            <t indent="0" pn="section-appendix.a.4-10.2.1">Claim <tt>medicinalProductName</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.4-10.2.2">
              <li pn="section-appendix.a.4-10.2.2.1">
                <t indent="0" pn="section-appendix.a.4-10.2.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.4-10.2.2.1.2"><tt>Hiy6WWueLD5bn16298tPv7GXhmldMDOTnBi-CZbphNo</tt></t>
              </li>
              <li pn="section-appendix.a.4-10.2.2.2">
                <t indent="0" pn="section-appendix.a.4-10.2.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.4-10.2.2.2.2"><tt>WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgIm1lZGljaW5hbFByb2R1Y3ROYW1lIiwgIkNPVklELTE5IFZhY2NpbmUgTW9kZXJuYSJd</tt></t>
              </li>
              <li pn="section-appendix.a.4-10.2.2.3">
                <t indent="0" pn="section-appendix.a.4-10.2.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.4-10.2.2.3.2"><tt>["eluV5Og3gSNII8EYnsxA_A", "medicinalProductName", "COVID-19 Vaccine Moderna"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.4-10.3">
            <t indent="0" pn="section-appendix.a.4-10.3.1">Claim <tt>marketingAuthorizationHolder</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.4-10.3.2">
              <li pn="section-appendix.a.4-10.3.2.1">
                <t indent="0" pn="section-appendix.a.4-10.3.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.4-10.3.2.1.2"><tt>Lb027q691jXXl-jC73vi8ebOj9smx3C-_og7gA4TBQE</tt></t>
              </li>
              <li pn="section-appendix.a.4-10.3.2.2">
                <t indent="0" pn="section-appendix.a.4-10.3.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.4-10.3.2.2.2"><tt>WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgIm1hcmtldGluZ0F1dGhvcml6YXRpb25Ib2xkZXIiLCAiTW9kZXJuYSBCaW90ZWNoIl0</tt></t>
              </li>
              <li pn="section-appendix.a.4-10.3.2.3">
                <t indent="0" pn="section-appendix.a.4-10.3.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.4-10.3.2.3.2"><tt>["6Ij7tM-a5iVPGboS5tmvVA", "marketingAuthorizationHolder", "Moderna Biotech"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.4-10.4">
            <t indent="0" pn="section-appendix.a.4-10.4.1">Claim <tt>nextVaccinationDate</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.4-10.4.2">
              <li pn="section-appendix.a.4-10.4.2.1">
                <t indent="0" pn="section-appendix.a.4-10.4.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.4-10.4.2.1.2"><tt>R2fGbfA07Z_YlkqmNZyma1xyyx1XstIiS6B1Ybl2JZ4</tt></t>
              </li>
              <li pn="section-appendix.a.4-10.4.2.2">
                <t indent="0" pn="section-appendix.a.4-10.4.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.4-10.4.2.2.2"><tt>WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm5leHRWYWNjaW5hdGlvbkRhdGUiLCAiMjAyMS0wOC0xNlQxMzo0MDoxMloiXQ</tt></t>
              </li>
              <li pn="section-appendix.a.4-10.4.2.3">
                <t indent="0" pn="section-appendix.a.4-10.4.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.4-10.4.2.3.2"><tt>["eI8ZWm9QnKPpNPeNenHdhQ", "nextVaccinationDate", "2021-08-16T13:40:12Z"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.4-10.5">
            <t indent="0" pn="section-appendix.a.4-10.5.1">Claim <tt>countryOfVaccination</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.4-10.5.2">
              <li pn="section-appendix.a.4-10.5.2.1">
                <t indent="0" pn="section-appendix.a.4-10.5.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.4-10.5.2.1.2"><tt>JzjLgtP29dP-B3td12P674gFmK2zy81HMtBgf6CJNWg</tt></t>
              </li>
              <li pn="section-appendix.a.4-10.5.2.2">
                <t indent="0" pn="section-appendix.a.4-10.5.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.4-10.5.2.2.2"><tt>WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImNvdW50cnlPZlZhY2NpbmF0aW9uIiwgIkdFIl0</tt></t>
              </li>
              <li pn="section-appendix.a.4-10.5.2.3">
                <t indent="0" pn="section-appendix.a.4-10.5.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.4-10.5.2.3.2"><tt>["Qg_O64zqAxe412a108iroA", "countryOfVaccination", "GE"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.4-10.6">
            <t indent="0" pn="section-appendix.a.4-10.6.1">Claim <tt>dateOfVaccination</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.4-10.6.2">
              <li pn="section-appendix.a.4-10.6.2.1">
                <t indent="0" pn="section-appendix.a.4-10.6.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.4-10.6.2.1.2"><tt>zJK_eSMXjwM8dXmMZLnI8FGM08zJ3_ubGeEMJ-5TBy0</tt></t>
              </li>
              <li pn="section-appendix.a.4-10.6.2.2">
                <t indent="0" pn="section-appendix.a.4-10.6.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.4-10.6.2.2.2"><tt>WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRhdGVPZlZhY2NpbmF0aW9uIiwgIjIwMjEtMDYtMjNUMTM6NDA6MTJaIl0</tt></t>
              </li>
              <li pn="section-appendix.a.4-10.6.2.3">
                <t indent="0" pn="section-appendix.a.4-10.6.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.4-10.6.2.3.2"><tt>["AJx-095VPrpTtN4QMOqROA", "dateOfVaccination", "2021-06-23T13:40:12Z"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.4-10.7">
            <t indent="0" pn="section-appendix.a.4-10.7.1">Claim <tt>order</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.4-10.7.2">
              <li pn="section-appendix.a.4-10.7.2.1">
                <t indent="0" pn="section-appendix.a.4-10.7.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.4-10.7.2.1.2"><tt>b0eUsvGP-ODDdFoY4NlzlXc3tDslWJtCJF75Nw8Oj_g</tt></t>
              </li>
              <li pn="section-appendix.a.4-10.7.2.2">
                <t indent="0" pn="section-appendix.a.4-10.7.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.4-10.7.2.2.2"><tt>WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgIm9yZGVyIiwgIjMvMyJd</tt></t>
              </li>
              <li pn="section-appendix.a.4-10.7.2.3">
                <t indent="0" pn="section-appendix.a.4-10.7.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.4-10.7.2.3.2"><tt>["Pc33JM2LchcU_lHggv_ufQ", "order", "3/3"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.4-10.8">
            <t indent="0" pn="section-appendix.a.4-10.8.1">Claim <tt>gender</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.4-10.8.2">
              <li pn="section-appendix.a.4-10.8.2.1">
                <t indent="0" pn="section-appendix.a.4-10.8.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.4-10.8.2.1.2"><tt>3nzLq81M2oN06wdv1shHvOEJVxZ5KLmdDkHEDJABWEI</tt></t>
              </li>
              <li pn="section-appendix.a.4-10.8.2.2">
                <t indent="0" pn="section-appendix.a.4-10.8.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.4-10.8.2.2.2"><tt>WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdlbmRlciIsICJGZW1hbGUiXQ</tt></t>
              </li>
              <li pn="section-appendix.a.4-10.8.2.3">
                <t indent="0" pn="section-appendix.a.4-10.8.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.4-10.8.2.3.2"><tt>["G02NSrQfjFXQ7Io09syajA", "gender", "Female"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.4-10.9">
            <t indent="0" pn="section-appendix.a.4-10.9.1">Claim <tt>birthDate</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.4-10.9.2">
              <li pn="section-appendix.a.4-10.9.2.1">
                <t indent="0" pn="section-appendix.a.4-10.9.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.4-10.9.2.1.2"><tt>Pn1sWi06G4LJrnn-_RT0RbM_HTdxnPJQuX2fzWv_JOU</tt></t>
              </li>
              <li pn="section-appendix.a.4-10.9.2.2">
                <t indent="0" pn="section-appendix.a.4-10.9.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.4-10.9.2.2.2"><tt>WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImJpcnRoRGF0ZSIsICIxOTYxLTA4LTE3Il0</tt></t>
              </li>
              <li pn="section-appendix.a.4-10.9.2.3">
                <t indent="0" pn="section-appendix.a.4-10.9.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.4-10.9.2.3.2"><tt>["lklxF5jMYlGTPUovMNIvCA", "birthDate", "1961-08-17"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.4-10.10">
            <t indent="0" pn="section-appendix.a.4-10.10.1">Claim <tt>givenName</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.4-10.10.2">
              <li pn="section-appendix.a.4-10.10.2.1">
                <t indent="0" pn="section-appendix.a.4-10.10.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.4-10.10.2.1.2"><tt>lF9uzdsw7HplGLc714Tr4WO7MGJza7tt7QFleCX4Itw</tt></t>
              </li>
              <li pn="section-appendix.a.4-10.10.2.2">
                <t indent="0" pn="section-appendix.a.4-10.10.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.4-10.10.2.2.2"><tt>WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgImdpdmVuTmFtZSIsICJNYXJpb24iXQ</tt></t>
              </li>
              <li pn="section-appendix.a.4-10.10.2.3">
                <t indent="0" pn="section-appendix.a.4-10.10.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.4-10.10.2.3.2"><tt>["nPuoQnkRFq3BIeAm7AnXFA", "givenName", "Marion"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.4-10.11">
            <t indent="0" pn="section-appendix.a.4-10.11.1">Claim <tt>familyName</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.4-10.11.2">
              <li pn="section-appendix.a.4-10.11.2.1">
                <t indent="0" pn="section-appendix.a.4-10.11.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.4-10.11.2.1.2"><tt>1lSQBNY24q0Th6OGzthq-7-4l6cAaxrYXOGZpeW_lnA</tt></t>
              </li>
              <li pn="section-appendix.a.4-10.11.2.2">
                <t indent="0" pn="section-appendix.a.4-10.11.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.4-10.11.2.2.2"><tt>WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImZhbWlseU5hbWUiLCAiTXVzdGVybWFubiJd</tt></t>
              </li>
              <li pn="section-appendix.a.4-10.11.2.3">
                <t indent="0" pn="section-appendix.a.4-10.11.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.4-10.11.2.3.2"><tt>["5bPs1IquZNa0hkaFzzzZNw", "familyName", "Mustermann"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.4-10.12">
            <t indent="0" pn="section-appendix.a.4-10.12.1">Claim <tt>administeringCentre</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.4-10.12.2">
              <li pn="section-appendix.a.4-10.12.2.1">
                <t indent="0" pn="section-appendix.a.4-10.12.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.4-10.12.2.1.2"><tt>TCmzrl7K2gev_du7pcMIyzRLHp-Yeg-Fl_cxtrUvPxg</tt></t>
              </li>
              <li pn="section-appendix.a.4-10.12.2.2">
                <t indent="0" pn="section-appendix.a.4-10.12.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.4-10.12.2.2.2"><tt>WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgImFkbWluaXN0ZXJpbmdDZW50cmUiLCAiUHJheGlzIFNvbW1lcmdhcnRlbiJd</tt></t>
              </li>
              <li pn="section-appendix.a.4-10.12.2.3">
                <t indent="0" pn="section-appendix.a.4-10.12.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.4-10.12.2.3.2"><tt>["5a2W0_NrlEZzfqmk_7Pq-w", "administeringCentre", "Praxis Sommergarten"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.4-10.13">
            <t indent="0" pn="section-appendix.a.4-10.13.1">Claim <tt>batchNumber</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.4-10.13.2">
              <li pn="section-appendix.a.4-10.13.2.1">
                <t indent="0" pn="section-appendix.a.4-10.13.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.4-10.13.2.1.2"><tt>V7kJBLK78TmVDOmrfJ7ZuUPHuK_2cc7yZRa4qV1txwM</tt></t>
              </li>
              <li pn="section-appendix.a.4-10.13.2.2">
                <t indent="0" pn="section-appendix.a.4-10.13.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.4-10.13.2.2.2"><tt>WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImJhdGNoTnVtYmVyIiwgIjE2MjYzODI3MzYiXQ</tt></t>
              </li>
              <li pn="section-appendix.a.4-10.13.2.3">
                <t indent="0" pn="section-appendix.a.4-10.13.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.4-10.13.2.3.2"><tt>["y1sVU5wdfJahVdgwPgS7RQ", "batchNumber", "1626382736"]</tt></t>
              </li>
            </ul>
          </li>
          <li pn="section-appendix.a.4-10.14">
            <t indent="0" pn="section-appendix.a.4-10.14.1">Claim <tt>healthProfessional</tt>:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a.4-10.14.2">
              <li pn="section-appendix.a.4-10.14.2.1">
                <t indent="0" pn="section-appendix.a.4-10.14.2.1.1">SHA-256 Hash:</t>
                <t indent="0" pn="section-appendix.a.4-10.14.2.1.2"><tt>1V_K-8lDQ8iFXBFXbZY9ehqR4HabWCi5T0ybIzZPeww</tt></t>
              </li>
              <li pn="section-appendix.a.4-10.14.2.2">
                <t indent="0" pn="section-appendix.a.4-10.14.2.2.1">Disclosure:</t>
                <t indent="0" pn="section-appendix.a.4-10.14.2.2.2"><tt>WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImhlYWx0aFByb2Zlc3Npb25hbCIsICI4ODMxMTAwMDAwMTUzNzYiXQ</tt></t>
              </li>
              <li pn="section-appendix.a.4-10.14.2.3">
                <t indent="0" pn="section-appendix.a.4-10.14.2.3.1">Contents:</t>
                <t indent="0" pn="section-appendix.a.4-10.14.2.3.2"><tt>["HbQ4X8srVW3QDxnIJdqyOA", "healthProfessional", "883110000015376"]</tt></t>
              </li>
            </ul>
          </li>
        </ul>
        <t indent="0" pn="section-appendix.a.4-11">This is an example of an SD-JWT+KB that discloses only <tt>type</tt>, <tt>medicinalProductName</tt>, <tt>atcCode</tt> of the vaccine, <tt>type</tt> of the <tt>recipient</tt>, <tt>type</tt>, <tt>order</tt>, and <tt>dateOfVaccination</tt>:</t>
        <sourcecode type="" markers="false" pn="section-appendix.a.4-12">
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.OZomvwO8iw4db89MYCeeomBVStXkT6u7G7FkicPWZnd2
_hGgr0l_u1NHgPVocuOt-m32Uu6kwtPmYFxKk0AOeA~WyJQYzMzSk0yTGNoY1VfbEhnZ
3ZfdWZRIiwgIm9yZGVyIiwgIjMvMyJd~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwg
ImRhdGVPZlZhY2NpbmF0aW9uIiwgIjIwMjEtMDYtMjNUMTM6NDA6MTJaIl0~WyIyR0xD
NDJzS1F2ZUNmR2ZyeU5STjl3IiwgImF0Y0NvZGUiLCAiSjA3QlgwMyJd~WyJlbHVWNU9
nM2dTTklJOEVZbnN4QV9BIiwgIm1lZGljaW5hbFByb2R1Y3ROYW1lIiwgIkNPVklELTE
5IFZhY2NpbmUgTW9kZXJuYSJd~eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dC
J9.eyJub25jZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaWVyL
mV4YW1wbGUub3JnIiwgImlhdCI6IDE3NDg1MzcyNDQsICJzZF9oYXNoIjogIklvV1VIO
TFsbGYzWEVybDQyYlEzc3hfNTNWMW8xdWpDejA4aERxSEs3RGsifQ.n0vzyIwCFMDVau
EaeJIWEKZZchxXMpXTQewHgAkARbOSZxB09IbXXtHfpoGqO_BtNFN2lShJEIQBGyc-Xp
HigA
</sourcecode>
        <t indent="0" pn="section-appendix.a.4-13">After the validation, the Verifier will have the following Processed SD-JWT Payload available for further handling:</t>
        <sourcecode type="json" markers="false" pn="section-appendix.a.4-14">
{
  "@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"
    }
  }
}
</sourcecode>
      </section>
      <section anchor="elliptic-curve-key-used-in-the-examples" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.5">
        <name slugifiedName="name-elliptic-curve-key-used-in-">Elliptic Curve Key Used in the Examples</name>
        <t indent="0" pn="section-appendix.a.5-1">The following Elliptic Curve public key, represented in JWK format, can be used to validate the Issuer signatures in the above examples:</t>
        <artwork align="left" pn="section-appendix.a.5-2">
{
  "kty": "EC",
  "crv": "P-256",
  "x": "b28d4MwZMjw8-00CG4xfnn9SLMVMM19SlqZpVb_uNtQ",
  "y": "Xv5zWwuoaTgdS6hV43yI6gBwTnjukmFQQnJ_kCxzqk8"
}
</artwork>
        <t indent="0" pn="section-appendix.a.5-3">The public key used to validate a Key Binding JWT can be found in the examples as the content of the <tt>cnf</tt> claim.</t>
      </section>
    </section>
    <section anchor="disclosure_format_considerations" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-disclosure-format-considera">Disclosure Format Considerations</name>
      <t indent="0" pn="section-appendix.b-1">As described in <xref target="creating_disclosures" format="default" sectionFormat="of" derivedContent="Section 4.2"/>, the Disclosure structure is JSON containing a 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 different representations but is semantically equivalent, thus avoiding canonicalization. Some further discussion of the considerations around this design decision follows.</t>
      <t indent="0" pn="section-appendix.b-2">When receiving an SD-JWT, a Verifier must
be able to recompute digests of the disclosed claim values and, given
the same input values, obtain the same digest values as signed by the
Issuer.</t>
      <t indent="0" pn="section-appendix.b-3">Usually, JSON-based formats transport claim values as simple properties of a JSON object such as this:</t>
      <sourcecode type="json" markers="false" pn="section-appendix.b-4">...
  "family_name": "Möbius",
  "address": {
    "street_address": "Schulstr. 12",
    "locality": "Schulpforta"
  }
...
</sourcecode>
      <t indent="0" pn="section-appendix.b-5">However, a problem arises when computation over the data needs 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.</t>
      <t indent="0" pn="section-appendix.b-6">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</t>
      <sourcecode type="json" markers="false" pn="section-appendix.b-7">
...
"family_name": "M\u00f6bius",
"address": {
  "street_address": "Schulstr. 12",
  "locality": "Schulpforta"
}
...
</sourcecode>
      <t indent="0" pn="section-appendix.b-8">or as</t>
      <sourcecode type="json" markers="false" pn="section-appendix.b-9">
...
"family_name": "Möbius",
"address": {"locality":"Schulpforta", "street_address":
   "Schulstr. 12"}
...
</sourcecode>
      <t indent="0" pn="section-appendix.b-10">The two representations of the value in <tt>family_name</tt> are very different on the byte level, but they yield
equivalent objects. The same is true for the representations of <tt>address</tt>, which vary in white space and order of elements in the object.</t>
      <t indent="0" pn="section-appendix.b-11">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 <xref target="RFC8785" format="default" sectionFormat="of" derivedContent="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.</t>
      <t indent="0" pn="section-appendix.b-12">There are generally two approaches to deal with this problem:</t>
      <ol spacing="normal" indent="adaptive" start="1" type="1" pn="section-appendix.b-13">
<li pn="section-appendix.b-13.1" derivedCounter="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.</li>
        <li pn="section-appendix.b-13.2" derivedCounter="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.</li>
      </ol>
      <t indent="0" pn="section-appendix.b-14">Mixed approaches are conceivable, i.e., transferring both the original JSON data
and 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.</t>
      <t indent="0" pn="section-appendix.b-15">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.</t>
      <t indent="0" pn="section-appendix.b-16">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.</t>
      <t indent="0" pn="section-appendix.b-17">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
<xref target="verifier_verification" format="default" sectionFormat="of" derivedContent="Section 7.3"/> for details.</t>
    </section>
    <section numbered="false" anchor="Acknowledgements" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.c-1">We would like to thank <contact fullname="Alen Horvat"/>, <contact fullname="Alex Hodder"/>, <contact fullname="Anders Rundgren"/>, <contact fullname="Arjan Geluk"/>, <contact fullname="Chad Parry"/>, <contact fullname="Christian Bormann"/>, <contact fullname="Christian Paquin"/>,
<contact fullname="Dale Bowie"/>, <contact fullname="Dan Moore"/>, <contact fullname="David Bakker"/>, <contact fullname="David Waite"/>, <contact fullname="Deb Cooley"/>, <contact fullname="Fabian Hauck"/>, <contact fullname="Filip Skokan"/>, <contact fullname="Giuseppe De Marco"/>, <contact fullname="Jacob Ward"/>, <contact fullname="Jeffrey Yasskin"/>, <contact fullname="John Preuß Mattsson"/>, <contact fullname="Joseph Heenan"/>, <contact fullname="Justin Richer"/>, <contact fullname="Kushal Das"/>, <contact fullname="Martin Thomson"/>, <contact fullname="Matthew Miller"/>, <contact fullname="Michael Fraser"/>, <contact fullname="Michael B. Jones"/>, <contact fullname="Mike Prorock"/>, <contact fullname="Nat Sakimura"/>, <contact fullname="Neil Madden"/>, <contact fullname="Oliver Terbu"/>, <contact fullname="Orie Steele"/>, <contact fullname="Paul Bastian"/>, <contact fullname="Peter Altmann"/>, <contact fullname="Pieter Kasselman"/>, <contact fullname="Richard Barnes"/>, <contact fullname="Rohan Mahy"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Ryosuke Abe"/>, <contact fullname="Sami Rosendahl"/>, <contact fullname="Shawn Butterfield"/>, <contact fullname="Shawn Emery"/>, <contact fullname="Simon Schulz"/>, <contact fullname="Takahiko Kawasaki"/>, <contact fullname="Tobias Looker"/>, <contact fullname="Torsten Lodderstedt"/>,
<contact fullname="Vittorio Bertocci"/>, <contact fullname="Watson Ladd"/>,
and <contact fullname="Yaron Sheffer"/> for their contributions (some of which
were substantial) to this document and to the initial set of implementations.

</t>
      <t indent="0" pn="section-appendix.c-2">The work on this document was started at the OAuth Security Workshop 2022 in Trondheim,
Norway.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.d">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="D." surname="Fett" fullname="Daniel Fett">
        <organization showOnFrontPage="true">Authlete</organization>
        <address>
          <email>mail@danielfett.de</email>
          <uri>https://danielfett.de/</uri>
        </address>
      </author>
      <author initials="K." surname="Yasuda" fullname="Kristina Yasuda">
        <organization showOnFrontPage="true">Keio University</organization>
        <address>
          <email>kristina@sfc.keio.ac.jp</email>
        </address>
      </author>
      <author initials="B." surname="Campbell" fullname="Brian Campbell">
        <organization showOnFrontPage="true">Ping Identity</organization>
        <address>
          <email>bcampbell@pingidentity.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
