Delegate SD-JWT
draft-ietf-oauth-delegate-sd-jwt-00

Web Authorization Protocol                                     G. Oliver
Internet-Draft                                                    Google
Intended status: Standards Track                              C. Bormann
Expires: 29 April 2027                                            SPRIND
                                                         26 October 2026

                            Delegate SD-JWT
                  draft-ietf-oauth-delegate-sd-jwt-00

Abstract

   This document specifies an extension to Selective Disclosure JSON Web
   Tokens [RFC9901] to support further delegation from the Holder to a
   Delegate Holder.  This is done by allowing the Key Binding JWT to
   also be an SD-JWT, optionally with its own Key Binding.  This has
   particular applicability to Agentic systems.

Status of This Memo

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

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

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

   This Internet-Draft will expire on 29 April 2027.

Copyright Notice

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

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

Oliver & Bormann          Expires 29 April 2027                 [Page 1]
Internet-Draft               Delegate SD-JWT                October 2026

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Feature Summary . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
     2.1.  Requirements Notation and Conventions . . . . . . . . . .   4
     2.2.  Terms and Definitions . . . . . . . . . . . . . . . . . .   4
   3.  Flow Diagram  . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Concepts  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  Selective Disclosure  . . . . . . . . . . . . . . . . . .   7
     4.2.  Optional Key Binding  . . . . . . . . . . . . . . . . . .   7
     4.3.  Verification  . . . . . . . . . . . . . . . . . . . . . .   7
   5.  Formats . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  dSD-JWT and dSD-JWT+KB Data Formats . . . . . . . . . . .   8
       5.1.1.  Compact Serialization . . . . . . . . . . . . . . . .   8
       5.1.2.  JSON Serialization  . . . . . . . . . . . . . . . . .   9
       5.1.3.  Delegate Payload Disclosure . . . . . . . . . . . . .   9
       5.1.4.  KB-SD-JWT and KB-SD-JWT+KB  . . . . . . . . . . . . .   9
   6.  Verification  . . . . . . . . . . . . . . . . . . . . . . . .  10
   7.  Delegation using Presentation . . . . . . . . . . . . . . . .  11
     7.1.  dSD-JWT Delegation using OpenID4VP  . . . . . . . . . . .  11
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
     8.1.  Mandatory verification of delegate SD-JWT Chain . . . . .  12
     8.2.  Delegation Policy . . . . . . . . . . . . . . . . . . . .  12
     8.3.  Delegate SD-JWT Revocation  . . . . . . . . . . . . . . .  12
   9.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  13
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     10.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Appendix A.  IANA Considerations  . . . . . . . . . . . . . . . .  14
     A.1.  JSON Web Token Claims Registration  . . . . . . . . . . .  14
     A.2.  Media Type Registration . . . . . . . . . . . . . . . . .  14
   Appendix B.  Acknowledgments  . . . . . . . . . . . . . . . . . .  15
   Appendix C.  Document History . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   This is an extension to SD-JWTs [RFC9901], to allow for the creation
   and delegation of new credentials using an existing SD-JWT+KB.

   SD-JWT provides a mechanism for ensuring minimal disclosure in a
   three party model.  This allows an intermediary party (the Holder) to
   choose to remove claims when only a subset is needed by a verifier.
   Additionally SD-JWT+KB allows for proof of possession by the Holder
   using the cnf claim.  The Verifier need only trust the Issuer and its
   policy regarding the cnf key to trust the resulting presentation.

Oliver & Bormann          Expires 29 April 2027                 [Page 2]
Internet-Draft               Delegate SD-JWT                October 2026

   This is achieved using a composite structure of an Issuer-Signed JWT
   containing salted hashes and associated optional disclosures that can
   be omitted by the Holder.  An optional KB-JWT containing transaction-
   specific data and signed by the private key cnf key is used to
   provide cryptographic key binding.

   While it is possible for a Verifier to forward and further down-scope
   a SD-JWT, it is not able to prove that it was the recipient of the
   original SD-JWT+KB presentation, nor is it able to downscope parts of
   the transaction data, which may be relevant for privacy reasons.

   This capability is useful for a ‘delegation’ model, where the Holder
   delegates further presentations of the SD-JWT+KB to a Delegate
   Holder.  Additionally, the Holder should be able to provide
   additional (optionally disclosable) claims as part of the Delegation.

   One example use-case is to delegate to an AI agent the ability to
   perform purchases on the user's behalf, along with constraints on
   valid fulfillment conditions.  The AI Agent can then prove to a
   merchant that it has been authorized to perform a purchase at this
   merchant on the Holder's behalf, without revealing what other
   merchants may have been able to fulfill this purchase.

   The approach taken here is to extend the KB-JWT so that it can be
   used as the start of a new SD-JWT or SD-JWT+KB, linking the resulting
   SD-JWT to the original one.

1.1.  Feature Summary

   This specification defines extensions to the SD-JWT and SD-JWT+KB
   formats:

   1.  dSD-JWT which is a composite structure consisting of an SD-JWT
       and a Key Binding SD-JWT.  The KB-SD-JWT signs over a delegate
       JSON Payload with zero or more disclosures.
       *  This includes an alternative format for a KB-JWT (called a KB-
          SD-JWT) to secure a nested, selectively disclosable JSON
          object.  This is achieved by making the KB-JWT an SD-JWT.
       *  A format for extending the SD-JWT+KB Compact Serialization to
          include a KB-SD-JWT.
       *  An alternative format to do the same for the SD-JWT JSON
          Serialization format.
   2.  dSD-JWT+KB which extends dSD-JWT to include Key Binding, allowing
       the Delegate Holder to demonstrate proof of possession.
       *  This re-uses the KB-JWT mechanism specified by SD-JWT+KB for
          associating and presenting a proof of possession of a key
          pair.

Oliver & Bormann          Expires 29 April 2027                 [Page 3]
Internet-Draft               Delegate SD-JWT                October 2026

       *  This also allows for further delegation of the dSD-JWT+KB with
          the use of additional KB-SD-JWTs.

2.  Conventions and Definitions

2.1.  Requirements Notation and Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [RFC2119].

2.2.  Terms and Definitions

   This specification uses the terms "Disclosure", "Selectively
   Disclosable JWT (SD-JWT)", "Key Binding", "Key Binding JWT (KB-JWT)",
   "Selectively Disclosable JWT with Key Binding (SD-JWT+KB)" defined by
   [RFC9901].

   _Delegated SD-JWT(dSD-JWT)_: A composite structure consisting of an
   SD-JWT and a Key Binding SD-JWT (KB-SD-JWT).  It acts as a chain of
   SD-JWTs where the Key Binding of the previous SD-JWT is used to sign
   the new one, allowing the Verifier to link presentations back to the
   initial Issuer.

   _Delegated SD-JWT with Key Binding (dSD-JWT+KB)_: An extension of the
   dSD-JWT that includes a final Key Binding JWT (KB-JWT).  This allows
   the Delegate Holder to demonstrate proof of possession of the dSD-
   JWT.

   _Key Binding SD-JWT (KB-SD-JWT)_: An alternative format for a KB-JWT
   used to secure a nested, selectively disclosable JSON object (the
   Delegate Payload).  It serves as the KB-JWT for the preceding SD-JWT
   in a chain.

   _Key Binding SD-JWT+KB (KB-SD-JWT+KB)_: A specific type of KB-SD-JWT
   where the typ parameter is set to "kb-sd-jwt+kb".  This type requires
   the Delegate Payload to include a cnf claim.

   _Delegate Payload_: A JSON object (which may be nested and
   selectively disclosable) over which the KB-SD-JWT signs.  In a dSD-
   JWT+KB, this payload MUST include a cnf claim to establish the
   Delegate Holder's key.

   _Issuer_: An entity that creates the initial SD-JWT.

Oliver & Bormann          Expires 29 April 2027                 [Page 4]
Internet-Draft               Delegate SD-JWT                October 2026

   _Holder_: An entity that receives the initial SD-JWT from the Issuer
   and has control of it.  They may present the SD-JWT to a Verifier
   directly or delegate it to a Delegate Holder.

   _Delegate Holder_: An intermediary entity to whom the original Holder
   delegates the SD-JWT.  The Delegate Holder can perform further
   presentations or delegations of the SD-JWT.

   _Verifier_: An entity that requests, checks and extracts the claims
   of the SD-JWT or dSD-JWT.

   _Delegation_: Delegation in this document refers to a Holder or
   Delegate Holder presenting a credential to a Delegate Holder for the
   purpose of further presentation.

3.  Flow Diagram

Oliver & Bormann          Expires 29 April 2027                 [Page 5]
Internet-Draft               Delegate SD-JWT                October 2026

   +----------------------------------------+
   |                                        |
   |                Issuer                  |
   |                                        |
   +----------------------------------------+
                     |
             Issues SD-JWT+KB and
                all Disclosures
                     |
                     v
   +----------------------------------------+
   |                                        |
   |                Holder                  |
   |                                        |
   +----------------------------------------+
                     |
             Delegates SD-JWT+KB,
           selected Disclosures and
             Payload to create a
            dSD-JWT or dSD-JWT+KB,
         including all new disclosures
                     |
                     v
   +----------------------------------------+
   |                                        |
   |         Delegate Holder(s)             |
   |                                        |
   +--+-------------------------------------+
      |   |          |
      +---+---+-----------------------------+
          |          |
          +---+-----------------------------+
                     |
              Presents dSD-JWT or
           dSD-JWT+KB and selected
               Disclosures
                     |
                     v
   +----------------------------------------+
   |                                        |
   |              Verifier(s)               |
   |                                        |
   +--+-------------------------------------+
      |   |   |
      +---+---+-----------------------------+
          |   |
          +---+-----------------------------+

Oliver & Bormann          Expires 29 April 2027                 [Page 6]
Internet-Draft               Delegate SD-JWT                October 2026

      Figure 1: Delegate SD-JWT Issuance, Delegation and Presentation.

4.  Concepts

   At a high level, a dSD-JWT acts as a chain of SD-JWTs where the KB-
   JWT in the preceding SD-JWT+KB fulfills the role of the Issuer-JWT
   for the next.  This allows the Verifier to know the full chain that
   the dSD-JWT went through and link the presentations back to the
   initial Issuer while preserving the principles of Data Minimization.

4.1.  Selective Disclosure

   An dSD-JWT has two different sets of Selective Disclosures:

   *  Selective Disclosures from the original SD-JWT
   *  Selective Disclosures from the new Delegate Payload

   A Delegate Holder may always choose to include or omit selective
   disclosures from the Delegate Payload.  If the Holder wishes to allow
   the Delegate Holder to omit selective disclosures from the preceding
   SD-JWT it MUST omit the sd_hash claim from the KB-JWT and include the
   issuer_jwt_hash claim instead.

4.2.  Optional Key Binding

   Key Binding is required for the initial SD-JWTs and all KB-SD-JWTs
   except the final one.  It is optional for Key Binding to be used for
   the final KB-SD-JWT.  When it is used, the Delegate Holder’s public
   key information is included in the Delegate Payload of the final KB-
   SD-JWT.  This allows the Delegate Holder to create a KB-JWT in future
   presentations using the private key associated with the included
   public key, demonstrating proof of possession.

4.3.  Verification

   At a high level verification works as follows:

   *  The Verifier receives a dSD-JWT or dSD-JWT+KB from the Delegate
      Holder.
   *  The Verifier splits the dSD-JWT into a chain with an SD-JWT, one
      or more KB-SD-JWT and (in the case of a dSD-JWT+KB) a final KB-
      JWT.
   *  The Verifier verifies the first SD-JWT+KB using the Issuer key,
      using the KB-SD-JWT that immediately follows it as the KB-JWT.
   *  For each KB-SD-JWT, the Verifier verifies it as an SD-JWT+KB,
      treating the Delegate Payload as the JWT payload.  The key from
      the cnf claim of the previous SD-JWT is used.

Oliver & Bormann          Expires 29 April 2027                 [Page 7]
Internet-Draft               Delegate SD-JWT                October 2026

   *  If required by policy, the final KB-SD-JWT MUST also be validated
      as an SD-JWT+KB, along with the transaction binding data included
      there.

5.  Formats

5.1.  dSD-JWT and dSD-JWT+KB Data Formats

   A dSD-JWT with a single delegation is composed of:

   *  A SD-JWT
      -  i.e. An issuer-signed JWT
      -  zero or more disclosures
   *  A KB-SD-JWT
      -  Serves as the KB-JWT for the preceding SD-JWT
      -  This is also the SD-JWT containing the Delegated Payload.

   A dSD-JWT+KB with a single delegation is composed of:

   *  A dSD-JWT whose KB-SD-JWT is a KB-SD-JWT+KB
   *  A KB-JWT

   A dSD-JWT or dSD-JWT+KB with multiple delegations is composed of:

   *  A SD-JWT
   *  Two or more KB-SD-JWTs
   *  When the format is dSD-JWT+KB, a KB-JWT.

5.1.1.  Compact Serialization

   The dSD-JWT format extends the SD-JWT format defined in [RFC9901]
   Section 4 by appending a tilde character followed by a KB-SD-JWT:

   <SD-JWT>~~<KB-JWT>~<Delegated Disclosure 1>~...~<Delegated Disclosure M>~

   The <KB-JWT> along with its disclosures is called a KB-SD-JWT.  In
   the examples in this section, <SD-JWT> and <KB-SD-JWT> denote the
   respective structure without its trailing tilde character.

   The dSD-JWT+KB format further extends the dSD-JWT format by appending
   a delegate KB-JWT:

   <SD-JWT>~~<KB-SD-JWT>~<delegate KB-JWT>

   This can be chained by replacing the KB-JWT with another KB-SD-JWT
   instead:

   <SD-JWT>~~<KB-SD-JWT 1>~~...~~<KB-SD-JWT n>~<delegate KB-JWT>

Oliver & Bormann          Expires 29 April 2027                 [Page 8]
Internet-Draft               Delegate SD-JWT                October 2026

   To process a dSD-JWT or a dSD-JWT+KB, the string is split on ~ as
   usual.  The resulting array of components MUST have exactly one empty
   component between the last component of each SD-JWT or KB-SD-JWT and
   the following KB-SD-JWT.  The following KB-SD-JWT is then used as the
   KB-JWT for the preceding SD-JWT.

   dSD-JWT+KB and dSD-JWT formats are differentiated by a trailing ~ for
   dSD-JWT.

5.1.2.  JSON Serialization

   For both the General and Flattened JSON Serialization, the dSD-JWT or
   dSD-JWT+KB is represented as a JSON object.  The only change in
   encoding is to the format of the kb_jwt unprotected header parameter
   ([RFC9901] Section 8.1), whose value now MUST conform to the General
   or Flattened JSON Serialization of an SD-JWT.  The sd_hash and
   issuer_jwt_hash digests MUST be computed over the equivalent Compact
   Serialization as defined in Section 8.1 of [RFC9901].

5.1.3.  Delegate Payload Disclosure

   The delegate payload disclosure is an Array disclosure, which is the
   base64url encoding of [salt, JSON Object Payload].

   The Disclosure Payload MUST follow all rules for the payload of the
   Issuer-signed JWT specified in [RFC9901] Section 4.1.

   The Delegate Disclosures are created as per [RFC9901] Section 4.2.

   The Delegate KB-JWT is a KB-JWT as per [RFC9901] Section 4.3 except
   that the REQUIRED sd_hash is calculated over the preceding KB-SD-JWT
   and its associated disclosures.

5.1.4.  KB-SD-JWT and KB-SD-JWT+KB

   This specifies two new extensions to the KB-JWT.  The following
   additional claims are included:

   *  “*delegate_payload*”: An array of JSON Objects.  If it contains
      more than one element then they MUST all be replaced with
      disclosures.  During the presentation of a dSD-JWT from a Delegate
      Holder to a Verifier exactly one of these MUST be disclosed.
      -  When presenting from a Holder to a new Delegate Holder,
         multiple values being present allows for multiple dSD-JWTs to
         be delegated with a single signature which may be convenient
         when using a signing key that requires a user action per
         signing event.

Oliver & Bormann          Expires 29 April 2027                 [Page 9]
Internet-Draft               Delegate SD-JWT                October 2026

   KB-SD-JWTs MUST conform to all the requirements of a KB-JWT and an
   SD-JWT except as listed below:

   KB-JWT changes:

   *  The typ parameter value MUST be replaced with "kb+sd-jwt" for a
      KB-SD-JWT, and "kb-sd-jwt+kb" for a KB-SD-JWT+KB.
      -  If the typ is KB-SD-JWT+KB then the Delegate Payload MUST
         include a cnf claim.
   *  The sd_hash parameter is OPTIONAL.  If it is not present it MUST
      instead include a issuer_jwt_hash parameter that hashes over only
      the preceding Issuer-signed jwt or KB-SD-JWT+KB and not any
      disclosures.

   When present, the sd_hash is calculated over the preceding SD-JWT or
   KB-SD-JWT, including its disclosures, as described in Section 4.3.1.
   Both sd_hash and issuer_jwt_hash use the hash algorithm of the
   preceding Issuer-signed JWT or KB-SD-JWT+KB, as defined in [RFC9901]
   Section 4.3.1.

   SD-JWT changes:

   *  All claims that are expected to be found in the issuer-signed JWT
      Payload except the _sd_alg claim MUST instead be claims in the
      Delegate Payload.

6.  Verification

   To perform verification of an dSD-JWT or dSD-JWT+KB the following
   steps must be followed.

   1.  Split the dSD-JWT into its component SD-JWTs
       1.  For a dSD-JWT this will be:
           *  A SD-JWT
           *  zero or more KB-SD-JWTs with typ "kb-sd-jwt+kb"
           *  one KB-SD-JWT with typ "kb+sd-jwt" or "kb-sd-jwt+kb"
       2.  For a dSD-JWT+KB this will be:
           *  A SD-JWT
           *  One or more KB-SD-JWTs with typ "kb-sd-jwt+kb"
           *  One KB-JWT
   2.  Validate and process the initial SD-JWT according to [RFC9901]
       Section 7.1.
   3.  For each KB-SD-JWT except the final one:
       1.  Validate and process it according to [RFC9901] Section 7.1
           *  The cnf claim of the preceding component is used as the
              Issuer public key.
           *  Treat the Delegate Payload as the JWT Payload for finding
              all claims other than the _sd_alg claim.

Oliver & Bormann          Expires 29 April 2027                [Page 10]
Internet-Draft               Delegate SD-JWT                October 2026

       2.  Verify that there is exactly one disclosed element in the
           delegate_payload array.
       3.  If the sd_hash claim is present, calculate the digest over
           the preceding SD-JWT or KB-SD-JWT and its disclosures, as
           described in Section 4.3.1, and verify that it matches the
           value of the sd_hash claim.
       4.  Otherwise, verify that the issuer_jwt_hash is present and
           matches the base64url encoded digest of the preceding Issuer-
           signed JWT or KB-SD-JWT+KB.
       5.  Verify the typ in the JOSE header is "kb-sd-jwt+kb"
   4.  For the final KB-SD-JWT:
       1.  Validate and process it according to 3.1 - 3.4
       2.  If the credential is a dSD-JWT+KB then the typ MUST be "kb-
           sd-jwt+kb", otherwise it MUST be "kb+sd-jwt" or "kb-sd-
           jwt+kb"
   5.  If Key Binding is required
       1.  If the credential is a dSD-JWT (without Key Binding), the
           Verifier MUST reject the presentation, as per Section 7.3.
       2.  Follow step 5 of Section 7.3 to verify the KB-JWT, using the
           final KB-SD-JWT to retrieve the Delegate Holder public key.
       3.  Calculate the digest over the final KB-SD-JWT+KB and its
           disclosures as described in Section 4.3.1, and verify that it
           matches the value of the sd_hash claim.

   If any of the steps fail then the presentation is invalid and
   processing MUST be aborted.  Otherwise the list of processed SD-JWT
   and Delegate Payloads MAY be passed to the application to be used for
   their intended purpose.

7.  Delegation using Presentation

   Presentation mechanisms that allow specification of additional
   transaction data within the KB-JWT can be used to perform delegation.
   Below is a description of how this can be done using the OpenID4VP
   presentation protocol.

7.1.  dSD-JWT Delegation using OpenID4VP

   OpenId4VP [OIDF.OID4VP] specifies transaction_data within the
   request, which is included within the KB-JWT.  To delegate an dSD-JWT
   or dSD-JWT+KB the transaction data type delegate MAY be used.  The
   following additional parameters are included in the transaction_data
   object:

   *  “format”: REQUIRED string containing either dSD-JWT or dSD-JWT+KB
   *  “delegate_payload_disclosure”: REQUIRED String containing the
      Array Disclosure of the delegate payload.

Oliver & Bormann          Expires 29 April 2027                [Page 11]
Internet-Draft               Delegate SD-JWT                October 2026

   *  “delegate_disclosures”: OPTIONAL Array of Strings containing the
      Disclosures for the selectively disclosable claims.

   The delegate payload MUST NOT contain any disclosures not provided in
   delegate_disclosures.  The KB-JWT includes the digest of the
   delegate_payload in the delegate_payload claim of the KB-JWT. _sd_alg
   may use any hash algorithm specified for hashing the
   transaction_data.  The Wallet MAY include additional decoy digests.

   Multiple delegate transaction_data MAY be included in the same
   request.  In that case, each MUST have their digest included in the
   delegate_payload.

8.  Security Considerations

   Security Considerations as described in [RFC9901] also apply to
   delegate SD-JWTs.  When the Holder is performing a delegation, they
   are acting as an Issuer of an SD-JWT and so all security
   considerations of an issuer apply to them.

8.1.  Mandatory verification of delegate SD-JWT Chain

   It is critical that the Verifier verifies each KB-SD-JWT in the chain
   and ensures that it is bound to the preceding Issuer JWT or KB-SD-JWT
   with the sd_hash or issuer_jwt_hash.  Without verifying the binding
   in both directions a malicious Delegate Holder may mis-match parts of
   the chain if the Holder cnf is reused.

8.2.  Delegation Policy

   An Issuer or Holder that wishes to limit delegation MAY include such
   constraints as visible claims in the Issuer signed JWT or KB-SD-
   JWT+KB.

8.3.  Delegate SD-JWT Revocation

   While traditional mechanisms of credential revocation can be used
   with delegate SD-JWTs, they present a practical challenge as, unlike
   a traditional Issuer, an individual Holder can not easily distribute
   revocation information to Verifiers.

   Having a short exp and using claims to constrain the usage of the
   delegated SD-JWT limits this problem, as do cases where the Holder
   and the Delegate Holder are managed by the same entity.

Oliver & Bormann          Expires 29 April 2027                [Page 12]
Internet-Draft               Delegate SD-JWT                October 2026

9.  Privacy Considerations

   The privacy considerations in [RFC9901] Section 10 also apply to
   Delegate SD-JWTs.

10.  References

10.1.  Normative References

   [OIDF.OID4VP]
              Terbu, O., Lodderstedt, T., Yasuda, K., Fett, D., and J.
              Heenan, "OpenID for Verifiable Presentations 1.0", 9 July
              2025, <https://openid.net/specs/openid-4-verifiable-
              presentations-1_0.html>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

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

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/info/rfc7519>.

   [RFC9901]  Fett, D., Yasuda, K., and B. Campbell, "Selective
              Disclosure for JSON Web Tokens", RFC 9901,
              DOI 10.17487/RFC9901, November 2025,
              <https://www.rfc-editor.org/info/rfc9901>.

10.2.  Informative References

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

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

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

Oliver & Bormann          Expires 29 April 2027                [Page 13]
Internet-Draft               Delegate SD-JWT                October 2026

Appendix A.  IANA Considerations

A.1.  JSON Web Token Claims Registration

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

   *  Claim Name: issuer_jwt_hash
   *  Claim Description: Digest of the Issuer-JWT to which the KB-SD-JWT
      is tied
   *  Change Controller: IETF
   *  Specification Document(s): [[ Section 5.1.4 of this specification
      ]]

A.2.  Media Type Registration

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

   To indicate that the content is a Key Binding SD-JWT:

   *  Type name: application
   *  Subtype name: kb+sd-jwt
   *  Required parameters: n/a
   *  Optional parameters: n/a
   *  Encoding considerations: binary; A Key Binding SD-JWT is a SD-JWT;
      SD-JWT values are a series of base64url-encoded values (some of
      which may be the empty string) separated by period ('.') and tilde
      ('~') characters.
   *  Security considerations: See the Security Considerations section
      of [[ this specification ]] and [RFC9901].
   *  Interoperability considerations: n/a
   *  Published specification: [[ this specification ]]
   *  Applications that use this media type: Applications utilizing a
      JWT based proof of possession mechanism with further selective
      disclosure.
   *  Fragment identifier considerations: n/a
   *  Additional information:
      -  Magic number(s): n/a
      -  File extension(s): n/a
      -  Macintosh file type code(s): n/a
   *  Person & email address to contact for further information: Gareth
      Oliver, gco@google.com
   *  Intended usage: COMMON
   *  Restrictions on usage: none
   *  Author: Gareth Oliver, gco@google.com

Oliver & Bormann          Expires 29 April 2027                [Page 14]
Internet-Draft               Delegate SD-JWT                October 2026

   *  Change Controller: IETF
   *  Provisional registration?  No

   To indicate that the content is a Key Binding SD-JWT+KB:

   *  Type name: application
   *  Subtype name: kb-sd-jwt+kb
   *  Required parameters: n/a
   *  Optional parameters: n/a
   *  Encoding considerations: binary; A Key Binding SD-JWT+KB is a SD-
      JWT+KB; SD-JWT values are a series of base64url-encoded values
      (some of which may be the empty string) separated by period ('.')
      and tilde ('~') characters.
   *  Security considerations: See the Security Considerations section
      of [[ this specification ]] and [RFC9901].
   *  Interoperability considerations: n/a
   *  Published specification: [[ this specification ]]
   *  Applications that use this media type: Applications utilizing a
      JWT based proof of possession mechanism with further selective
      disclosure.
   *  Fragment identifier considerations: n/a
   *  Additional information:
      -  Magic number(s): n/a
      -  File extension(s): n/a
      -  Macintosh file type code(s): n/a
   *  Person & email address to contact for further information: Gareth
      Oliver, gco@google.com
   *  Intended usage: COMMON
   *  Restrictions on usage: none
   *  Author: Gareth Oliver, gco@google.com
   *  Change Controller: IETF
   *  Provisional registration?  No

Appendix B.  Acknowledgments

   TODO

Appendix C.  Document History

   -00

   *  Initial Working Group Draft (adopted from draft-gco-oauth-
      delegate-sd-jwt)

   [[ pre Working Group Adoption: ]]

   -01

Oliver & Bormann          Expires 29 April 2027                [Page 15]
Internet-Draft               Delegate SD-JWT                October 2026

   *  editorial fixes
   *  change kb+sd-jwt+kb to kb-sd-jwt+kb

   -00

   *  Initial Version

Authors' Addresses

   Gareth Oliver
   Google
   Email: gco@google.com

   Christian Bormann
   SPRIND
   Email: chris.bormann@gmx.de

Oliver & Bormann          Expires 29 April 2027                [Page 16]