Selective Disclosure for JSON Web Tokens

Internet Engineering Task Force (IETF)                           D. Fett
Request for Comments: 9901                                      Authlete
Category: Standards Track                                      K. Yasuda
ISSN: 2070-1721                                          Keio University
                                                             B. Campbell
                                                           Ping Identity
                                                           November 2025

Abstract

本仕様は、JSON Web Signature (JWS) のペイロードとして用いられる JSON データ構造の個々の要素を選択的に開示するための仕組みを定義する。主なユースケースは、JSON Web Token (JWT) の claim を選択的に開示することである。

Status of This Memo

本文書は Internet Standards Track の文書である。

本文書は Internet Engineering Task Force (IETF) の成果物である。IETF コミュニティの合意を反映している。公開レビューを受け、Internet Engineering Steering Group (IESG) により刊行が承認された。Internet Standards に関する詳細は RFC 7841 の Section 2 を参照のこと。

本文書の最新状況、正誤表、フィードバックの提供方法に関する情報は、以下から入手できる。

https://www.rfc-editor.org/info/rfc9901

Copyright Notice

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.

1. Introduction

システム間で JSON データをやり取りする際、改ざんに対して保護するために JSON Web Signature (JWSs) [RFC7515] が用いられることが多い。JWS の一般的な用途として JSON Web Token (JWT) [RFC7519] があり、これはユーザーのアイデンティティを表現するためにしばしば使用される形式である。例えば OpenID Connect [OpenID.Core] で定義される ID Token は JWT であり、Relying Party (RP) が利用できるようにサーバーが作成したユーザーの claim を含む。OpenID Connect のように、JWT がサーバーから Relying Party (RP) へ直ちに送られる場合、サーバーは発行時点で JWT に含めるユーザーの claim を選択できるため、JWT を検証する Relying Party (RP) に共有される情報を最小化できる。

もう一つのモデルとして、JWT の発行と提示を完全に分離するものが現れつつある。このモデルでは、多数の claim を含む JWT が中間の当事者に発行され、その当事者が JWT を保持する（Holder）。Holder はその後、JWT 内の claim の一部だけを必要とする可能性がある複数の検証当事者（Verifiers）に対して JWT を提示できる。例えば、JWT が住所と生年月日の両方を表す claim を含む場合、Holder はある Verifier には住所のみを開示し、別の Verifier には生年月日のみを開示することを選択できる。

このモデルと最小開示のプライバシー原則を併せて考えると、Verifier が提示されたデータの真正性を確認できることを保証しつつ、データ要素を選択的に開示できる仕組みが必要となる。本仕様は、JWS の JSON ペイロードに対するそのような仕組みを定義し、主なユースケースとして JWT を想定する。

Selectively Disclosable JWT (SD-JWT) は「salted hashes」と呼ばれる手法に基づく。すなわち、選択的に開示できるようにすべき任意のデータ要素について、SD-JWT の Issuer は、JWS 構造の JSON ペイロードにそのデータの平文を含めない。代わりに、そのデータの digest をその位置に置く。Verifier への提示に際して、Holder は署名済みペイロードとともに、開示したい claim の平文を送る。Verifier は平文データから digest を計算し、それが署名済みペイロードに含まれていることを確認できる。さらに、Verifier が非開示データ要素の平文値を推測できないようにするため、digest の作成時には追加の salt 値を用い、開示時にはその salt 値を平文と併せて送る。

Holder の同意なしに SD-JWT が Verifier に提示される攻撃を防ぐため、本仕様はさらに、Holder の管理下にある鍵に SD-JWT を結び付ける仕組み（Key Binding）を定義する。Key Binding が強制される場合、Holder は SD-JWT 自体に含まれる公開鍵に対応する秘密鍵の所持を証明しなければならない。通常は、取引ごとのデータを含むデータ構造に対して署名することでこれを行い、本仕様ではそのデータ構造を Key Binding JWT と定義する。Key Binding JWT を伴う SD-JWT を、本仕様では「SD-JWT+KB」と呼ぶ。

1.1. Feature Summary

本仕様は、主要なデータ形式を 2 つ定義する:

SD-JWT は複合構造であり、JWS に加えて任意の Disclosures から構成され、JWS ペイロードの一部を選択的に開示できる。以下を含む:
- ネストした JSON データ構造における選択的開示を可能にする形式。選択的に開示可能なオブジェクトのプロパティ（name/value ペア）と配列要素をサポートする。
- 選択的に開示可能なデータ項目を符号化するための形式。
- JWS Compact Serialization を拡張する形式。Issuer が署名した JSON データ構造と、開示可能なデータ項目とをまとめて転送できるようにする。
- 代替として、JWS JSON Serialization を拡張する形式。これも Issuer が署名した JSON データ構造と Disclosure データの転送を可能にする。
SD-JWT+KB は、SD-JWT と、Verifier に提示して検証できる暗号学的な Key Binding からなる複合構造である。以下を含む:
- SD-JWT を鍵ペアと関連付ける仕組み。
- 関連付けられた鍵ペアの秘密鍵を所持していることの証明を可能にする Key Binding JWT（KB-JWT）の形式。
- SD-JWT と KB-JWT をまとめて転送するために SD-JWT 形式を拡張する形式。

1.2. Conventions and Terminology

本文書中のキーワード「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「NOT RECOMMENDED」「MAY」「OPTIONAL」は、ここに示すようにすべて大文字で現れる場合に限り、BCP 14 [RFC2119] [RFC8174] に記載のとおりに解釈される。

Base64url:\ [RFC7515] の Section 2 で定義された、パディングなしの URL セーフな base64 エンコーディングを指す。

Claim:\ 本文書では、一般にオブジェクトのプロパティ（name/value ペア）および配列要素を指す。

Selective Disclosure:\ Issuer が発行した JWT に含まれる claim の部分集合を、Holder が Verifier に開示する処理。

Selectively Disclosable JWT (SD-JWT):\ Issuer が署名した JWT（JWS。 [RFC7515] を参照）と 0 個以上の Disclosures からなる複合構造であり、本仕様で定義する選択的開示をサポートする。通常の claim と、選択的に開示可能な claim の digest の両方を含み得る。

Disclosure:\ salt、claim 名（claim が name/value ペアのときに存在し、配列要素のときには存在しない）、および claim 値を含む JSON 配列を base64url でエンコードした文字列。Disclosure は当該 claim の digest を計算するために使用される。用語 Disclosure は base64url エンコードされた文字列全体を指す。

Key Binding:\ 提示時に秘密鍵の管理を証明することにより、Holder が SD-JWT を所持していることを証明する能力。Key Binding を利用する場合、SD-JWT には Holder が管理する秘密鍵に対応する公開鍵（またはその公開鍵への参照）が含まれる。

Key Binding JWT (KB-JWT):\ Key Binding JWT は、SD-JWT のペイロードに含まれる鍵を用いてそのペイロードが署名され、かつ KB-JWT が自身の sd_hash claim に SD-JWT の hash を含むとき、特定の SD-JWT に「結び付けられている」と言う。その形式は Section 4.3 で定義される。

Selectively Disclosable JWT with Key Binding (SD-JWT+KB):\ SD-JWT と、その SD-JWT に結び付けられた Key Binding JWT からなる複合構造。

Processed SD-JWT Payload:\ Issuer が署名した SD-JWT の検証と処理の結果として得られる JSON オブジェクト。digest のプレースホルダーが、Disclosures から得られる対応する値で置き換えられている。

Issuer:\ SD-JWT を作成するエンティティ。

Holder:\ Issuer から SD-JWT を受け取り、それらを管理しているエンティティ。本仕様の文脈では、実際のユーザー、当該ユーザーが所有する支援ハードウェアおよびソフトウェア、またはその両方を指し得る。

Verifier:\ SD-JWT と、それに対応する Disclosures から claim を要求し、確認し、抽出するエンティティ。

2. Flow Diagram

          +------------+
          |            |
          |   Issuer   |
          |            |
          +------------+
                |
           SD-JWT を発行
     すべての Disclosures を含む
                |
                v
          +------------+
          |            |
          |   Holder   |
          |            |
          +------------+
                |
    SD-JWT または SD-JWT+KB を提示
   選択された Disclosures を含む
                |
                v
          +-------------+
          |             |+
          |  Verifiers  ||+
          |             |||
          +-------------+||
           +-------------+|
            +-------------+

          図 1: SD-JWT の発行および提示フロー

3. Concepts

本セクションでは、Section 4 で説明するデータ形式から抽象化し、概念レベルで SD-JWT とそれに対応する Disclosures および Key Binding を説明する。

3.1. SD-JWT and Disclosures

SD-JWT の本質は、選択的に開示可能な claim に対する digest を含む、デジタル署名された JSON 文書であり、Disclosures は文書の外側に置かれる。Disclosures は署名を壊すことなく省略でき、またそれらへの改変は検出できる。選択的に開示可能な claim は、個々のオブジェクトのプロパティ（name/value ペア）または配列要素である。

各 digest 値は、対応する Disclosure の完全性を保証し、それに対応付く。digest 値は Disclosures に対して hash 関数を適用して計算される。各 Disclosure は、暗号学的に安全なランダム salt、claim 名（claim がオブジェクトのプロパティの場合のみ）、および claim 値を含む。Disclosures は Section 4 で定義する形式により SD-JWT とともに Holder に送られる。SD-JWT を Verifier に提示する際、Holder はその Verifier に公開したい claim の Disclosures のみを含める。

SD-JWT は、Verifier に常に開示される平文の claim を含んでもよい（MAY）。

3.2. Disclosing to a Verifier

SD-JWT の claim 値の部分集合を Verifier に開示するために、Holder は、選択的に解放する claim の Disclosures のみを SD-JWT の一部として Verifier に送る。

3.3. Optional Key Binding

Key Binding は任意の機能である。ユースケースにより Key Binding が必要な場合、SD-JWT は Holder が管理する鍵素材に関する情報を含まなければならない（MUST）。

注: 公開鍵を SD-JWT に含める方法は Section 4.1.2 に記述する。

Verifier が Key Binding を要求する場合、Holder は SD-JWT と、その SD-JWT に結び付けられた Key Binding JWT からなる SD-JWT+KB を提示する。Key Binding JWT は、Holder の秘密鍵による署名を次のものに対して符号化する:

SD-JWT の hash
署名の新鮮性を確保するための nonce
本文書の意図された Verifier を示す audience 値

Key Binding JWT の形式の詳細は Section 4.3 に記述する。

3.4. Verification

高いレベルでは、Verifier は

Holder から SD-JWT または SD-JWT+KB のいずれかを受け取り
Issuer の公開鍵を用いて SD-JWT（または SD-JWT+KB 内の SD-JWT）上の署名を検証し
Verifier のポリシーが Key Binding を要求する場合、SD-JWT に含まれる（または参照される）公開鍵を用いて KB-JWT 上の署名を検証し
Holder が選択した Disclosures に対して digest を計算し、各 digest が SD-JWT に含まれていることを検証する

詳細なアルゴリズムは Section 7.3 に記述する。

4. SD-JWT and SD-JWT+KB Data Formats

SD-JWT は、次の要素で構成される。

Issuer によって署名された JWT
0 個以上の Disclosure

SD-JWT+KB は、次の要素で構成される。

SD-JWT（すなわち、Issuer によって署名された JWT と 0 個以上の Disclosure）
Key Binding JWT

Issuer によって署名された JWT、Disclosure、および Key Binding JWT については、それぞれ 4.1 節、4.2 節、4.3 節で説明する。

SD-JWT のコンパクトなシリアライズ形式は、各パートを 1 文字のチルダ (~) で区切って連結したものであり、次のとおりである。ここで、D.1 から D.N は、それぞれの Disclosure を表す。

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

連結されるパートの順序は、次のとおりでなければならない。

Issuer によって署名された JWT
チルダ文字 (~)
0 個以上の Disclosure（それぞれの後ろにチルダ文字が付く）
最後に任意の Key Binding JWT

Key Binding JWT が存在しない場合は、次を満たさなければならない。

最後の要素は空文字列でなければならない
最後の区切りのチルダ文字は省略してはならない

SD-JWT+KB のシリアライズ形式は、Key Binding JWT を連結することで SD-JWT 形式を拡張する。

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

これら 2 つの形式は、SD-JWT に存在する末尾の ~ 文字によって区別できる。

SD-JWT を想定する Verifier は、チルダで区切られた最後の構成要素が空であることを検証しなければならない。

SD-JWT+KB を想定する Verifier は、チルダで区切られた最後の構成要素が有効な KB-JWT であることを検証しなければならない。

Disclosure は、そこに含まれるダイジェスト値を介して Issuer によって署名された JWT と結び付けられる。

Holder に対して発行する際、Issuer は関連するすべての Disclosure を SD-JWT に含める。

Verifier に提示する際、Holder は SD-JWT 内の Disclosure のうち選択した集合だけを送信する。

Holder は Disclosure の任意の部分集合を Verifier に送ってよい。すなわち、1 つも送らない、いくつか送る、またはすべての Disclosure を送る、のいずれでもよい。

Holder が Verifier に開示したくないデータについては、Holder は Disclosure を送ってはならず、また salt 値を他の方法で明らかにしてもならない。

Holder は、発行された SD-JWT に含まれていなかった Disclosure を送ってはならず、また同じ Disclosure を複数回送ってはならない。

SD-JWT 形式をさらに説明するため、次の例では、構成要素の有無が異なるいくつかの SD-JWT の組み合わせを示す。

Disclosure を含まない SD-JWT:

<Issuer-signed JWT>~

Disclosure を含む SD-JWT:

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

Disclosure を含まない SD-JWT+KB:

<Issuer-signed JWT>~<KB-JWT>

Disclosure を含む SD-JWT+KB:

<Issuer-signed JWT>~<Disclosure 1>~<Disclosure N>~<KB-JWT>

SD-JWT 形式の別の説明として、SD-JWT、SD-JWT+KB、および各種の構成要素についての ABNF [RFC5234] をここに示す（祝う人のために）。

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

4.1. Issuer-Signed JWT

SD-JWT は JWT コンポーネントを持ち、これは Issuer の秘密鍵で署名されなければならない（MUST）。none アルゴリズムを使用してはならない（MUST NOT）。

SD-JWT のペイロードは、次の規則に従う JSON オブジェクトである:

ペイロードは、Section 4.1.1 で説明する _sd_alg キーを含んでもよい（MAY）。
ペイロードは、Section 4.2 に記述する方法で作成・整形された、対応する claim の選択的開示を可能にするための 1 つ以上の Disclosure の digest を含んでもよい（MAY）。
ペイロードは、SD-JWT 内の実際の claim 数を分かりにくくするため、Section 4.2.5 に記述する方法で作成・整形された 1 つ以上の decoy digest を含んでもよい（MAY）。
ペイロードは、恒久的に開示される 1 つ以上の claim を含んでもよい（MAY）。
ペイロードは、Section 4.1.2 で説明するように、Holder の公開鍵（複数可）またはそれらへの参照（複数可）を含んでもよい（MAY）。
ペイロードは、SD-JWT を利用するアプリケーションによって定義または要求される iss、iat などの追加の claim を含んでもよい（MAY）。
ペイロードは、Section 4.2.4.1 および 4.2.4.2 に記述する digest の伝達を目的とする場合を除き、claim _sd または ... を含んではならない（MUST NOT）。

同じ digest 値は SD-JWT 内に複数回現れてはならない（MUST NOT）。

SD-JWT のアプリケーションおよびプロファイルは、明示的に型付けされるべきである（SHOULD）。詳細は Section 9.11 を参照のこと。

どの claim を Holder が選択的に開示できるようにし、どれをそうしないかを決めるのは Issuer である。想定するユースケースにおいて特定の claim を Verifier から隠す必要がない場合など、claim を平文として含めてもよい（MAY）。exp のような有効性制御に関わる claim を選択的に開示可能にする際の考慮事項は Section 9.7 を参照のこと。

選択的に開示できない claim は、他のいかなる JSON 構造と同様に、平文で SD-JWT に含められる。

4.1.1. Hash Function Claim

claim _sd_alg は、Section 4.2 に記述する digest を生成するために Issuer が使用する hash アルゴリズムを示す。使用する場合、この claim は SD-JWT ペイロードのトップレベルに現れなければならない（MUST）。ペイロード内のネストしたオブジェクトでは使用してはならない（MUST NOT）。トップレベルに _sd_alg claim が存在しない場合、既定値 sha-256 を使用しなければならない（MUST）。

この claim 値は、hash アルゴリズム識別子を表す大小文字を区別する文字列である。hash アルゴリズム識別子は、「Named Information Hash Algorithm Registry」[Hash.Algs] の「Hash Name String」列にある hash アルゴリズム値、または別仕様および／または本仕様のプロファイルで定義された値でなければならない（MUST）。

相互運用性を促進するため、実装は sha-256 hash アルゴリズムをサポートしなければならない（MUST）。

salt のエントロピー、salt の最小長、および hash アルゴリズムの選択に関する要件は Section 9 を参照のこと。

4.1.2. Key Binding

Issuer が Key Binding を可能にしたい場合、[RFC7800] で定義される cnf claim を用いて、Holder に関連付けられた公開鍵、またはそれへの参照を含める。[RFC7800] の Section 3.2 で定義される jwk 確認方式を用いることが推奨されるが、他の確認方式も使用できる。

[RFC7800] で述べられているとおり、アプリケーションが同一の SD-JWT 内で複数の proof-of-possession 鍵を表現する必要がある場合、それを達成する一つの方法は、追加の proof-of-possession 鍵情報を保持するために cnf に加えて別の claim 名を使用することである。

Holder の鍵ペアがどのように確立されるかを述べることは、本書のスコープ外である。例えば、Holder が鍵ペアを作成して公開鍵を Issuer に提供してもよい（MAY）。Issuer が Holder のために鍵ペアを作成してもよい（MAY）。または、Holder と Issuer が事前に確立された鍵素材を用いてもよい（MAY）。

注: 本文書全体の例では、cnf claim の jwk メンバーを用い、公開鍵の生値を値として SD-JWT に含めている。

4.2. Disclosures

Disclosures は、claim がオブジェクトのプロパティ（name/value ペア）か配列要素かに応じて異なる方法で作成される。

claim がオブジェクトのプロパティである場合、Issuer は Section 4.2.1 に記述する Disclosure を作成する。
claim が配列要素である場合、Issuer は Section 4.2.2 に記述する Disclosure を作成する。

4.2.1. Disclosures for Object Properties

オブジェクトのプロパティである各 claim について、選択的に開示できるようにする場合、Issuer は次のとおり Disclosure を作成しなければならない（MUST）:

次の順序で 3 要素からなる JSON 配列を作成する:
1. salt 値。文字列でなければならない（MUST）。セキュリティ上の考慮事項は Section 9.3 を参照のこと。salt の推奨エントロピーを達成するため、Issuer は暗号学的に安全なランダムデータ 128 ビットを base64url でエンコードして文字列を生成してもよい（MAY）。salt 値は、選択的に開示される各 claim ごとに一意でなければならない（MUST）。Issuer は Holder 以外のいかなる当事者にも salt 値を明かしてはならない（MUST NOT）。
2. claim 名、またはキー。通常の JWT ペイロードで使用されるのと同様である。文字列でなければならず（MUST）、_sd、...、または恒久的に開示される claim としてオブジェクト内に存在する claim 名であってはならない（MUST NOT）。
3. claim 値。通常の JWT ペイロードで使用されるのと同様である。値は JSON で許可される任意の型（数値、文字列、真偽値、配列、null、オブジェクトを含む）でよい。

JSON 配列の UTF-8 バイト列を base64url エンコードする。この文字列が Disclosure である。

注: この順序は可読性の観点から決められた。salt は SD-JWT 内で一定の長さであり、claim 名も概ね同程度の長さで、claim 値はサイズが変動し、大きなオブジェクトになり得るためである。

Example

配列は次のとおり作成される:

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

得られる Disclosure は次のとおり:

WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNw7ZiaXVzI
l0

JSON 表現における空白の違い、Unicode 文字のエンコーディング、オブジェクトのプロパティの並び順などの差異は許容され、base64url エンコード前に正規化を行う必要はない。なぜなら、digest は base64url エンコードされた値そのものに対して計算されるからである。例えば、次の文字列はいずれも有効であり、同じ claim 値 "Möbius" をエンコードしている:

Unicode のウムラウトを別の方法でエンコードしたもの:

text WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNXHUwMG Y2Yml1cyJd

空白を含まないもの:

text WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsImZhbWlseV9uYW1lIiwiTcO2Yml1cy Jd

要素間に改行文字を入れたもの:

text WwoiXzI2YmM0TFQtYWM2cTJLSTZjQlc1ZXMiLAoiZmFtaWx5X25hbWUiLAoiTcO2Ym l1cyIKXQ

ただし、digest は対応する base64url エンコード値そのものに対して計算されるため、結果として Issuer が選んだ表現の差異が署名され、この特定の SD-JWT の文脈ではそれが不変となる。

Disclosure 形式のアプローチに関する追加の考慮事項は Appendix B を参照のこと。

4.2.2. Disclosures for Array Elements

配列要素である各 claim について、選択的に開示できるようにする場合、Issuer は次のとおり Disclosure を作成しなければならない（MUST）:

配列は、次の順序で 2 要素を含まなければならない（MUST）:
1. Section 4.2.1 に記述する salt 値。
2. 隠す対象の配列要素。この値は、数値、文字列、真偽値、配列、オブジェクトを含む、JSON で許可される任意の型でよい。

Disclosure 文字列は、Section 4.2.1 に記述したとおり、得られた JSON 配列の UTF-8 バイト列を base64url エンコードして作成される。JSON エンコード結果の差異に関する同じ考慮事項が適用される。

Example

例えば、次の JWT Claims Set における nationalities 配列の 2 番目の要素に対する Disclosure は:

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

まず次の配列を作成することで生成できる:

["lklxF5jMYlGTPUovMNIvCA", "FR"]

得られる Disclosure は次のとおり:

WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIkZSIl0

注: 配列のサイズだけでも、意図しない情報が漏れる可能性がある。Section 4.2.5 に記述する decoys を用いて配列サイズを一貫してパディングすると、特定のインスタンスに実際に存在する要素数を分かりにくくする助けとなる。

4.2.3. Hashing Disclosures

SD-JWT に Disclosures への参照を埋め込むため、各 Disclosure は Section 4.1.1 の _sd_alg claim で指定された hash アルゴリズム、またはアルゴリズム指定がない場合は SHA-256 によって hash 化される。得られた digest は次に述べるとおり、元の claim 値の代わりに SD-JWT ペイロードへ含められる。

digest は、Disclosure である base64url エンコード値の US-ASCII バイト列に対して計算されなければならない（MUST）。これは JWS [RFC7515] および JWE [RFC7516] の慣例に従う。digest のバイト列は base64url エンコードされなければならない（MUST）。

重要な点:

hash 関数への入力は base64url エンコードされた Disclosure でなければならず（MUST）、base64url 文字列によってエンコードされたバイト列そのものではない。
hash 関数出力のバイト列は base64url エンコードされなければならず（MUST）、digest バイト列の（しばしば用いられる）16 進表現を構成するバイト列ではない。

例えば、Section 4.2.1 の family_name claim に対する Disclosure

WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNw7ZiaXVzIl
0

の base64url エンコードされた SHA-256 digest は次である:

X9yH0Ajrdm1Oij4tWso9UzzKJvPoDxwmuEcO3XAdRC0

4.2.4. Embedding Disclosure Digests in SD-JWTs

選択的に開示可能な claim については、Disclosures の digest が、claim 自体の代わりに Issuer が署名した JWT へ埋め込まれる。埋め込み方法の詳細は、claim がオブジェクトのプロパティ（name/value ペア）か配列要素かにより異なる。

claim がオブジェクトのプロパティである場合、Issuer は Section 4.2.4.1 に記述する Disclosure digest を埋め込む。
claim が配列要素である場合、Issuer は Section 4.2.4.2 に記述する Disclosure digest を作成する。

4.2.4.1. Object Properties

オブジェクトのプロパティに対する Disclosures の digest は、オブジェクト内の新しいキー _sd の下の配列に追加される。_sd キーは文字列の配列を参照しなければならず（MUST）、各文字列は Disclosure の digest または Section 4.2.5 に記述する decoy digest である。_sd キーは、トップレベルを含む JSON オブジェクト階層の任意のレベルに存在できる。Section 6 に記述するように深くネストしていてもよく、また Section 4.2.6 に記述する recursive Disclosures 内に存在してもよい。

Issuer がそのレベルでいずれの claim も選択的に開示しないと決めた場合、配列は空でもよい（MAY）。ただし、空間節約のため、この場合は _sd キーを省略することが推奨される（RECOMMENDED）。

Issuer は、配列内の claim の元の順序を隠さなければならない（MUST）。これを確実にするため、Section 4.2.5 に記述する decoy digest を追加した後に、hash 配列を（英数字順またはランダムなどで）シャッフルすることが推奨される（RECOMMENDED）。正確な手法は、要素の元の順序に依存しない限り重要ではない。

Example:

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

4.2.4.2. Array Elements

配列要素に対する Disclosures の digest は、元の claim 値が配列内にあったのと同じ位置に配列へ追加される。各 digest について、{"...": "<digest>"} という形式のオブジェクトが配列に追加される。キーは常に文字列 ...（三つのドット）でなければならない（MUST）。値は Section 4.2.3 に記述する方法で作成された Disclosure の digest でなければならない（MUST）。オブジェクトに他のキーが存在してはならない（MUST NOT）。

Example:

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

Section 7.3 に記述するとおり、Verifier は、Disclosure を受け取っていない選択的に開示可能な配列要素をすべて無視する。上の例では、2 番目の要素に一致する Disclosure を受け取らない限り、検証処理は 2 要素の配列 ["DE", "US"] を出力する。一致する Disclosure を受け取った場合、出力は 3 要素の配列 ["DE", "FR", "US"] となる。

4.2.5. Decoy Digests

Issuer は、いかなる claim にも関連付けられていない追加の digest を SD-JWT ペイロードに加えてもよい（MAY）。そのような「decoy」digest の目的は、敵対的な Verifier が SD-JWT に含まれる元の claim 数や配列要素数を把握することをより困難にすることである。decoy digest は、オブジェクト用の _sd 配列にも配列内にも追加してよい（MAY）。

decoy digest は、暗号学的に安全なランダム数に対して hash を計算して作成することが推奨される（RECOMMENDED）。その digest のバイト列は上記と同様に base64url エンコードされなければならない（MUST）。Disclosures と同じ digest 関数が使用されなければならない（MUST）。

decoy digest については Holder に Disclosure は送られない。すなわち Holder は、いかなる Disclosure にも対応しない digest を目にする。追加のプライバシー考慮事項は Section 10.4 を参照のこと。

可読性と再現性を確保するため、本仕様の例には、明示的に述べない限り decoy digest は含まれない。decoy digest を含む例は Appendix A.1 を参照のこと。

4.2.6. Recursive Disclosures

上記のアルゴリズムは「recursive Disclosures」と互換である。これは、ある選択的に開示されたフィールドが、さらに別の選択的に開示可能なフィールドの存在を明らかにするものである。

Example の JSON 構造:

{
  "family_name": "Möbius",
  "nationalities": ["DE", "FR", "UK"]
}

Holder が複数の国籍を持つ場合、Issuer は国籍に関する記述の存在自体を隠したい一方で、Holder がそれぞれの国籍を個別に開示できるようにもしたいかもしれない。これは、まず nationalities 配列内の各エントリを選択的に開示可能にし、その後、nationalities フィールド全体を選択的に開示可能にすることで達成できる。

次は、nationalities 配列内の各エントリを選択的に開示可能にした例:

{
  "family_name": "Möbius",
  "nationalities": [
    { "...": "PmnlrRjhLcwf8zTDdK15HVGwHtPYjddvD362WjBLwro" },
    { "...": "r823HFN6Ba_lpSANYtXqqCBAH-TsQlIzfOK0lRAFLCM" },
    { "...": "nP5GYjwhFm6ESlAeC4NCaIliW4tz0hTrUeoJB3lb5TA" }
  ]
}

Disclosures の内容（対応関係の表現）:

PmnlrRj... = ["16_mAd0GiwaZokU26_0i0h","DE"]
r823HFN... = ["fn9fN0rD-fFs2n303ZI-0c","FR"]
nP5GYjw... = ["YIKesqOkXXNzMQtsX_-_lw","UK"]

続いて nationalities 配列全体を選択的に開示可能にする:

{
  "family_name": "Möbius",
  "_sd": ["5G1srw3RG5W4pVTwSsYxeOWosRBbzd18ZoWKkC-hBL4"]
}

Disclosures の内容:

[
  ["16_mAd0GiwaZokU26_0i0h", "DE"],
  ["fn9fN0rD-fFs2n303ZI-0c", "FR"],
  ["YIKesqOkXXNzMQtsX_-_lw", "UK"],
  [
    "4drfeTtSUK3aY_-PF12gcX",
    "nationalities",
    [
      { "...": "PmnlrRjhLcwf8zTDdK15HVGwHtPYjddvD362WjBLwro" },
      { "...": "r823HFN6Ba_lpSANYtXqqCBAH-TsQlIzfOK0lRAFLCM" },
      { "...": "nP5GYjwhFm6ESlAeC4NCaIliW4tz0hTrUeoJB3lb5TA" }
    ]
  ]
]

この Disclosures の集合があれば、Holder は hash PmnlrRj... を持つ Disclosure を含めることで "DE" 国籍のみを開示でき、また PmnlrRj... と r823HFN... の両方を含めることで "DE" と "FR" の両方を開示しつつ "UK" 国籍は隠せる。どちらの場合でも、Holder は、各要素を含む nationalities フィールドを開示するために、hash 5G1srw3... を持つ Disclosure も含める必要がある。

recursive なマスキングを行うと、SD-JWT 内の Disclosure オブジェクト間に依存関係が導入されることに注意する。r823HFN... Disclosure は 5G1srw3... Disclosure なしには使用できない。なぜなら Verifier は、r823HFN... Disclosure の内容をどこに挿入すべきかを示す一致する hash を持たないからである。ある Disclosure オブジェクトが SD-JWT に含まれる場合、SD-JWT は、その Disclosure オブジェクトを処理するために必要な他のすべての Disclosure オブジェクトも含まなければならない（MUST）。言い換えると、SD-JWT 内の任意の Disclosure オブジェクトは、Issuer が署名した JWT 内の claim に「接続」しなければならず（MUST）、必要に応じて中間の Disclosure オブジェクトを介する。上の例では、5G1srw3... Disclosure オブジェクトも含めずに、PmnlrRj...、r823HFN...、nP5GYjw... のいずれか 1 つだけの Disclosure オブジェクトを含めることは不正である。

4.3. Key Binding JWT

本セクションは、Holder の秘密鍵により SD-JWT に対して行う署名を符号化する Key Binding JWT を定義する。

Key Binding JWT は [RFC7519] に従う JWT でなければならず（MUST）、次の要素を含まなければならない（MUST）:

JOSE header では:
- typ: REQUIRED。kb+jwt でなければならない（MUST）。これは [RFC8725] の Section 3.11 で推奨されるとおり、Key Binding JWT を明示的に型付けする。
- alg: REQUIRED。IANA の「JSON Web Signature and Encryption Algorithms」レジストリにあるものなどのデジタル署名アルゴリズム識別子である。"none" であってはならない（MUST NOT）。

JWT ペイロードでは:
- iat: REQUIRED。[RFC7519] で定義された構文を用いて、Key Binding JWT が発行された時刻でなければならない（MUST）。
- aud: REQUIRED。値は Key Binding JWT の意図された受領者を識別する単一の文字列でなければならない（MUST）。値の表現方法は使用されるプロトコルに委ねられ、本仕様のスコープ外である。
- nonce: REQUIRED。署名の新鮮性、または与えられた取引への結び付けの新鮮性を確保する。この claim の値型は文字列でなければならない（MUST）。この値の取得方法は使用されるプロトコルに委ねられ、本仕様のスコープ外である。
- sd_hash: REQUIRED。以下で定義する、Issuer が署名した JWT と選択された Disclosures に対する base64url エンコードされた hash 値。

JWT の一般的な拡張性モデルにより、Key Binding JWT に追加の claim や header パラメータを加えることができる。しかし、説得力のある理由がない限り、これは避けるべきである（SHOULD）。相互運用性を損ない、概念的整合性に負担を与え得るためである。

4.3.1. Binding to an SD-JWT

sd_hash claim の hash 値は KB-JWT を特定の SD-JWT に結び付ける。sd_hash 値は、エンコードされた SD-JWT の US-ASCII バイト列に対して計算されなければならない（MUST）。すなわち、Issuer が署名した JWT、チルダ文字、そして Verifier への提示のために選択された 0 個以上の Disclosures（それぞれの後にチルダ文字）である:

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

その後、digest のバイト列は base64url エンコードされなければならない（MUST）。

Disclosures と同じ hash アルゴリズムが使用されなければならない（MUST）（Issuer が署名した JWT 内の _sd_alg 要素、または Section 4.1.1 で定義する既定値により定義される）。

4.3.2. Validating the Key Binding JWT

Key Binding を要求するかどうかは、Verifier が属する信頼要件（信頼フレームワークなど）の集合に基づく Verifier のポリシーに委ねられる。セキュリティ上の考慮事項は Section 9.5 を参照のこと。

Verifier が Key Binding を要求する場合、Verifier は、Key Binding JWT 上の署名検証に用いる鍵が、SD-JWT に Holder の公開鍵として指定された鍵であることを確実にしなければならない（MUST）。例えば、SD-JWT が jwk メンバーを持つ cnf 値を含む場合、Verifier は提供された JWK を解析し、それを用いて Key Binding JWT を検証する。

検証処理の詳細は Section 7.3 で定義される。

5. Example SD-JWT

この例では、単純な SD-JWT を示す。この例は、発行と提示に分かれている。

注: 本文書の例全体を通して、RFC における行長制限に合わせ、かつ可読性のために、JSON 文字列および base64 エンコード文字列に改行を追加している。JSON では文字列内に改行を含めることは許されない。

5.1. Issuance

次のユーザーに関するデータが、Issuer により使用される入力 JWT Claims Set を構成する:

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

この例では、SD-JWT を構築するにあたり、Issuer は次の決定を行った:

nationalities 配列は常に可視とするが、その内容は選択的に開示可能とする。
sub 要素、および本質的な検証データ（iss、exp、cnf など）は常に可視とする。
その他のすべての claim は選択的に開示可能とする。
address については、Issuer はフラットな構造を使用している。すなわち、address claim 内のすべての claim は、全体をまとめてのみ開示できる。他の選択肢は Section 6 で議論する。

SD-JWT には次のペイロードが使用される:

{
  "_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"
    }
  }
}

Issuer により作成された対応する Disclosures を以下に列挙する。以下の本文および本仕様の他の箇所では、ラベル「SHA-256 Hash:」は、ラベル「Base64url-Encoded SHA-256 Hash:」の略記として用いる。

Claim given_name

SHA-256 Hash:
- jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4
Disclosure: text WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9obiJ d
Contents: json ["2GLC42sKQveCfGfryNRN9w", "given_name", "John"]

Claim family_name

SHA-256 Hash:
- TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo
Disclosure: text WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIkRvZSJ d
Contents: json ["eluV5Og3gSNII8EYnsxA_A", "family_name", "Doe"]

Claim email

SHA-256 Hash:
- JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYlSE
Disclosure: text WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImVtYWlsIiwgImpvaG5kb2VAZXhh bXBsZS5jb20iXQ
Contents: json ["6Ij7tM-a5iVPGboS5tmvVA", "email", "johndoe@example.com"]

Claim phone_number

SHA-256 Hash:
- PorFbpKuVu6xymJagvkFsFXAbRoc2JGlAUA2BA4o7cI
Disclosure: text WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInBob25lX251bWJlciIsICIrMS0 yMDItNTU1LTAxMDEiXQ
Contents: json ["eI8ZWm9QnKPpNPeNenHdhQ", "phone_number", "+1-202-555-0101"]

Claim phone_number_verified

SHA-256 Hash:
- XQ_3kPKt1XyX7KANkqVR6yZ2Va5NrPIvPYbyMvRKBMM
Disclosure: text WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJlcl92ZXJpZmll ZCIsIHRydWVd
Contents: json ["Qg_O64zqAxe412a108iroA", "phone_number_verified", true]

Claim address

SHA-256 Hash:
- XzFrzwscM6Gn6CJDc6vVK8BkMnfG8vOSKfpPIZdAfdE
Disclosure: text WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImFkZHJlc3MiLCB7InN0cmVldF9 hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRvd24iLC AicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0
Contents: json [ "AJx-095VPrpTtN4QMOqROA", "address", { "street_address": "123 Main St", "locality": "Anytown", "region": "Anystate", "country": "US" } ]

Claim birthdate

SHA-256 Hash:
- gbOsI4Edq2x2Kw-w5wPEzakob9hV1cRD0ATN3oQL9JM
Disclosure: text WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImJpcnRoZGF0ZSIsICIxOTQwLTA xLTAxIl0
Contents: json ["Pc33JM2LchcU_lHggv_ufQ", "birthdate", "1940-01-01"]

Claim updated_at

SHA-256 Hash:
- CrQe7S5kqBAHt-nMYXgc6bdt2SH5aTY1sU_M-PgkjPI
Disclosure: text WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInVwZGF0ZWRfYXQiLCAxNTcwMDA wMDAwXQ
Contents: json ["G02NSrQfjFXQ7Io09syajA", "updated_at", 1570000000]

Array Entry (nationalities)

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

Array Entry (nationalities)

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

その後、ペイロードは Issuer により署名され、次の Issuer-signed JWT が作成される:

eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb
IkNyUWU3UzVrcUJBSHQtbk1ZWGdjNmJkdDJTSDVhVFkxc1VfTS1QZ2tqUEkiLCAiSnpZ
akg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQWWxTRSIsICJQb3JGYnBL
dVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1
SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAiWFFfM2tQS3QxWHlYN0tB
TmtxVlI2eVoyVmE1TnJQSXZQWWJ5TXZSS0JNTSIsICJYekZyendzY002R242Q0pEYzZ2
Vks4QmtNbmZHOHZPU0tmcFBJWmRBZmRFIiwgImdiT3NJNEVkcTJ4Mkt3LXc1d1BFemFr
b2I5aFYxY1JEMEFUTjNvUUw5Sk0iLCAianN1OXlWdWx3UVFsaEZsTV8zSmx6TWFTRnpn
bGhRRzBEcGZheVF3TFVLNCJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu
Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAic3ViIjog
InVzZXJfNDIiLCAibmF0aW9uYWxpdGllcyI6IFt7Ii4uLiI6ICJwRm5kamtaX1ZDem15
VGE2VWpsWm8zZGgta284YUlLUWM5RGxHemhhVllvIn0sIHsiLi4uIjogIjdDZjZKa1B1
ZHJ5M2xjYndIZ2VaOGtoQXYxVTFPU2xlclAwVmtCSnJXWjAifV0sICJfc2RfYWxnIjog
InNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0y
NTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VH
ZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlG
MkhaUSJ9fX0.MczwjBFGtzf-6WMT-hIvYbkb11NrV1WMO-jTijpMPNbswNzZ87wY2uHz
-CXo6R04b7jYrpj9mNRAvVssXou1iw

Disclosures を追加すると、SD-JWT は次のようになる:

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~

5.2. Presentation

次の非規範的な例は、Holder から Verifier に送られる形の SD-JWT+KB を示す。これはチルダで区切られた 6 つのパートから構成されることに注意する。先頭は上で示した Issuer-signed JWT、中央に 4 つの Disclosures（claim given_name、family_name、address、および nationalities のうち 1 つに対応）、そして最後の要素が Key Binding JWT である。

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

この提示のために Holder が作成して署名した、次の Key Binding JWT ペイロードが使用された:

{
  "nonce": "1234567890",
  "aud": "https://verifier.example.org",
  "iat": 1748537244,
  "sd_hash": "0_Af-2B-EhLWX5ydh_w2xzwmO6iM66B_2QCEanI4fUY"
}

Verifier が Key Binding を要求しないのであれば、Holder は SD-JWT+KB にカプセル化する代わりに、選択した Disclosures を含む SD-JWT をそのまま提示できた。

検証後、Verifier は後続処理のために、次の Processed SD-JWT Payload を利用できる:

{
  "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"
}

6. Considerations on Nested Data in SD-JWTs

JSON である以上、SD-JWT ペイロード内のオブジェクトは、値が別のオブジェクトである name/value ペアを含み得る（MAY）。また、オブジェクトが配列の要素になり得る。SD-JWT では、Issuer が JSON の各レベルにおいて、各 claim を個別に、選択的に開示可能とするかどうかを決定する。この選択は、階層の上位にあるキーが選択的に開示可能かどうかとは独立に、各レベルで行える。

これにより、digest を含む _sd キーは SD-JWT 内に複数回現れ得る（MAY）。同様に、階層内に複数の配列があり、それぞれが選択的に開示可能な要素を持ち得る（MAY）。選択的に開示可能な claim の digest が、他の Disclosures の中に現れ得る（MAY）ことさえある。

次の例は、Issuer が持つ選択肢のいくつかを示す。どの構造を用いるかは Issuer が決める。例えば、SD-JWT の想定ユースケース、プライバシー要件、サイズに関する考慮事項、あるいは動作環境の要件などに依存する。ネストした構造の例をさらに見たい場合は Appendix A.1 および Appendix A.2 を参照のこと。

本セクション全体での例として、次の入力 JWT Claims Set を用いる:

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

注: 以下の構造例は非規範的であり、可能な選択肢のすべてを表す意図はない。また、SD-JWT において address claim をどのように表現できるかを定義したり制限したりする意図もない。

6.1. Example: Flat SD-JWT

Issuer は、address claim を、全体を完全に開示するか、まったく開示しないかのどちらかとして扱うブロックとして扱うことを選べる。次の例は、この場合、address claim 全体が Disclosure 内のオブジェクトとして扱われることを示す。

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

Issuer は SD-JWT 内の 1 つの hash によって参照される、次の Disclosure を作成する:

Claim address

SHA-256 Hash:
- fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do
Disclosure: text WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImFkZHJlc3MiLCB7InN0cmVldF9 hZGRyZXNzIjogIlNjaHVsc3RyLiAxMiIsICJsb2NhbGl0eSI6ICJTY2h1bHBmb3 J0YSIsICJyZWdpb24iOiAiU2FjaHNlbi1BbmhhbHQiLCAiY291bnRyeSI6ICJER SJ9XQ
Contents: json [ "2GLC42sKQveCfGfryNRN9w", "address", { "street_address": "Schulstr. 12", "locality": "Schulpforta", "region": "Sachsen-Anhalt", "country": "DE" } ]

6.2. Example: Structured SD-JWT

Issuer は代わりに、address claim の内容を個別に選択的に開示可能にすることもできる:

{
  "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"
}

この場合、Issuer は address のサブ claim の Disclosures に次のデータを用いる:

Claim street_address

SHA-256 Hash:
- 9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM
Disclosure: text WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN0cmVldF9hZGRyZXNzIiwgIlN jaHVsc3RyLiAxMiJd
Contents: json ["2GLC42sKQveCfGfryNRN9w", "street_address", "Schulstr. 12"]

Claim locality

SHA-256 Hash:
- 6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0
Disclosure: text WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImxvY2FsaXR5IiwgIlNjaHVscGZv cnRhIl0
Contents: json ["eluV5Og3gSNII8EYnsxA_A", "locality", "Schulpforta"]

Claim region

SHA-256 Hash:
- KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88
Disclosure: text WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInJlZ2lvbiIsICJTYWNoc2VuLUFu aGFsdCJd
Contents: json ["6Ij7tM-a5iVPGboS5tmvVA", "region", "Sachsen-Anhalt"]

Claim country

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

Issuer はまた、address の 1 つのサブ claim を恒久的に開示し、他のサブ claim のみを隠すこともできる:

{
  "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"
}

この場合、country は平文で提供されるため、country に対する Disclosure は存在しない。

6.3. Example: SD-JWT with Recursive Disclosures

Issuer はまた、address claim の内容を再帰的に選択的開示可能にすることも選べる。すなわち、address claim 自体も選択的開示可能にし、同時にそのサブ claim も選択的に開示可能にする:

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

Issuer はまずサブ claim の Disclosures を作成し、その digest を address claim の Disclosure に含める:

Claim street_address

SHA-256 Hash:
- 9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM
Disclosure: text WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN0cmVldF9hZGRyZXNzIiwgIlN jaHVsc3RyLiAxMiJd
Contents: json ["2GLC42sKQveCfGfryNRN9w", "street_address", "Schulstr. 12"]

Claim locality

SHA-256 Hash:
- 6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0
Disclosure: text WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImxvY2FsaXR5IiwgIlNjaHVscGZv cnRhIl0
Contents: json ["eluV5Og3gSNII8EYnsxA_A", "locality", "Schulpforta"]

Claim region

SHA-256 Hash:
- KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88
Disclosure: text WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInJlZ2lvbiIsICJTYWNoc2VuLUFu aGFsdCJd
Contents: json ["6Ij7tM-a5iVPGboS5tmvVA", "region", "Sachsen-Anhalt"]

Claim country

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

Claim address

SHA-256 Hash:
- HvrKX6fPV0v9K_yCVFBiLFHsMaxcD_114Em6VT8x1lg
Disclosure: text WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImFkZHJlc3MiLCB7Il9zZCI6IFs iNnZoOWJxLXpTNEdLTV83R3BnZ1ZiWXp6dTZvT0dYcm1OVkdQSFA3NVVkMCIsIC I5Z2pWdVh0ZEZST0NnUnJ0TmNHVVhtRjY1cmRlemlfNkVyX2o3NmttWXlNIiwgI ktVUkRQaDRaQzE5LTN0aXotRGYzOVY4ZWlkeTFvVjNhM0gxRGEyTjBnODgiLCAi V045cjlkQ0JKOEhUQ3NTMmpLQVN4VGpFeVc1bTV4NjVfWl8ycm8yamZYTSJdfV0
Contents: json [ "Qg_O64zqAxe412a108iroA", "address", { "_sd": [ "6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0", "9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM", "KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88", "WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM" ] } ]

7. Verification and Processing

7.1. Verification of the SD-JWT

SD-JWT（直接、または SD-JWT+KB の構成要素として）を受け取った際、Holder または Verifier は次を確実にする必要がある:

Issuer-signed JWT が有効であること、そして
すべての Disclosures が有効であり、Issuer-signed JWT 内の対応する digest 値（ペイロードに直接埋め込まれているもの、または他の Disclosures の内容に再帰的に含まれているもの）に対応していること。

SD-JWT を受け取った Holder または Verifier は、SD-JWT を検証しペイロードを抽出するため、次の確認を実施しなければならない（MUST）:

SD-JWT を Issuer-signed JWT と Disclosures（存在する場合）に分離する。
Issuer-signed JWT を検証する:
1. 使用された署名アルゴリズムがアプリケーションにとって安全と見なされていることを確実にする。詳細は [RFC8725] の Section 3.1 および 3.2 を参照のこと。"none" アルゴリズムは受け入れてはならない（MUST NOT）。
2. [RFC7515] の Section 5.2 に従い、Issuer-signed JWT に対する署名を検証する。
3. Issuer を検証し、署名鍵が当該 Issuer に属することを検証する。
4. _sd_alg claim の値が理解可能であり、hash アルゴリズムが Holder または Verifier のポリシーに従って安全と見なされていることを確認する（Section 4.1.1 を参照）。
Disclosures と Issuer-signed JWT 内に埋め込まれた digest を次のとおり処理する:
1. 提供された各 Disclosure について: 1. Section 4.2.3 に記述するとおり、base64url エンコード文字列に対する digest を計算する。
2. (*) Issuer-signed JWT 内に埋め込まれたすべての digest を次のとおり特定する: 1. 文字列の配列を参照する _sd キーを持つすべてのオブジェクトを見つける。 2. 1 つのキーを持つオブジェクトであり、そのキーが ... で、かつ文字列を参照するものになっている配列要素をすべて見つける。
3. () 前の手順で見つけた各埋め込み digest について: 1. 値を、先に計算した digest と比較して一致する Disclosure を見つける。そのような Disclosure が見つからない場合、その digest は無視しなければならない（MUST）。 2. digest がオブジェクトの _sd キー内で見つかった場合: 1. 対応する Disclosure の内容が 3 要素の JSON 配列（salt、claim 名、claim 値）でない場合、SD-JWT は拒否しなければならない（MUST）。 2. claim 名が _sd または ... である場合、SD-JWT は拒否しなければならない（MUST）。 3. claim 名が _sd キーと同じレベルに既に存在する場合、SD-JWT は拒否しなければならない（MUST）。 4. _sd キーのレベルにおいて、Disclosure の claim 名と claim 値を用いて新しい claim を挿入する。 5. (*) および () に記述した手順を用いて値を再帰的に処理する。 3. digest が配列要素内で見つかった場合: 1. 対応する Disclosure の内容が 2 要素の JSON 配列（salt、値）でない場合、SD-JWT は拒否しなければならない（MUST）。 2. 配列要素を Disclosure の値で置き換える。 3. () および (*) に記述した手順を用いて値を再帰的に処理する。
4. 前の手順で digest が見つからなかった配列要素をすべて削除する。
5. Issuer-signed JWT ペイロードから、すべての _sd キーとその内容を削除する。これによりプロパティを持たないオブジェクトになった場合、空オブジェクト {} として表現すべきである。
6. SD-JWT ペイロードから claim _sd_alg を削除する。
Issuer-signed JWT ペイロード（直接、または他の Disclosures を介して再帰的に）で、いずれかの digest 値が複数回現れた場合、SD-JWT は拒否しなければならない（MUST）。
いずれかの Disclosure が、Issuer-signed JWT における digest 値（直接、または他の Disclosures を介して再帰的に）から参照されていない場合、SD-JWT は拒否しなければならない（MUST）。
処理済みペイロードに nbf、exp、aud などの claim が存在する場合、それらを用いて SD-JWT が有効であることを確認する。必須の有効性制御 claim が欠落している場合（Section 9.7 を参照）、SD-JWT は拒否しなければならない（MUST）。

いずれかの手順が失敗した場合、SD-JWT は有効ではなく、処理は中止しなければならない（MUST）。そうでなければ、上述の処理および検証手順の結果として得られる JSON 文書（以降「Processed SD-JWT Payload」と呼ぶ）を、意図した目的のために利用するアプリケーションへ提供できる。

これらの処理手順は、Holder が完全な Disclosures の集合を受け取ったことを保証しない点に注意する。すなわち、Issuer-signed JWT 内のいくつかの digest 値（decoy digest ではないもの）について、対応する Disclosures が存在しない場合があり得る。例えば、Issuer からのメッセージが途中で切り詰められていた場合などである。必要に応じてユーザーに表示できるよう、Disclosures と平文の claim 値との対応付けをどのように維持するかは Holder に委ねられる。

7.2. Processing by the Holder

Issuer は Holder に SD-JWT を提供し、SD-JWT+KB は提供しない。Holder が SD-JWT+KB を受け取った場合、それは拒否しなければならない（MUST）。

SD-JWT を受け取る際、Holder は次を行わなければならない（MUST）:

Section 7.1 で定義するとおり SD-JWT を処理して検証し、ペイロードを抽出する。
ペイロード内の claim 内容が受け入れ可能であることを確実にする（アプリケーションに依存する。例えば、Holder が確認できる値について正しいことを確認する）。

Verifier への提示のために、Holder は次の（または同等の）手順を実施しなければならない（MUST）（SD-JWT 受領後に Section 7.1 で述べた確認に加えて）:

Verifier に開示する Disclosures を決定し、必要なら同意を取得する（同意をどのように、また取得するかどうかは本書のスコープ外である）。
選択した各 Disclosure が、次の 2 条件のいずれかを満たすことを検証する:
1. Disclosure の hash が Issuer-signed JWT の claim に含まれている。
2. Disclosure の hash が、別の選択された Disclosure の claim 値に含まれている。
Issuer-signed JWT と選択した Disclosures を含めて SD-JWT を組み立てる（形式は Section 4 を参照）。
Key Binding が不要な場合:
1. SD-JWT を Verifier に送る。
Key Binding が必要な場合:
1. SD-JWT に結び付けられた Key Binding JWT を作成する。
2. SD-JWT と Key Binding JWT を連結して SD-JWT+KB を組み立てる。
3. SD-JWT+KB を Verifier に送る。

7.3. Verification by the Verifier

Holder からの提示（SD-JWT または SD-JWT+KB）を受け取った際、Verifier は Section 7.1 に記述する確認に加えて、次を確実にする必要がある:

Key Binding が必要な場合、Holder が SD-JWT+KB を提供していること、そして
Key Binding JWT が Holder により署名されており有効であること。

このため、Verifier は次の手順（または同等の手順）に従わなければならない（MUST）:

当該ユースケースに対する Verifier のポリシーに従い、Key Binding を確認するかどうかを決定する。この決定は、Holder が Key Binding JWT を提供しているかどうかに基づいてはならない（MUST NOT）。詳細は Section 9.5 を参照のこと。
Key Binding が必要で、Holder が（Key Binding なしの）SD-JWT を提供した場合、Verifier は提示を拒否しなければならない（MUST）。
Holder が SD-JWT+KB を提供した場合、それを SD-JWT と Key Binding JWT に解析する。
Section 7.1 で定義するとおり SD-JWT を処理して提示を検証し、ペイロードを抽出する。
Key Binding が必要な場合:
1. SD-JWT から Holder の公開鍵を特定する（Section 4.1.2 を参照）。
2. 使用された署名アルゴリズムがアプリケーションにとって安全と見なされていることを確実にする。詳細は [RFC8725] の Section 3.1 および 3.2 を参照のこと。"none" アルゴリズムは受け入れてはならない（MUST NOT）。
3. [RFC7515] の Section 5.2 に従い、Key Binding JWT に対する署名を検証する。
4. Key Binding JWT の typ が kb+jwt であることを確認する（Section 4.3 を参照）。
5. iat claim により決定される Key Binding JWT の作成時刻が、許容される範囲内であることを確認する。
6. nonce および aud claim を検証することで、Key Binding JWT が現在の取引に結び付けられ、この Verifier のために作成されたこと（リプレイ検出）を確認する。
7. Section 4.3.1 で定義するとおり Issuer-signed JWT と Disclosures に対する digest を計算し、それが Key Binding JWT の sd_hash claim の値と一致することを検証する。
8. [RFC7519] および [RFC8725] に従い、その他すべての点で Key Binding JWT が有効な JWT であることを確認する。

いずれかの手順が失敗した場合、提示は有効ではなく、処理は中止しなければならない（MUST）。

そうでなければ、Processed SD-JWT Payload をアプリケーションへ渡し、意図した目的のために使用できる。

8. JWS JSON Serialization

本セクションは、[RFC7515] の JWS JSON Serialization を用いた SD-JWT および SD-JWT+KB の代替形式を説明する。この形式のサポートは OPTIONAL である。

8.1. New Unprotected Header Parameters

General および Flattened のいずれの JSON Serialization でも、SD-JWT または SD-JWT+KB は [RFC7515] の Section 7.2 に従う JSON オブジェクトとして表現される。次の新しい unprotected header パラメータを定義する:

disclosures: 各要素が Section 4.2 に記述する個別の Disclosure である文字列の配列。
kb_jwt: SD-JWT+KB の場合にのみ存在し、Section 4.3 に記述する Key Binding JWT。

SD-JWT+KB で JWS JSON Serialization を使用する場合、kb_jwt は存在しなければならず（MUST）、sd_hash claim の digest は Section 4.3.1 に記述するとおり SD-JWT に対して計算されなければならない（MUST）。これは、JWS JSON Serialization を使用している場合であっても、digest を計算するために通常の SD-JWT Compact Serialization としての表現を一時的に作成しなければならない（MUST）ことを意味する。詳細には、SD-JWT Compact Serialization 部分は、JWS JSON serialized SD-JWT の protected header、payload、signature を . 文字で区切って連結することで構築し、unprotected header の disclosures メンバーから Disclosures を用いる。

disclosures 以外の unprotected header は digest の対象外であり、したがって通常どおり、改ざんから保護されない。

8.2. Flattened JSON Serialization

Flattened JSON Serialization の場合、unprotected header は 1 つだけである。

次は、Flattened JSON Serialization を用いて発行された、JWS JSON serialized SD-JWT の非規範的な例である:

{
  "header": {
    "disclosures": [
      "WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN1YiIsICJqb2huX2RvZV80M\n  iJd",
      "WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiSm9ob\n  iJd",
      "WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIkRvZ\n  SJd",
      "WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImJpcnRoZGF0ZSIsICIxOTQwL\n  TAxLTAxIl0"
    ]
  },
  "payload": "eyJfc2QiOiBbIjRIQm42YUlZM1d0dUdHV1R4LXFVajZjZGs2V0JwWn\n  lnbHRkRmF2UGE3TFkiLCAiOHNtMVFDZjAyMXBObkhBQ0k1c1A0bTRLWmd5Tk9PQV\n  ljVGo5SE5hQzF3WSIsICJjZ0ZkaHFQbzgzeFlObEpmYWNhQ2FhN3VQOVJDUjUwVk\n  U1UjRMQVE5aXFVIiwgImpNQ1hWei0tOWI4eDM3WWNvRGZYUWluencxd1pjY2NmRl\n  JCQ0ZHcWRHMm8iXSwgImlzcyI6ICJodHRwczovL2lzc3Vlci5leGFtcGxlLmNvbS\n  IsICJpYXQiOiAxNjgzMDAwMDAwLCAiZXhwIjogMTg4MzAwMDAwMCwgIl9zZF9hbG\n  ciOiAic2hhLTI1NiIsICJjbmYiOiB7Imp3ayI6IHsia3R5IjogIkVDIiwgImNydi\n  I6ICJQLTI1NiIsICJ4IjogIlRDQUVSMTladnUzT0hGNGo0VzR2ZlNWb0hJUDFJTG\n  lsRGxzN3ZDZUdlbWMiLCAieSI6ICJaeGppV1diWk1RR0hWV0tWUTRoYlNJaXJzVm\n  Z1ZWNDRTZ0NGpUOUYySFpRIn19fQ",
  "protected": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0",
  "signature": "3oOtvPxU3QdDWUmfGexVB5rWyON2f1atg5rL825bvvD1g7ywjKDK\n  y2UHqHoH2QS4FA99JbG5qnlqFaGXFChfjQ"
}

次は 2 つの Disclosures を含む SD-JWT+KB である:

{
  "header": {
    "disclosures": [
      "WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIkRvZ\n  SJd",
      "WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiSm9ob\n  iJd"
    ],
    "kb_jwt": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dCJ9.eyJub25j\n  ZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaWVyLmV4YW\n  1wbGUub3JnIiwgImlhdCI6IDE3NDg1MzcyNDQsICJzZF9oYXNoIjogIlZqdFBz\n  Z1pwUVRSeEtKdkRwU0otblhsWktFOVo5TGdENEZ5Q3d3b05NUncifQ.GrDvJ2j\n  hYNmUvqdwVEIrxeTFEuI5qKSM7I6P95JmA6Wko-FBB5vPGQn0wvmdgjLCE2iDR\n  h1r82zchjmABQ3V8w"
  },
  "payload": "eyJfc2QiOiBbIjRIQm42YUlZM1d0dUdHV1R4LXFVajZjZGs2V0JwWn\n  lnbHRkRmF2UGE3TFkiLCAiOHNtMVFDZjAyMXBObkhBQ0k1c1A0bTRLWmd5Tk9PQV\n  ljVGo5SE5hQzF3WSIsICJjZ0ZkaHFQbzgzeFlObEpmYWNhQ2FhN3VQOVJDUjUwVk\n  U1UjRMQVE5aXFVIiwgImpNQ1hWei0tOWI4eDM3WWNvRGZYUWluencxd1pjY2NmRl\n  JCQ0ZHcWRHMm8iXSwgImlzcyI6ICJodHRwczovL2lzc3Vlci5leGFtcGxlLmNvbS\n  IsICJpYXQiOiAxNjgzMDAwMDAwLCAiZXhwIjogMTg4MzAwMDAwMCwgIl9zZF9hbG\n  ciOiAic2hhLTI1NiIsICJjbmYiOiB7Imp3ayI6IHsia3R5IjogIkVDIiwgImNydi\n  I6ICJQLTI1NiIsICJ4IjogIlRDQUVSMTladnUzT0hGNGo0VzR2ZlNWb0hJUDFJTG\n  lsRGxzN3ZDZUdlbWMiLCAieSI6ICJaeGppV1diWk1RR0hWV0tWUTRoYlNJaXJzVm\n  Z1ZWNDRTZ0NGpUOUYySFpRIn19fQ",
  "protected": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0",
  "signature": "3oOtvPxU3QdDWUmfGexVB5rWyON2f1atg5rL825bvvD1g7ywjKDK\n  y2UHqHoH2QS4FA99JbG5qnlqFaGXFChfjQ"
}

8.3. General JSON Serialization

General JSON Serialization の場合、unprotected header が複数存在する（署名ごとに 1 つ）。disclosures および kb_jwt が存在する場合、それらは 1 つ目の unprotected header に含めなければならず（MUST）、後続の unprotected header に存在してはならない（MUST NOT）。

次は、General JSON Serialization を用いて Key Binding JWT を含む、JWS JSON serialized SD-JWT の提示の非規範的な例である:

{
  "payload": "eyJfc2QiOiBbIjRIQm42YUlZM1d0dUdHV1R4LXFVajZjZGs2V0JwWn\n  lnbHRkRmF2UGE3TFkiLCAiOHNtMVFDZjAyMXBObkhBQ0k1c1A0bTRLWmd5Tk9PQV\n  ljVGo5SE5hQzF3WSIsICJjZ0ZkaHFQbzgzeFlObEpmYWNhQ2FhN3VQOVJDUjUwVk\n  U1UjRMQVE5aXFVIiwgImpNQ1hWei0tOWI4eDM3WWNvRGZYUWluencxd1pjY2NmRl\n  JCQ0ZHcWRHMm8iXSwgImlzcyI6ICJodHRwczovL2lzc3Vlci5leGFtcGxlLmNvbS\n  IsICJpYXQiOiAxNjgzMDAwMDAwLCAiZXhwIjogMTg4MzAwMDAwMCwgIl9zZF9hbG\n  ciOiAic2hhLTI1NiIsICJjbmYiOiB7Imp3ayI6IHsia3R5IjogIkVDIiwgImNydi\n  I6ICJQLTI1NiIsICJ4IjogIlRDQUVSMTladnUzT0hGNGo0VzR2ZlNWb0hJUDFJTG\n  lsRGxzN3ZDZUdlbWMiLCAieSI6ICJaeGppV1diWk1RR0hWV0tWUTRoYlNJaXJzVm\n  Z1ZWNDRTZ0NGpUOUYySFpRIn19fQ",
  "signatures": [
    {
      "header": {
        "disclosures": [
          "WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgI\n  kRvZSJd",
          "WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiS\n  m9obiJd"
        ],
        "kid": "issuer-key-1",
        "kb_jwt": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dCJ9.eyJu\n  b25jZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaW\n  VyLmV4YW1wbGUub3JnIiwgImlhdCI6IDE3NDg1MzcyNDQsICJzZF9oYXNo\n  IjogInFieUlXUDNwaFZneEVzRFJpd2R3OVc2QkozZHhpUEx1bWNZcFBidT\n  RFYjgifQ.VyZqxaVHh1XE6M-kuax_7Laq42uFDrx17lLG2jluyKgy_PqC8\n  5z4DVpISdMZDdSANGs-0zN2N7xnM-E1Pg0sOw"
      },
      "protected": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0",
      "signature": "dz1N3uvhVHJjldyXwppmBLieTj0vuBMbzL06rnrLIuxEQb9B\n  HoIOwGrWh-UadW4orRpEiEtjf7xyHDONMJ6tBw"
    },
    {
      "header": {
        "kid": "issuer-key-2"
      },
      "protected": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0",
      "signature": "kuXio_U88RH_-fihAPET4AFUjj0BpxsT6yddMFIr6pfHKtAe\n  0FOJNWQxU42rfnORuNQNTgGsf2A8LjEba5inNg"
    }
  ]
}

8.4. Verification of the JWS JSON Serialized SD-JWT

JWS JSON serialized SD-JWT の検証は Section 3.4 で定義された規則に従う。ただし、次の点が異なる:

SD-JWT または SD-JWT+KB を構成要素に分割する必要はなく、Disclosures は unprotected header の disclosures メンバーにある。
SD-JWT+KB の Key Binding JWT における sd_hash の digest を検証するため、Verifier は Section 8.1 に記述するとおり、hash 化する文字列を組み立てなければならない（MUST）。

9. Security Considerations

セキュリティ上の考慮事項は、次の性質の達成に役立つ。

Selective Disclosure:\ Verifier の役割にある攻撃者は、Holder によって明示的に開示されていない claim name または claim value について、提示された SD-JWT 以外の他の開示済み claim や情報源から導出できない限り、SD-JWT から情報を得ることはできない。

Integrity:\ 悪意のある Holder は、選択的に開示可能な claim の name や value を、Verifier に検知されることなく改変できない。

さらに、Section 9.5 で述べるとおり、Key Binding を適用することで、SD-JWT クレデンシャルの提示者がそのクレデンシャルの Holder であることを保証できる。

9.1. Mandatory Signing of the Issuer-Signed JWT

JWT は、発行された claim の完全性を保護するために Issuer が署名しなければならない (MUST)。この JWT が署名されていない場合、攻撃者は claim を改変または追加できる (例: 被害者のアカウントを乗っ取るために "email" 属性を変更する、偽の学術資格を示す属性を追加する)。

Verifier は、発行後に改ざんされていないことを保証するために、Issuer-signed JWT の署名を常に検証しなければならない (MUST)。署名を検証できない場合、Issuer-signed JWT は拒否されなければならない (MUST)。

Issuer-signed JWT の安全性は署名アルゴリズムの安全性に依存する。[RFC7515] の Section 5.2 最終段落に従い、(利用可能になった場合の耐量子アルゴリズムを含め) [JWS.Algs] から適切な JWS アルゴリズムを選択することは、アプリケーション固有の判断である。

9.2. Manipulation of Disclosures

Holder は、Verifier に送信する前に claim の value を変更することで Disclosures を改ざんできる。Verifier は、claim の value が正しいこと、すなわち Disclosures の digest が署名済み SD-JWT に実際に含まれていることを確認するために、Disclosures を検査しなければならない (MUST)。

(ハッシュを確認せずに) Disclosures からすべての claim value を取り出して SD-JWT payload に挿入する素朴な Verifier は、この攻撃に対して脆弱である。ただし、構造化された SD-JWT では、Disclosures の digest を比較しない限り、ネストしたオブジェクトのどこに claim を挿入すべきかという正しい位置を判断できない。したがって、そのような素朴な実装は安全でないだけでなく、不正確でもある。

Section 7.3 で述べた手順により、Verifier が Disclosures を正しく検査できる。

9.3. Entropy of the Salt

平文の claim を秘匿するセキュリティモデルは、ハッシュ関数への追加入力として salt の高いエントロピーを持つ乱数データに依存する。乱数性により、同一の平文 claim value が同一の digest value を生成しないことが保証される。また、ある claim の取り得る value 空間をハッシュ関数に列挙投入して一致する digest value を探すことで、digest の原像 (preimage) を推測して平文 claim value を学習することは実行不可能になる。したがって、他の salt が開示されていたとしても、未開示の salt が学習されたり推測されたりしないことが極めて重要である。

そのため、各 salt は、暗号学的にランダムで、十分に長く、推測が実行不可能となるだけの十分高いエントロピーを持つように生成されなければならない (MUST)。新しい salt は、他の salt と独立に、各 claim ごとに選択されなければならない (MUST)。乱数値生成に関する考慮事項は "Randomness Requirements for Security" [RFC4086] を参照のこと。

salt のランダム生成部分の推奨最小長は 128 bits である (RECOMMENDED)。

Issuer は、SD-JWT の構造内で同一の claim name が異なる場所に出現する場合も含め、各 claim に対して新しい salt value が選ばれることを保証しなければならない (MUST)。これは Appendix A.2 の例で確認できる。そこでは name が type の claim が複数出現するが、それぞれ異なる salt を持っている。

9.4. Choice of a Hash Algorithm

ある提示において開示されていないが選択的に開示可能な claim のプライバシーを確保するため、ハッシュ関数は、特定の digest から 3 要素 (salt, claim name, claim value) のいかなる部分も計算で得られないことが実行不可能であるよう保証しなければならない (MUST)。これは、ハッシュ関数が原像計算困難性 (preimage resistant) を満たす必要があることを意味し、さらに観測者が未開示内容に関する部分的情報を推測できないことも求められる。暗号学的コミットメント方式の用語では、ハッシュ関数は計算的に秘匿 (computationally hiding) である必要がある。

選択的に開示可能な claim の完全性を確保するため、ハッシュ関数は第二原像計算困難性 (second-preimage resistant) を満たさなければならない (MUST)。すなわち、salt・claim name・claim value の任意の組み合わせに対し、同一の digest を生む別の組み合わせを見つけることが実行不可能でなければならない。

ハッシュ関数は衝突困難性 (collision resistant) も満たすべきである (SHOULD)。SD-JWT の想定用途に必須ではないものの、衝突困難性がない場合、Issuer は同じハッシュ値を持つ複数の Disclosures を見つけられる可能性がある。その場合、SD-JWT に対する署名は JWT の内容へのコミットメントにならない。digest 生成に用いるハッシュ関数の衝突困難性は、署名方式が用いるハッシュ関数の衝突困難性と整合すべきである (SHOULD)。例えば、ES512 署名アルゴリズムを用いる場合、SHA-512 のように少なくとも 256-bit の衝突困難性を持つ Disclosure 用ハッシュ関数が必要になる。

"Named Information Hash Algorithm Registry" [Hash.Algs] への登録だけでは、そのハッシュアルゴリズムが SD-JWT での使用に適していることを示さない (同レジストリには sha-256-32 や sha-256-64 のような大幅に短縮された digest が複数含まれており、これらはセキュリティ用途に不適である)。

9.5. Key Binding

Key Binding は、SD-JWT クレデンシャルの提示者が実際にそのクレデンシャルの Holder であることを保証することを目的とする。Key Binding と互換な SD-JWT には、Holder が保有する private key に対応する public key、もしくは public key への参照が含まれる。Verifier は、SD-JWT クレデンシャル提示時に Holder がその private key の所持を証明することを要求する。

Key Binding がない場合、Verifier が得られるのはそのクレデンシャルが特定の Issuer によって発行されたという証拠だけであり、クレデンシャル自体は入手した誰でもリプレイできる。つまり例えば、クレデンシャルが攻撃者に漏えいした後、攻撃者はバインディングを要求しない任意の Verifier に対してそのクレデンシャルを提示できる。また、Holder が提示した相手である悪意のある Verifier は、別の Verifier が Key Binding を要求しない場合、その別の Verifier に対してクレデンシャルを提示できる。

Verifier は、クレデンシャルを検証する前に、特定のユースケースで Key Binding が必要かどうかを決定しなければならない (MUST)。この判断は、次の要因を含むがこれらに限られない様々な要因から情報を得られる: ビジネス要件、ユースケース、ユースケースに要求される Holder とそのクレデンシャルのバインディングの種類、ユースケースの機微性、想定されるクレデンシャルの性質、同時に提示される他のクレデンシャルの種類と内容、など。

Verifier が攻撃者の影響を受け得るデータに基づいてセキュリティポリシーの判断を行わないことが重要である。このため、Key Binding が必要かどうかを決定する際、Verifier は、Holder が SD-JWT+KB を提供したか、あるいは bare SD-JWT を提供したかを考慮してはならない (MUST NOT)。そうしなければ、攻撃者は SD-JWT+KB から KB-JWT を取り除いて、結果の SD-JWT を提示できてしまう。

さらに、Verifier は、Key Binding 情報が自分たちの認識しない形式で SD-JWT に追加されている可能性があり、その結果、SD-JWT が Key Binding をサポートしているかどうか判別できない場合があることを認識しておくべきである。

Verifier が特定のユースケースで Key Binding が必要だと判断し、Holder が bare SD-JWT を提示した場合、または無効な Key Binding JWT を含む SD-JWT+KB を提示した場合、Verifier は Section 7.3 に記載された検証手順に従って提示を拒否する。

9.6. Concealing Claim Names

SD-JWT は、選択的に開示可能な claim の name が、その claim の value が開示されない限り常に秘匿されることを保証する。これにより攻撃者がそのような claim の name を学習することを防ぐ。しかし、恒久的に開示される claim の name は隠されない。これには、秘匿されないオブジェクト自身の key でありつつ、その内部に秘匿された claim を含むものも含まれる。この制約は、Issuer が SD-JWT の構造を作成する際に考慮する必要がある。

9.7. Selectively Disclosable Validity Claims

Issuer は、SD-JWT の真正性または有効性の評価に重要な内容を選択的に開示可能にしてはならない (MUST NOT)。そのような内容の正確な一覧はアプリケーションに依存し、SD-JWT のアプリケーション固有プロファイルで列挙されるべきである (SHOULD)。以下は、セキュリティ上重要と見なすべき登録済み JWT claim name の一覧である (SHOULD):

iss (Issuer)
aud (Audience)。ただし issuers は、配列内の個々のエントリを選択的に開示可能にしてもよい (MAY)
exp (Expiration Time)
nbf (Not Before)
cnf (Confirmation Key)

Issuer は通常、SD-JWT の有効性を制御する claim を SD-JWT payload に平文で含めるが、必ずそうする保証はない。したがって Verifier は、それに確実に依存できず、セキュリティ上重要な claim が選択的に開示可能であり得るものとして運用する必要がある。

よって Verifier は、与えられた文脈における SD-JWT の有効性チェックに必要だと判断するすべての claim が、SD-JWT の検証中に存在する (またはそれぞれ開示される) ことを保証しなければならない (MUST)。これは Section 7.1 で定義された検証の最終ステップで実装されている。

要求される有効性 claim の正確な集合は、通常は運用環境のルール、アプリケーション固有プロファイル、またはクレデンシャル形式によって定義され、ここに列挙したもの以外の claim を含んでもよい (MAY)。

9.8. Distribution and Rotation of Issuer Signature Verification Key

本仕様は、Issuer の署名検証鍵がどのように Verifier に配布されるかを定義しない。しかし、例えば JSON Web Key Set (JWKS) 形式 [RFC7517] を用いて事前定義された場所に鍵を公開するなど、効率的で安全な鍵のローテーションと失効を可能にする方法で Issuer が鍵を公開することが推奨される (RECOMMENDED)。Verifier は、与えられた鍵配布方式に対して合理的かつ適切な手段により、署名検証に期限切れまたは失効した鍵を使用していないことを確認する必要がある。

9.9. Forwarding Credentials

SD-JWT (SD-JWT+KB から抽出された SD-JWT を含む) を所持する任意の主体は、Key Binding を強制しない任意の第三者にそれを転送できる。その際、その主体は Disclosures を削除して、受け手が元の SD-JWT に含まれる claim の一部だけを知るようにできる。

例えば、デバイス製造者が、上流および下流のサプライチェーン関係者に関する情報を含む SD-JWT を作成するかもしれない。各サプライチェーン主体は、上流主体から自分に対して選択的に開示された claim だけを検証でき、さらに下流主体に提示する際に開示済み claim を追加で減らすことも選択できる。

いくつかのシナリオではこの挙動は望ましい可能性がある。望ましくない場合、Issuer は Key Binding をサポートし、Verifier は Key Binding を強制する必要がある。

9.10. Integrity of SD-JWTs and SD-JWT+KBs

SD-JWT では、Issuer-signed JWT は Issuer の署名により完全性が保護され、Disclosures の value はそれらに含まれる digest により完全性が保護される。しかし、Disclosures の具体的な集合は完全性保護されない。SD-JWT は Disclosures を追加または削除しても有効であり得る。

SD-JWT+KB では、選択された Disclosures の集合が完全性保護される。Key Binding JWT の署名は、特定の SD-JWT、すなわち特定の Issuer-signed JWT と特定の Disclosures 集合を対象にする。したがって、Key Binding JWT の署名は、Key Binding の証明に加えて、Holder が開示した Disclosures 集合の真正性と完全性も保証する。SD-JWT+KB における Disclosures 集合は、Holder が送信する意図を持っていた集合であり、中継者が Disclosures の一覧を追加・削除・改変していない。

9.11. Explicit Typing

[RFC8725] の Section 3.11 は、ある種類の JWT が別の種類の JWT と誤認される混同攻撃 (Section 2.8 of [RFC8725] で記述) を防ぐ仕組みの一つとして、明示的な型付けの利用を説明している。SD-JWT もそのような混同攻撃の対象となり得るため、他の技法がない場合には、SD-JWT のアプリケーションプロファイルが、SD-JWT 発行時に typ ヘッダパラメータを含めて明示的な型を指定し、Verifier がこの値を検査することが推奨される (RECOMMENDED)。

typ ヘッダを用いて SD-JWT の明示的型付けを行う場合、"application/example+sd-jwt" 形式の media type 名を使用することが推奨される (RECOMMENDED)。ここで "example" は、特定の種類の SD-JWT を識別する識別子に置き換えられる。[RFC7515] の Section 4.1.9 における typ の定義は "application/" 接頭辞を省略することを推奨しているため、typ ヘッダパラメータの値は "example+sd-jwt" となる。

SD-JWT payload の content type を示すために cty content type ヘッダパラメータを使用することもでき、これにより異なる種類の JSON オブジェクトや異なる種類の JWT Claim Sets を区別できる。

9.12. Key Pair Generation and Lifecycle Management

SD-JWT の実装は非対称暗号鍵に依存するため、鍵ペアの生成、取り扱い、保管、およびライフサイクル管理が安全に行われることを保証しなければならない (MUST)。

安全な鍵管理の具体的機構は本書のスコープ外であるが、実装者は NIST SP 800-57 Part 1 [NIST.SP.800-57pt1r5] に概説されているような確立されたベストプラクティスに従うべきである (SHOULD)。これには次が含まれる:

Secure Generation: 暗号学的に安全な手法および乱数生成器を用いる。
Secure Storage: private key を不正アクセスから保護する。
Lifecycle Management: 必要に応じて安全な鍵ローテーション、失効、廃棄を確実に行う。

適切な鍵管理は不可欠であり、いずれかが侵害されると SD-JWT の不正開示や偽造につながり得る。

10. Privacy Considerations

10.1. Unlinkability

Unlinkability は、攻撃者がユーザーの同意を超えて同一ユーザーのクレデンシャル提示を相関付けできないようにする性質である。\ Unlinkability がない場合、攻撃者はユーザーが開示する意図を持っていた以上にユーザーについて学習できてしまう可能性がある。例えば:

共謀する Verifiers が、広告プロファイルを構築するためにサービス横断でユーザーを追跡したい場合。
Issuers が、監視を可能にするためにユーザーがどこでクレデンシャルを提示したか追跡したい場合。
複数の Verifiers でデータ侵害が発生した後、公開情報により、
- Verifier A に提示された識別可能情報と、
- 元は匿名だった Verifier B に提示された情報が結び付けられ、
- その結果 Verifier B のユーザーの身元が露見する場合。

以下では次の種類の unlinkability を議論する:

Presentation Unlinkability: Verifier は同一クレデンシャルの 2 つの提示を結び付けられないこと。
Verifier/Verifier Unlinkability: 2 つの異なる Verifiers への提示が、同一クレデンシャルが提示されたことを明らかにしないこと。\ 例:
- 2 つの Verifiers が共謀する場合
- 第三者により提示内容の開示を強制される場合
- 一方の Verifier から他方へデータが漏えいする場合
Issuer/Verifier Unlinkability (Honest Verifier):\ クレデンシャルの Issuer は、Verifier が偶発的・意図的に提示データを Issuer と共有したり、共有を強制されたりしない限り、ユーザーがそのクレデンシャルを提示したことを知り得ないこと。
Issuer/Verifier Unlinkability (Careless/Colluding/Compromised/Coerced Verifier):

クレデンシャルの Issuer は、いかなる状況でも、ユーザーがそのクレデンシャルを特定の Verifier に提示したことを判別できてはならない。\ 特に、Verifier が偶発的または意図的に提示データを Issuer と共有した場合や、共有を強制された場合を含む。

いずれの場合も、unlinkability は、開示された claim がユーザーを直接または間接に特定する情報を含まない場合に限られる。\ 例:

納税者番号が開示された claim に含まれる場合、Issuer と Verifier は容易にユーザーの取引を結び付けられる。
一方で、ユーザーがある Verifier には birthdate だけを開示し、別の Verifier には postal code だけを開示する場合、2 つの Verifiers は同一ユーザーとやり取りしていることを判別できないはずである。

不注意・共謀・侵害・強要された Verifier を想定した Issuer/Verifier unlinkability は、SD-JWT のような salt 付きハッシュに基づく選択的開示方式では達成できない。\ これは、Issuer の署名付きで発行されたクレデンシャルが Verifier に直接提示され、Verifier がそれを Issuer に転送できるためである。\ 後にデータが露見するリスクを低減するため、Section 10.2 では保存されるデータ量を減らすための要件を定義する。

Issuer/Verifier unlinkability を検討するにあたり、Issuer と Verifier の間に非対称な権力関係が存在し得る点に注意することが重要である。\ この力学により、Honest Verifier であっても共謀を強いられることがある。例:

政府の Issuer が、Verifier に対して提示されたクレデンシャルに関する情報を報告するよう命じる権限を持ち得る。
法的要件によりこれがさらに強制され、Issuer/Verifier unlinkability を明示的に損なう可能性がある。
大規模なサービスプロバイダがクレデンシャルを発行する場合、より大きな運用環境への参加をインセンティブ化することで、Verifier に暗黙の圧力をかけて共謀へと誘導し得る。

SD-JWT の導入者は、これらの潜在的な権力力学を認識し、可能な限り緩和し、そして/またはそのリスクをユーザーに透明化しなければならない。

これとは対照的に、Honest Verifier を想定した Issuer/Verifier unlinkability は一般に達成できる。\ ただし、失効確認のような Verifier から Issuer へのコールバックがある場合、クレデンシャルの利用状況に関する情報が Issuer に開示される可能性がある。\ そのようなコールバックが必要な場合、プライバシーを保ち、クレデンシャルの詳細を Issuer に開示しない方法で実行される必要がある（[TSL] に記載された機構は一例）。\ また、そのようなリクエストのタイミングがサイドチャネルになり得る点にも注意が必要である。

Verifier/Verifier unlinkability と presentation unlinkability は、バッチ発行により達成できる。\ すなわち、同一の claim に基づく単一のクレデンシャルだけでなく、そのようなクレデンシャルのバッチが Holder に発行される。\ Holder はその後、Verifier ごと、あるいは Verifier とのセッションごとに別のクレデンシャルを使用できる。

バッチ内の各クレデンシャルには、新しい Key Binding 鍵と新しい salt を使用しなければならない (MUST)。
- これにより Verifiers がこれらの値を用いてクレデンシャル同士を結び付けられないことが保証される。
iat、exp、nbf のような時刻情報を運ぶ claim は、次のいずれかを行わなければならない (MUST):
- ランダム化（例: iat を過去 24 時間の範囲でランダム化し、それに応じて exp を計算する）
- 丸め（例: 日の開始時刻へ切り下げる）

SD-JWT が秘匿するのは、開示されない claim の value のみである。\ それは匿名クレデンシャル [CL01] のセキュリティ特性を満たさない。\ とりわけ、共謀する Verifiers と Issuers は、どのフィールドが開示されたかに関わらず（何も開示されなかった場合であっても）、同一のクレデンシャルを見たかどうかを知り得る。

この挙動は、ユーザーが自然に予期すること、あるいはユーザーインターフェースのやり取りから期待するよう誘導されることと整合しない可能性があり、結果として、ユーザーが本来ならしなかったかもしれない判断をしてしまう可能性がある。

上記のバッチ発行のような回避策は、Verifiers が異なる提示を結び付けることを防ぐのに役立つが、Issuer/Verifier unlinkability には有効ではない。\ この問題は、mDL/mDoc [ISO.18013-5] や SD-CWT [SD-CWT] を含む、salt 付きハッシュに基づくすべての方式に当てはまる。

10.2. Storage of User Data

ユーザーデータが保存される場所はどこであれ、それは攻撃者にとって潜在的な標的になる。\ そのデータが公的な国家 ID サービスのような信頼された権威によって署名されている場合、その標的は特に高い価値を持ち得る。

例: OpenID Connect [OpenID.Core] では、署名された ID Token が Relying Parties に保存され得る。\ SD-JWT の場合、Holders は SD-JWT を保存しなければならず、Issuers と Verifiers も同様に保存すると決める可能性がある。

当然ながら、そのようなデータの漏えいは、ユーザーの私的データが第三者に明らかになるリスクを伴う。\ 署名されたユーザーデータは、その真正性を第三者が容易に検証できるため、リスクをさらに悪化させる。\ また Section 9.5 で議論したとおり、漏えいした SD-JWT は、Key Binding が強制されておらず、かつ攻撃者が Holder の暗号鍵にアクセスできる場合、攻撃者が Holder になりすますことを可能にし得る。

これらのリスク、および Section 10.1 で述べたリスクのため、SD-JWT を実装するシステムは保存するデータ量を最小化するよう設計されるべきである (SHOULD)。\ 関係する当事者は、ログファイルを含め、厳密に必要な期間を超えて SD-JWT を保存しないべきである (SHOULD NOT)。

Issuance 後、Issuers は Issuer-signed JWT または対応する Disclosures を保存しないべきである (SHOULD NOT)。
Holders は SD-JWT を暗号化形式でのみ保存すべきであり (SHOULD)、
- 可能な限り、特に private Key Binding 鍵についてはハードウェアに裏打ちされた暗号化を用いるべきである (SHOULD)。
- 分散型のデータ保存（例: ユーザーデバイス上）は、集中型保存よりもユーザークレデンシャルに対して優先されるべきである (SHOULD)。
- 期限切れの SD-JWT は可能な限り速やかに削除されるべきである (SHOULD)。
Verification 後、Verifiers は Issuer-signed JWT または対応する Disclosures を保存しないべきである (SHOULD NOT)。
- アプリケーションに必要な検証結果およびユーザーデータだけを保存すれば十分な場合がある。

上記のルールからの例外は、強い要件（例: 機能要件または法的監査要件）があり、安全な保存を保証でき、かつプライバシーへの影響が評価されている場合に認められ得る。

10.3. Confidentiality During Transport

Issuance または提示の際に SD-JWT または SD-JWT+KB が安全でないチャネルで送信されると、攻撃者がユーザーの個人データを傍受して読み取ったり、過去の利用と相関付けたりできる可能性がある。

通常、クレデンシャルの issuance および提示のためのトランスポートプロトコルは、例えば TLS の使用を要求することで、送信データの機密性を保護するよう設計されている。

したがって本仕様は、データの機密性はトランスポートプロトコルにより提供されるものとみなし、いかなる暗号化機構も規定しない。

実装者は、ユーザーデータのプライバシーや受動的観測者による相関攻撃が懸念される場合、トランスポートプロトコルが機密性を提供することを保証しなければならない (MUST)。

潜在的に安全でない、または漏えいしやすいチャネル上で転送中の SD-JWT または SD-JWT+KB を暗号化するため、実装者は JSON Web Encryption (JWE) [RFC7516] を用いて、SD-JWT または SD-JWT+KB を JWE の平文 payload としてカプセル化してもよい (MAY)。\ とりわけ、SD-JWT が URL 経由で送信され、情報がブラウザに保存/キャッシュされたり web server のログに残ったりし得る場合、SD-JWT は JWE を用いて暗号化されるべきである (SHOULD)。

10.4. Decoy Digests

claim の数（または特定の claim の存在）が、未開示の claim に関する情報を開示してしまうサイドチャネルになり得る場合、decoy digests の使用が推奨される (RECOMMENDED)。

特に、SD-JWT 内のある claim が特定の条件が満たされたときのみ存在する場合（例: ユーザーがあるグループのメンバーである場合にのみ会員番号が含まれる）、Issuer は条件が満たされないときに decoy digests を追加するべきである (SHOULD)。

decoy digests は SD-JWT のサイズを増加させる。\ decoy digests の数（またはそもそも使用するかどうか）は、SD-JWT のサイズとユーザーデータのプライバシーの間のトレードオフである。

10.5. Issuer Identifier

ある Issuer が 1 種類の SD-JWT しか発行しない場合、プライバシー上の含意が生じ得る。\ というのも、Holder がその Issuer によって発行された SD-JWT を持っている場合、その type と claim name が判別できるためである。

例:

がん研究機関ががん登録情報を含む SD-JWT しか発行しない場合、その SD-JWT を所有する Holder ががん患者であることを推測できてしまう。

さらに、Issuer identifier そのものがユーザーに関する情報を漏らす可能性もある。

例:

軍組織や薬物リハビリセンターがワクチンクレデンシャルを発行する場合、Verifiers は Holder が軍関係者である、あるいは物質使用障害を抱えているかもしれないと推測できてしまう。

この問題を緩和するため、複数の Issuers のグループが共通の Issuer identifier を使用することを選択し得る。\ 本仕様のスコープ外にあるグループ署名方式を、個別署名の代わりに用いることもできる。

11. IANA Considerations

11.1. JSON Web Token Claims Registration

IANA は、[RFC7519] により確立された "JSON Web Token Claims" レジストリ [JWT.Claims] に、以下の Claims を登録している。

Claim Name: _sd
- Claim Description: オブジェクトのプロパティに対する Disclosures の digest
- Change Controller: IETF
- Specification Document(s): RFC 9901 の Section 4.2.4.1

Claim Name: ...
- Claim Description: 配列要素に対する Disclosure の digest
- Change Controller: IETF
- Specification Document(s): RFC 9901 の Section 4.2.4.2

Claim Name: _sd_alg
- Claim Description: Disclosure の digest および提示に対する digest の生成に用いるハッシュアルゴリズム
- Change Controller: IETF
- Specification Document(s): RFC 9901 の Section 4.1.1

Claim Name: sd_hash
- Claim Description: KB-JWT が紐付けられている SD-JWT の digest
- Change Controller: IETF
- Specification Document(s): RFC 9901 の Section 4.3

11.2. Media Type Registrations

IANA は、[RFC6838] に記載された方法により、"Media Types" レジストリ [MediaTypes] に [RFC2046] の以下の media types を登録している。

Note: Issuer-signed JWT 自体の typ ヘッダで使用される media type 値については Section 9.11 を参照のこと。

11.2.1. SD-JWT Content

content が SD-JWT であることを示すため:

タイプ名: application
サブタイプ名: sd-jwt
必須パラメータ: n/a
任意パラメータ: n/a
エンコーディングに関する考慮事項: binary; application/sd-jwt の値は、period (.) および tilde (~) 文字で区切られた base64url-encoded 値の列（空文字列である場合もある）である。
セキュリティに関する考慮事項: RFC 9901、[RFC7519]、および [RFC8725] の Security Considerations セクションを参照のこと。
相互運用性に関する考慮事項: n/a
公開仕様: RFC 9901
この media type を使用するアプリケーション: 完全性保護された content の選択的開示を必要とするアプリケーション。
フラグメント識別子に関する考慮事項: n/a

追加情報:

マジックナンバー: n/a
ファイル拡張子: n/a
Macintosh ファイルタイプコード: n/a

追加情報の問い合わせ先（Person & email address）: Daniel Fett, mail@danielfett.de\ 想定用途: COMMON\ 使用上の制約: none\ 著者: Daniel Fett, mail@danielfett.de\ 変更管理者（Change Controller）: IETF

11.2.2. JWS JSON Serialized SD-JWT Content

content が JWS JSON serialized SD-JWT であることを示すため:

タイプ名: application
サブタイプ名: sd-jwt+json
必須パラメータ: n/a
任意パラメータ: n/a
エンコーディングに関する考慮事項: binary; application/sd-jwt+json の値は、JSON Object として表現される。
セキュリティに関する考慮事項: RFC 9901 および [RFC7515] の Security Considerations セクションを参照のこと。
相互運用性に関する考慮事項: n/a
公開仕様: RFC 9901
この media type を使用するアプリケーション: ETSI JAdES 準拠の署名により保護された content の選択的開示を必要とするアプリケーション。
フラグメント識別子に関する考慮事項: n/a

追加情報:

マジックナンバー: n/a
ファイル拡張子: n/a
Macintosh ファイルタイプコード: n/a

追加情報の問い合わせ先（Person & email address）: Daniel Fett, mail@danielfett.de\ 想定用途: COMMON\ 使用上の制約: none\ 著者: Daniel Fett, mail@danielfett.de\ 変更管理者（Change Controller）: IETF

11.2.3. Key Binding JWT Content

content が Key Binding JWT であることを示すため:

タイプ名: application
サブタイプ名: kb+jwt
必須パラメータ: n/a
任意パラメータ: n/a
エンコーディングに関する考慮事項: binary; Key Binding JWT は JWT である。JWT の値は period (.) 文字で区切られた base64url-encoded 値の列としてエンコードされる。
セキュリティに関する考慮事項: RFC 9901、[RFC7519]、および [RFC8725] の Security Considerations セクションを参照のこと。
相互運用性に関する考慮事項: n/a
公開仕様: RFC 9901
この media type を使用するアプリケーション: JWT ベースの proof-of-possession 機構を利用するアプリケーション。
フラグメント識別子に関する考慮事項: n/a

追加情報:

マジックナンバー: n/a
ファイル拡張子: n/a
Macintosh ファイルタイプコード: n/a

追加情報の問い合わせ先（Person & email address）: Daniel Fett, mail@danielfett.de\ 想定用途: COMMON\ 使用上の制約: none\ 著者: Daniel Fett, mail@danielfett.de\ 変更管理者（Change Controller）: IETF

11.3. Structured Syntax Suffixes Registration

IANA は、[RFC6838] に記載された方法により、"Structured Syntax Suffixes" レジストリ [StructuredSuffix] に +sd-jwt を登録している。\ これは、media type が SD-JWT としてエンコードされることを示すために使用できる。

Name: SD-JWT
+suffix: +sd-jwt
References: RFC 9901
エンコーディングに関する考慮事項: binary; SD-JWT の値は、period (.) 文字または tilde (~) 文字で区切られた base64url-encoded 値の列（空文字列である場合もある）である。
相互運用性に関する考慮事項: n/a
フラグメント識別子に関する考慮事項: n/a
セキュリティに関する考慮事項: RFC 9901、[RFC7519]、および [RFC8725] の Security Considerations セクションを参照のこと。
Contact: Daniel Fett, mail@danielfett.de
Author/Change controller: IETF

12. References

12.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 1997年3月, https://www.rfc-editor.org/info/rfc2119.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, 2008年1月, https://www.rfc-editor.org/info/rfc5234.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, 2013年1月, https://www.rfc-editor.org/info/rfc6838.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, 2015年5月, https://www.rfc-editor.org/info/rfc7515.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, 2015年5月, https://www.rfc-editor.org/info/rfc7516.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, 2015年5月, https://www.rfc-editor.org/info/rfc7519.
[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, 2016年4月, https://www.rfc-editor.org/info/rfc7800.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2017年5月, https://www.rfc-editor.org/info/rfc8174.
[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, 2020年2月, https://www.rfc-editor.org/info/rfc8725.

12.2. Informative References

[CL01] Camenisch, J. and A. Lysyanskaya, "An Efficient System for Non-Transferable Anonymous Credentials with Optional Anonymity Revocation", Cryptology ePrint Archive, Paper 2001/019, 2001年, https://eprint.iacr.org/2001/019.pdf.
[Hash.Algs] IANA, "Named Information Hash Algorithm Registry", https://www.iana.org/assignments/named-information.
[ISO.18013-5] ISO/IEC, "Personal identification - ISO-compliant driving license - Part 5: Mobile driving license (mDL) application", ISO/IEC 18013-5:2021, 2021年9月, https://www.iso.org/standard/69084.html.
[JWS.Algs] IANA, "JSON Web Signature and Encryption Algorithms", https://www.iana.org/assignments/jose.
[JWT.Claims] IANA, "JSON Web Token Claims", https://www.iana.org/assignments/jwt.
[MediaTypes] IANA, "Media Types", https://www.iana.org/assignments/media-types.
[NIST.SP.800-57pt1r5] Barker, E., "Recommendation for Key Management: Part 1 - General", NIST SP 800-57pt1r5, DOI 10.6028/NIST.SP.800-57pt1r5, 2020年5月, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf.
[OIDC.IDA] Lodderstedt, T., Fett, D., Haine, M., Pulido, A., Lehmann, K., and K. Koiwai, "OpenID Connect for Identity Assurance 1.0", 2024年10月1日, https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html.
[OpenID.Core] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0 incorporating errata set 2", 2023年12月15日, https://openid.net/specs/openid-connect-core-1_0.html.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, 1996年11月, https://www.rfc-editor.org/info/rfc2046.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, 2005年6月, https://www.rfc-editor.org/info/rfc4086.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, 2015年5月, https://www.rfc-editor.org/info/rfc7517.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, 2020年6月, https://www.rfc-editor.org/info/rfc8785.
[SD-CWT] Prorock, M., Steele, O., Birkholz, H., and R. Mahy, "Selective Disclosure CBOR Web Tokens (SD-CWT)", Work in Progress, Internet-Draft, draft-ietf-spice-sd-cwt-05, 2025年10月20日, https://datatracker.ietf.org/doc/html/draft-ietf-spice-sd-cwt-05.
[SD-JWT-VC] Terbu, O., Fett, D., and B. Campbell, "SD-JWT-based Verifiable Credentials (SD-JWT VC)", Work in Progress, Internet-Draft, draft-ietf-oauth-sd-jwt-vc-13, 2025年11月6日, https://datatracker.ietf.org/doc/html/draft-ietf-oauth-sd-jwt-vc-13.
[StructuredSuffix] IANA, "Structured Syntax Suffixes", https://www.iana.org/assignments/media-type-structured-suffix.
[TSL] Looker, T., Bastian, P., and C. Bormann, "Token Status List (TSL)", Work in Progress, Internet-Draft, draft-ietf-oauth-status-list-13, 2025年10月20日, https://datatracker.ietf.org/doc/html/draft-ietf-oauth-status-list-13.
[VC_DATA_v2.0] Sporny, M., Ed., Thiboeau, T., Ed., Jones, M. B., Ed., Cohen, G., Ed., and I. Herman, Ed., "Verifiable Credentials Data Model 2.0", W3C Recommendation, 2025年5月, https://www.w3.org/TR/vc-data-model-2.0/.

Appendix A. Additional Examples

以下の例は規範的ではなく、説明目的のみに提供される。\ 特に、claim の構造や選択的に開示可能な claim の選択は規範的ではない。

読みやすさのために改行を追加している。

A.1. Simple Structured SD-JWT

この例では、Section 5 とは対照的に、Issuer は address claim に対して構造化オブジェクトを作成し、claim の個々のメンバーを個別に開示できるようにすることを決定した。

次のユーザーに関するデータが、Issuer によって使用される入力 JWT Claims Set を構成する:

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

Issuer はまた、Verifier が claim の真の数を推測できないようにするため、decoy digests を追加することを決定した。

次の payload が SD-JWT に使用される:

{
  "_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"
}

SD-JWT payload 内の digests は、次の Disclosures を参照する:

Claim sub
- SHA-256 Hash:
  - X6ZAYOII2vPN40V7xExZwVwz7yRmLNcVwt5DL8RLv4g
- Disclosure: text WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN1YiIsICI2YzVjMGE0OS1iNTg5LTQzMWQtYmFlNy0yMTkxMjJhOWVjMmMiXQ
- Contents: json ["2GLC42sKQveCfGfryNRN9w", "sub", "6c5c0a49-b589-431d-bae7-219122a9ec2c"]

Claim given_name
- SHA-256 Hash:
  - ommFAicVT8LGHCB0uywx7fYuo3MHYKO15cz-RZEYM5Q
- Disclosure: text WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiXHU1OTJhXHU5MGNlIl0
- Contents: json ["eluV5Og3gSNII8EYnsxA_A", "given_name", "\u592a\u90ce"]

Claim family_name
- SHA-256 Hash:
  - C9inp6YoRaEXR427zYJP7Qrk1WH_8bdwOA_YUrUnGQU
- Disclosure: text WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIlx1NWM3MVx1NzUzMCJd
- Contents: json ["6Ij7tM-a5iVPGboS5tmvVA", "family_name", "\u5c71\u7530"]

Claim email
- SHA-256 Hash:
  - Kuet1yAa0HIQvYnOVd59hcViO9Ug6J2kSfqYRBeowvE
- Disclosure: text WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImVtYWlsIiwgIlwidW51c3VhbCBlbWFpbCBhZGRyZXNzXCJAZXhhbXBsZS5qcCJd
- Contents: json ["eI8ZWm9QnKPpNPeNenHdhQ", "email", "\"unusual email address\"@example.jp"]

Claim phone_number
- SHA-256 Hash:
  - s0BKYsLWxQQeU8tVlltM7MKsIRTrEIa1PkJmqxBBf5U
- Disclosure: text WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJlciIsICIrODEtODAtMTIzNC01Njc4Il0
- Contents: json ["Qg_O64zqAxe412a108iroA", "phone_number", "+81-80-1234-5678"]

Claim street_address
- SHA-256 Hash:
  - 6aUhzYhZ7SJ1kVmagQAO3u2ETN2CC1aHheZpKnaF0_E
- Disclosure: text WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInN0cmVldF9hZGRyZXNzIiwgIlx1Njc3MVx1NGVhY1x1OTBmZFx1NmUyZlx1NTMzYVx1ODI5ZFx1NTE2Y1x1NTcxMlx1ZmYxNFx1NGUwMVx1NzZlZVx1ZmYxMlx1MjIxMlx1ZmYxOCJd
- Contents: json [ "AJx-095VPrpTtN4QMOqROA", "street_address", "\u6771\u4eac\u90fd\u6e2f\u533a\u829d\u516c\u5712\uff14\u4e01\u76ee\uff12\u2212\uff18" ]

Claim locality
- SHA-256 Hash:
  - rvJd6iq6T5ejmsBMoGwuNXh9qAAFATAci40oidEeVsA
- Disclosure: text WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImxvY2FsaXR5IiwgIlx1Njc3MVx1NGVhY1x1OTBmZCJd
- Contents: json ["Pc33JM2LchcU_lHggv_ufQ", "locality", "\u6771\u4eac\u90fd"]

Claim region
- SHA-256 Hash:
  - PzzcVu0qbMuBGSjulfewzkesD9zutOExn5EWNwkrQ-k
- Disclosure: text WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInJlZ2lvbiIsICJcdTZlMmZcdTUzM2EiXQ
- Contents: json ["G02NSrQfjFXQ7Io09syajA", "region", "\u6e2f\u533a"]

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

Claim birthdate
- SHA-256 Hash:
  - MMldOFFzB2d0umlmpTIaGerhWdU_PpYfLvKhh_f_9aY
- Disclosure: text WyJ5eXRWYmRBUEdjZ2wyckk0QzlHU29nIiwgImJpcnRoZGF0ZSIsICIxOTQwLTAxLTAxIl0
- Contents: json ["yytVbdAPGcgl2rI4C9GSog", "birthdate", "1940-01-01"]

次の decoy digests が追加される:

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

以下は、address プロパティの region と country のみを開示する SD-JWT の提示例である:

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~

検証後、Verifier は後続処理のために次の Processed SD-JWT Payload を利用できる:

{
  "iss": "https://issuer.example.com",
  "iat": 1683000000,
  "exp": 1883000000,
  "address": {
    "region": "港区",
    "country": "JP"
  }
}

A.2. Complex Structured SD-JWT

この例では、複雑なオブジェクトを持つ SD-JWT を表現する。\ OpenID Connect for Identity Assurance [OIDC.IDA] で定義されたデータ構造を使用する。

Issuer は、入力 JWT Claims Set として次のユーザーデータを使用している:

{
  "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"
}

次の payload が SD-JWT に使用される:

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

SD-JWT payload 内の digests は、次の Disclosures を参照する:

Claim time
- SHA-256 Hash: vTwe3raHIFYgFA3xaUD2aMxFz5oDo8iBu05qKlOg9Lw
- Disclosure: text WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInRpbWUiLCAiMjAxMi0wNC0yM1Q xODoyNVoiXQ
- Contents: json ["2GLC42sKQveCfGfryNRN9w", "time", "2012-04-23T18:25Z"]

Claim verification_process
- SHA-256 Hash: 7h4UE9qScvDKodXVCuoKfKBJpVBfXMF_TmAGVaZe3Sc
- Disclosure: text WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgInZlcmlmaWNhdGlvbl9wcm9jZXN zIiwgImYyNGM2Zi02ZDNmLTRlYzUtOTczZS1iMGQ4NTA2ZjNiYzciXQ
- Contents: json [ "eluV5Og3gSNII8EYnsxA_A", "verification_process", "f24c6f-6d3f-4ec5-973e-b0d8506f3bc7" ]

Evidence entry fields
- Claim type
  - SHA-256 Hash: G5EnhOAOoU9X_6QMNvzFXjpEA_Rc-AEtm1bG_wcaKIk
  - Disclosure: text WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInR5cGUiLCAiZG9jdW1lbnQiXQ
  - Contents: json ["6Ij7tM-a5iVPGboS5tmvVA", "type", "document"]
- Claim method
  - SHA-256 Hash: WpxQ4HSoEtcTmCCKOeDslB_emucYLz2oO8oHNr1bEVQ
  - Disclosure: text WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm1ldGhvZCIsICJwaXBwIl0
  - Contents: json ["eI8ZWm9QnKPpNPeNenHdhQ", "method", "pipp"]
- Claim time
  - SHA-256 Hash: 9wpjVPWuD7PK0nsQDL8B06lmdgV3LVybhHydQpTNyLI
  - Disclosure: text WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInRpbWUiLCAiMjAxMi0wNC0yMlQ xMTozMFoiXQ
  - Contents: json ["Qg_O64zqAxe412a108iroA", "time", "2012-04-22T11:30Z"]
- Claim document
  - SHA-256 Hash: IhwFrWUB63RcZq9yvgZ0XPc7Gowh3O2kqXeBIswg1B4
  - Disclosure: text WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRvY3VtZW50IiwgeyJ0eXBlIjo gImlkY2FyZCIsICJpc3N1ZXIiOiB7Im5hbWUiOiAiU3RhZHQgQXVnc2J1cmciLC AiY291bnRyeSI6ICJERSJ9LCAibnVtYmVyIjogIjUzNTU0NTU0IiwgImRhdGVfb 2ZfaXNzdWFuY2UiOiAiMjAxMC0wMy0yMyIsICJkYXRlX29mX2V4cGlyeSI6ICIy MDIwLTAzLTIyIn1d
  - Contents: json [ "AJx-095VPrpTtN4QMOqROA", "document", { "type": "idcard", "issuer": { "name": "Stadt Augsburg", "country": "DE" }, "number": "53554554", "date_of_issuance": "2010-03-23", "date_of_expiry": "2020-03-22" } ]

Array Entry
- SHA-256 Hash: tYJ0TDucyZZCRMbROG4qRO5vkPSFRxFhUELc18CSl3k
- Disclosure: text WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgeyJfc2QiOiBbIjl3cGpWUFd1RDd QSzBuc1FETDhCMDZsbWRnVjNMVnliaEh5ZFFwVE55TEkiLCAiRzVFbmhPQU9vVT lYXzZRTU52ekZYanBFQV9SYy1BRXRtMWJHX3djYUtJayIsICJJaHdGcldVQjYzU mNacTl5dmdaMFhQYzdHb3doM08ya3FYZUJJc3dnMUI0IiwgIldweFE0SFNvRXRj VG1DQ0tPZURzbEJfZW11Y1lMejJvTzhvSE5yMWJFVlEiXX1d
- Contents: json [ "Pc33JM2LchcU_lHggv_ufQ", { "_sd": [ "9wpjVPWuD7PK0nsQDL8B06lmdgV3LVybhHydQpTNyLI", "G5EnhOAOoU9X_6QMNvzFXjpEA_Rc-AEtm1bG_wcaKIk", "IhwFrWUB63RcZq9yvgZ0XPc7Gowh3O2kqXeBIswg1B4", "WpxQ4HSoEtcTmCCKOeDslB_emucYLz2oO8oHNr1bEVQ" ] } ]

Claim given_name
- SHA-256 Hash: S_498bbpKzB6Eanftss0xc7cOaoneRr3pKr7NdRmsMo
- Disclosure: text WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdpdmVuX25hbWUiLCAiTWF4Il0
- Contents: json ["G02NSrQfjFXQ7Io09syajA", "given_name", "Max"]

Claim family_name
- SHA-256 Hash: Wxh_sV3iRH9bgrTBJi-aYHNCLt-vjhX1sd-igOf_9lk
- Disclosure: text WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImZhbWlseV9uYW1lIiwgIk1cdTA wZmNsbGVyIl0
- Contents: json ["lklxF5jMYlGTPUovMNIvCA", "family_name", "M\u00fcller"]

Claim nationalities
- SHA-256 Hash: hvDXhwmGcJQsBCA2OtjuLAcwAMpDsaU0nkovcKOqWNE
- Disclosure: text WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIm5hdGlvbmFsaXRpZXMiLCBbIkR FIl1d
- Contents: json ["nPuoQnkRFq3BIeAm7AnXFA", "nationalities", ["DE"]]

Claim birthdate
- SHA-256 Hash: WNA-UNK7F_zhsAb9syWO6IIQ1uHlTmOU8r8CvJ0cIMk
- Disclosure: text WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImJpcnRoZGF0ZSIsICIxOTU2LTA xLTI4Il0
- Contents: json ["5bPs1IquZNa0hkaFzzzZNw", "birthdate", "1956-01-28"]

Claim place_of_birth
- SHA-256 Hash: RiOiCn6_w5ZHaadkQMrcQJf0Jte5RwurRs54231DTlo
- Disclosure: text WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgInBsYWNlX29mX2JpcnRoIiwgeyJ jb3VudHJ5IjogIklTIiwgImxvY2FsaXR5IjogIlx1MDBkZXlra3ZhYlx1MDBlNm phcmtsYXVzdHVyIn1d
- Contents: json [ "5a2W0_NrlEZzfqmk_7Pq-w", "place_of_birth", { "country": "IS", "locality": "\u00deykkvab\u00e6jarklaustur" } ]

Claim address
- SHA-256 Hash: _O-wJiH3enSB4ROHntToQT8JmLtz-mhO2f1c89XoerQ
- Disclosure: text WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImFkZHJlc3MiLCB7ImxvY2FsaXR 5IjogIk1heHN0YWR0IiwgInBvc3RhbF9jb2RlIjogIjEyMzQ0IiwgImNvdW50cn kiOiAiREUiLCAic3RyZWV0X2FkZHJlc3MiOiAiV2VpZGVuc3RyYVx1MDBkZmUgM jIifV0
- Contents: json [ "y1sVU5wdfJahVdgwPgS7RQ", "address", { "locality": "Maxstadt", "postal_code": "12344", "country": "DE", "street_address": "Weidenstra\u00dfe 22" } ]

Claim birth_middle_name
- SHA-256 Hash: otkxuT14nBiwzNJ3MPaOitOl9pVnXOaEHal_xkyNfKI
- Disclosure: text WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImJpcnRoX21pZGRsZV9uYW1lIiw gIlRpbW90aGV1cyJd
- Contents: json ["HbQ4X8srVW3QDxnIJdqyOA", "birth_middle_name", "Timotheus"]

Claim salutation
- SHA-256 Hash: -aSznId9mWM8ocuQolCllsxVggq1-vHW4OtnhUtVmWw
- Disclosure: text WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgInNhbHV0YXRpb24iLCAiRHIuIl0
- Contents: json ["C9GSoujviJquEgYfojCb1A", "salutation", "Dr."]

Claim msisdn
- SHA-256 Hash: IKbrYNn3vA7WEFrysvbdBJjDDU_EvQIr0W18vTRpUSg
- Disclosure: text WyJreDVrRjE3Vi14MEptd1V4OXZndnR3IiwgIm1zaXNkbiIsICI0OTEyMzQ1Njc 4OSJd
- Contents: json ["kx5kF17V-x0JmwUx9vgvtw", "msisdn", "49123456789"]

以下は SD-JWT の提示例である:

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~

検証後、Verifier は次の Processed SD-JWT Payload を利用できる:

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

A.3. SD-JWT-Based Verifiable Credentials (SD-JWT VC) (continued)

The following is the issued SD-JWT:

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
qalFXejB0TGl1Q21NZU8wS3FhekdJIl19XQ~WyJqN0FEZGIwVVZiMExpMGNpUGNQMGV3
IiwgImFnZV9pbl95ZWFycyIsIDYyXQ~WyJXcHhKckZ1WDh1U2kycDRodDA5anZ3IiwgI
mFnZV9iaXJ0aF95ZWFyIiwgMTk2M10~WyJhdFNtRkFDWU1iSlZLRDA1bzNKZ3RRIiwgI
mlzc3VhbmNlX2RhdGUiLCAiMjAyMC0wMy0xMSJd~WyI0S3lSMzJvSVp0LXprV3ZGcWJV
TEtnIiwgImV4cGlyeV9kYXRlIiwgIjIwMzAtMDMtMTIiXQ~WyJjaEJDc3loeWgtSjg2S
S1hd1FEaUNRIiwgImlzc3VpbmdfYXV0aG9yaXR5IiwgIkRFIl0~WyJmbE5QMW5jTXo5T
GctYzlxTUl6XzlnIiwgImlzc3VpbmdfY291bnRyeSIsICJERSJd~

The following payload is used for the SD-JWT:

{
  "_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",
    "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"
    }
  }
}

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:

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

This is the payload of the corresponding Key Binding JWT:

{
  "nonce": "1234567890",
  "aud": "https://verifier.example.org",
  "iat": 1748537244,
  "sd_hash": "PjMYfM07VbJdMxLIluvRNb88JFljSX4n-G43Uc_BSRM"
}

After validation, the Verifier will have the following Processed SD-JWT Payload available for further handling:

{
  "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"]
}

A.4. W3C Verifiable Credentials Data Model v2.0

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

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

The following is the input JWT Claims Set:

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

The following is the issued SD-JWT:

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~

The following payload is used for the SD-JWT:

{
  "@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"
    }
  }
}

The digests in the SD-JWT payload reference the following Disclosures:

Claim atcCode
- SHA-256 Hash: 1cF5hLwkhMNIaqfWJrXI7NMWedL-9f6Y2PA52yPjSZI
- Disclosure: text WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImF0Y0NvZGUiLCAiSjA3QlgwMyJd
- Contents: json ["2GLC42sKQveCfGfryNRN9w", "atcCode", "J07BX03"]

Claim medicinalProductName
- SHA-256 Hash: Hiy6WWueLD5bn16298tPv7GXhmldMDOTnBi-CZbphNo
- Disclosure: text WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgIm1lZGljaW5hbFByb2R1Y3ROYW1lIiwgIkNPVklELTE5IFZhY2NpbmUgTW9kZXJuYSJd
- Contents: json [ "eluV5Og3gSNII8EYnsxA_A", "medicinalProductName", "COVID-19 Vaccine Moderna" ]

Claim marketingAuthorizationHolder
- SHA-256 Hash: Lb027q691jXXl-jC73vi8ebOj9smx3C-_og7gA4TBQE
- Disclosure: text WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgIm1hcmtldGluZ0F1dGhvcml6YXRpb25Ib2xkZXIiLCAiTW9kZXJuYSBCaW90ZWNoIl0
- Contents: json [ "6Ij7tM-a5iVPGboS5tmvVA", "marketingAuthorizationHolder", "Moderna Biotech" ]

Claim nextVaccinationDate
- SHA-256 Hash: R2fGbfA07Z_YlkqmNZyma1xyyx1XstIiS6B1Ybl2JZ4
- Disclosure: text WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm5leHRWYWNjaW5hdGlvbkRhdGUiLCAiMjAyMS0wOC0xNlQxMzo0MDoxMloiXQ
- Contents: json ["eI8ZWm9QnKPpNPeNenHdhQ", "nextVaccinationDate", "2021-08-16T13:40:12Z"]

Claim countryOfVaccination
- SHA-256 Hash: JzjLgtP29dP-B3td12P674gFmK2zy81HMtBgf6CJNWg
- Disclosure: text WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImNvdW50cnlPZlZhY2NpbmF0aW9uIiwgIkdFIl0
- Contents: json ["Qg_O64zqAxe412a108iroA", "countryOfVaccination", "GE"]

Claim dateOfVaccination
- SHA-256 Hash: zJK_eSMXjwM8dXmMZLnI8FGM08zJ3_ubGeEMJ-5TBy0
- Disclosure: text WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRhdGVPZlZhY2NpbmF0aW9uIiwgIjIwMjEtMDYtMjNUMTM6NDA6MTJaIl0
- Contents: json ["AJx-095VPrpTtN4QMOqROA", "dateOfVaccination", "2021-06-23T13:40:12Z"]

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

Claim gender
- SHA-256 Hash: 3nzLq81M2oN06wdv1shHvOEJVxZ5KLmdDkHEDJABWEI
- Disclosure: text WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdlbmRlciIsICJGZW1hbGUiXQ
- Contents: json ["G02NSrQfjFXQ7Io09syajA", "gender", "Female"]

Claim birthDate
- SHA-256 Hash: Pn1sWi06G4LJrnn-_RT0RbM_HTdxnPJQuX2fzWv_JOU
- Disclosure: text WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImJpcnRoRGF0ZSIsICIxOTYxLTA4LTE3Il0
- Contents: json ["lklxF5jMYlGTPUovMNIvCA", "birthDate", "1961-08-17"]

Claim givenName
- SHA-256 Hash: lF9uzdsw7HplGLc714Tr4WO7MGJza7tt7QFleCX4Itw
- Disclosure: text WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgImdpdmVuTmFtZSIsICJNYXJpb24iXQ
- Contents: json ["nPuoQnkRFq3BIeAm7AnXFA", "givenName", "Marion"]

Claim familyName
- SHA-256 Hash: 1lSQBNY24q0Th6OGzthq-7-4l6cAaxrYXOGZpeW_lnA
- Disclosure: text WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImZhbWlseU5hbWUiLCAiTXVzdGVybWFubiJd
- Contents: json ["5bPs1IquZNa0hkaFzzzZNw", "familyName", "Mustermann"]

Claim administeringCentre
- SHA-256 Hash: TCmzrl7K2gev_du7pcMIyzRLHp-Yeg-Fl_cxtrUvPxg
- Disclosure: text WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgImFkbWluaXN0ZXJpbmdDZW50cmUiLCAiUHJheGlzIFNvbW1lcmdhcnRlbiJd
- Contents: json ["5a2W0_NrlEZzfqmk_7Pq-w", "administeringCentre", "Praxis Sommergarten"]

Claim batchNumber
- SHA-256 Hash: V7kJBLK78TmVDOmrfJ7ZuUPHuK_2cc7yZRa4qV1txwM
- Disclosure: text WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImJhdGNoTnVtYmVyIiwgIjE2MjYzODI3MzYiXQ
- Contents: json ["y1sVU5wdfJahVdgwPgS7RQ", "batchNumber", "1626382736"]

Claim healthProfessional
- SHA-256 Hash: 1V_K-8lDQ8iFXBFXbZY9ehqR4HabWCi5T0ybIzZPeww
- Disclosure: text WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImhlYWx0aFByb2Zlc3Npb25hbCIsICI4ODMxMTAwMDAwMTUzNzYiXQ
- Contents: json ["HbQ4X8srVW3QDxnIJdqyOA", "healthProfessional", "883110000015376"]

This is an example of an SD-JWT+KB that discloses only type, medicinalProductName, atcCode of the vaccine, type of the recipient, type, order, and dateOfVaccination:

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

After the validation, the Verifier will have the following Processed SD-JWT Payload available for further handling:

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

A.5. Elliptic Curve Key Used in the Examples

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

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

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

Appendix B. Disclosure Format Considerations

As described in Section 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.

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.

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

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

However, a problem arises when computation over the data 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.

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:

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

or as:

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

The two representations of the value in family_name are very different on the byte level, but they yield equivalent objects. The same is true for the representations of address, which vary in white space and order of elements in the object.

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

There are generally two approaches to deal with this problem:

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.
Source string hardening: Instead of transferring data in a format that may introduce variations, a representation of the data is serialized. This representation is then used as the hashing input at the Verifier, but also transferred to the Verifier and used for the same digest calculation there. This means that the Verifier can easily compute and check the digest of the byte string before finally deserializing and accessing the data.

Mixed approaches are conceivable, i.e., transferring both the original JSON data 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.

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

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

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

Acknowledgements

We would like to thank Alen Horvat, Alex Hodder, Anders Rundgren, Arjan Geluk, Chad Parry, Christian Bormann, Christian Paquin, Dale Bowie, Dan Moore, David Bakker, David Waite, Deb Cooley, Fabian Hauck, Filip Skokan, Giuseppe De Marco, Jacob Ward, Jeffrey Yasskin, John Preuß Mattsson, Joseph Heenan, Justin Richer, Kushal Das, Martin Thomson, Matthew Miller, Michael Fraser, Michael B. Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard Barnes, Rohan Mahy, Roman Danyliw, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Shawn Emery, Simon Schulz, Takahiko Kawasaki, Tobias Looker, Torsten Lodderstedt, Vittorio Bertocci, Watson Ladd, and Yaron Sheffer for their contributions (some of which were substantial) to this document and to the initial set of implementations.

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

Authors' Addresses

Daniel Fett

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

Kristina Yasuda

Keio University
Email: kristina@sfc.keio.ac.jp

Brian Campbell

Ping Identity
Email: bcampbell@pingidentity.com

Selective Disclosure for JSON Web Tokens

Abstract

Status of This Memo

Copyright Notice

Table of Contents

1. Introduction

1.1. Feature Summary

1.2. Conventions and Terminology

2. Flow Diagram

3. Concepts

3.1. SD-JWT and Disclosures

3.2. Disclosing to a Verifier

3.3. Optional Key Binding

3.4. Verification

4. SD-JWT and SD-JWT+KB Data Formats

4.1. Issuer-Signed JWT

4.1.1. Hash Function Claim

4.1.2. Key Binding

4.2. Disclosures

4.2.1. Disclosures for Object Properties

Example

4.2.2. Disclosures for Array Elements

Example

4.2.3. Hashing Disclosures

4.2.4. Embedding Disclosure Digests in SD-JWTs

4.2.4.1. Object Properties

4.2.4.2. Array Elements

4.2.5. Decoy Digests

4.2.6. Recursive Disclosures

4.3. Key Binding JWT

4.3.1. Binding to an SD-JWT

4.3.2. Validating the Key Binding JWT

5. Example SD-JWT

5.1. Issuance

Claim given_name

Claim family_name

Claim email

Claim phone_number

Claim phone_number_verified

Claim address

Claim birthdate

Claim updated_at

Array Entry (nationalities)

Array Entry (nationalities)

5.2. Presentation

6. Considerations on Nested Data in SD-JWTs

6.1. Example: Flat SD-JWT

Claim address

6.2. Example: Structured SD-JWT

Claim street_address

Claim locality

Claim region

Claim country

6.3. Example: SD-JWT with Recursive Disclosures

Claim street_address

Claim locality

Claim region

Claim country

Claim address

7. Verification and Processing

7.1. Verification of the SD-JWT

7.2. Processing by the Holder

7.3. Verification by the Verifier

8. JWS JSON Serialization

8.1. New Unprotected Header Parameters

8.2. Flattened JSON Serialization

8.3. General JSON Serialization

8.4. Verification of the JWS JSON Serialized SD-JWT

9. Security Considerations

9.1. Mandatory Signing of the Issuer-Signed JWT

9.2. Manipulation of Disclosures

9.3. Entropy of the Salt

9.4. Choice of a Hash Algorithm

9.5. Key Binding

9.6. Concealing Claim Names

9.7. Selectively Disclosable Validity Claims

9.8. Distribution and Rotation of Issuer Signature Verification Key

9.9. Forwarding Credentials

9.10. Integrity of SD-JWTs and SD-JWT+KBs

9.11. Explicit Typing