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
This specification defines a mechanism for the selective disclosure of individual elements of a JSON data structure used as the payload of a JSON Web Signature (JWS). The primary use case is the selective disclosure of JSON Web Token (JWT) claims.
この仕様は、JSON Web 署名 (JWS) のペイロードとして使用される JSON データ構造の個々の要素を選択的に開示するためのメカニズムを定義します。主な使用例は、JSON Web Token (JWT) クレームの選択的開示です。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9901.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9901 で入手できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2025 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
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.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
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
4.2.2. Disclosures for Array Elements
4.2.3. Hashing Disclosures
4.2.4. Embedding Disclosure Digests in SD-JWTs
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
5.2. Presentation
6. Considerations on Nested Data in SD-JWTs
6.1. Example: Flat SD-JWT
6.2. Example: Structured SD-JWT
6.3. Example: SD-JWT with Recursive Disclosures
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
9.12. Key Pair Generation and Lifecycle Management
10. Privacy Considerations
10.1. Unlinkability
10.2. Storage of User Data
10.3. Confidentiality During Transport
10.4. Decoy Digests
10.5. Issuer Identifier
11. IANA Considerations
11.1. JSON Web Token Claims Registration
11.2. Media Type Registrations
11.3. Structured Syntax Suffixes Registration
12. References
12.1. Normative References
12.2. Informative References
Appendix A. Additional Examples
A.1. Simple Structured SD-JWT
A.2. Complex Structured SD-JWT
A.3. SD-JWT-Based Verifiable Credentials (SD-JWT VC)
A.4. W3C Verifiable Credentials Data Model v2.0
A.5. Elliptic Curve Key Used in the Examples
Appendix B. Disclosure Format Considerations
Acknowledgements
Authors' Addresses
The exchange of JSON data between systems is often secured against modification using JSON Web Signatures (JWSs) [RFC7515]. A popular application of JWS is the JSON Web Token (JWT) [RFC7519], a format that is often used to represent a user's identity. An ID Token as defined in OpenID Connect [OpenID.Core], for example, is a JWT containing the user's claims created by the server for consumption by a relying party. In cases where the JWT is sent immediately from the server to the relying party, as in OpenID Connect, the server can select at the time of issuance which user claims to include in the JWT, minimizing the information shared with the relying party who validates the JWT.
システム間の JSON データの交換は、多くの場合、JSON Web Signatures (JWS) [RFC7515] を使用して変更から保護されます。JWS の一般的なアプリケーションは、ユーザーの ID を表すためによく使用される形式である JSON Web Token (JWT) [RFC7519] です。たとえば、OpenID Connect [OpenID.Core] で定義されている ID トークンは、証明書利用者が使用するためにサーバーによって作成されたユーザーのクレームを含む JWT です。OpenID Connect のように、JWT がサーバーから証明書利用者に即座に送信される場合、サーバーは発行時にどのユーザーが JWT に含めると主張するかを選択でき、JWT を検証する証明書利用者と共有される情報を最小限に抑えることができます。
Another model is emerging that fully decouples the issuance of a JWT from its presentation. In this model, a JWT containing many claims is issued to an intermediate party, who holds the JWT (the Holder). The Holder can then present the JWT to different verifying parties (Verifiers) that each may only require a subset of the claims in the JWT. For example, the JWT may contain claims representing both an address and a birthdate. The Holder may elect to disclose only the address to one Verifier, and only the birthdate to a different Verifier.
JWT の発行とそのプレゼンテーションを完全に切り離す別のモデルが出現しています。このモデルでは、多くのクレームを含む JWT が、JWT を保持する中間者 (ホルダー) に発行されます。その後、所有者は、JWT 内のクレームのサブセットのみを必要とするさまざまな検証当事者 (Verifier) に JWT を提示できます。たとえば、JWT には、住所と生年月日の両方を表すクレームが含まれる場合があります。所有者は、1 人の検証者には住所のみを開示し、別の検証者には生年月日のみを開示することを選択できます。
Privacy principles of minimal disclosure in conjunction with this model demand a mechanism enabling selective disclosure of data elements while ensuring that Verifiers can still check the authenticity of the data provided. This specification defines such a mechanism for JSON payloads of JWSs, with JWTs as the primary use case.
このモデルと組み合わせた最小限の開示のプライバシー原則では、検証者が提供されたデータの信頼性を引き続き確認できるようにしながら、データ要素の選択的な開示を可能にするメカニズムが必要です。この仕様では、JWT を主な使用例として、JWS の JSON ペイロードに対するこのようなメカニズムを定義します。
Selectively Disclosable JWT (SD-JWT) is based on an approach called "salted hashes": For any data element that should be selectively disclosable, the Issuer of the SD-JWT does not include the cleartext of the data in the JSON payload of the JWS structure; instead, a digest of the data takes its place. For presentation to a Verifier, the Holder sends the signed payload along with the cleartext of those claims it wants to disclose. The Verifier can then compute the digest of the cleartext data and confirm it is included in the signed payload. To ensure that Verifiers cannot guess cleartext values of non-disclosed data elements, an additional salt value is used when creating the digest and sent along with the cleartext when disclosing it.
Selectively Disclosable JWT (SD-JWT) は、「ソルテッド ハッシュ」と呼ばれるアプローチに基づいています。選択的に開示する必要があるデータ要素については、SD-JWT の発行者は、JWS 構造の JSON ペイロードにデータの平文を含めません。代わりに、データのダイジェストが代わりに使用されます。検証者に提示するために、所有者は、開示したい主張の平文とともに署名されたペイロードを送信します。その後、検証者は平文データのダイジェストを計算し、それが署名済みペイロードに含まれていることを確認できます。検証者が非公開データ要素のクリアテキスト値を推測できないようにするために、ダイジェストの作成時に追加のソルト値が使用され、公開時にクリアテキストと一緒に送信されます。
To prevent attacks in which an SD-JWT is presented to a Verifier without the Holder's consent, this specification additionally defines a mechanism for binding the SD-JWT to a key under the control of the Holder (Key Binding). When Key Binding is enforced, a Holder has to prove possession of a private key belonging to a public key contained in the SD-JWT itself. It usually does so by signing over a data structure containing transaction-specific data, herein defined as the Key Binding JWT. An SD-JWT with a Key Binding JWT is called "SD-JWT+KB" in this specification.
ホルダーの同意なしに SD-JWT が検証者に提示される攻撃を防ぐために、この仕様では、SD-JWT をホルダーの制御下にあるキーにバインドするメカニズム (キー バインディング) を追加定義します。キー バインドが強制される場合、所有者は SD-JWT 自体に含まれる公開鍵に属する秘密鍵の所有を証明する必要があります。これは通常、トランザクション固有のデータを含むデータ構造 (ここではキー バインディング JWT として定義) に署名することによって行われます。キーバインディング JWT を備えた SD-JWT を、本仕様書では「SD-JWT+KB」と呼びます。
This specification defines two primary data formats:
この仕様では、次の 2 つの主要なデータ形式を定義します。
1. SD-JWT is a composite structure, consisting of a JWS plus optional Disclosures, enabling selective disclosure of portions of the JWS payload. It comprises the following:
1. SD-JWT は、JWS とオプションの開示で構成される複合構造であり、JWS ペイロードの一部の選択的な開示を可能にします。これは次の内容で構成されます。
* A format for enabling selective disclosure in nested JSON data structures, supporting selectively disclosable object properties (name/value pairs) and array elements.
* 入れ子になった JSON データ構造で選択的開示を可能にする形式。選択的に開示可能なオブジェクト プロパティ (名前と値のペア) および配列要素をサポートします。
* A format for encoding the selectively disclosable data items.
* 選択的に開示可能なデータ項目をエンコードするための形式。
* A format extending the JWS Compact Serialization, allowing for the combined transport of the Issuer-signed JSON data structure and the disclosable data items.
* JWS コンパクト シリアル化を拡張した形式。発行者署名の JSON データ構造と開示可能なデータ項目の組み合わせたトランスポートを可能にします。
* An alternate format extending the JWS JSON Serialization, also allowing for transport of the Issuer-signed JSON data structure and Disclosure data.
* JWS JSON シリアル化を拡張した代替形式。発行者署名の JSON データ構造と開示データの転送も可能になります。
2. SD-JWT+KB is a composite structure of an SD-JWT and a cryptographic Key Binding that can be presented to and verified by the Verifier. It comprises the following:
2. SD-JWT+KB は、検証者に提示して検証できる SD-JWT と暗号化キー バインディングの複合構造です。これは次の内容で構成されます。
* A mechanism for associating an SD-JWT with a key pair.
* SD-JWT をキー ペアに関連付けるメカニズム。
* A format for a Key Binding JWT (KB-JWT) that allows proof of possession of the private key of the associated key pair.
* 関連付けられたキー ペアの秘密キーの所有を証明できるキー バインディング JWT (KB-JWT) の形式。
* A format extending the SD-JWT format for the combined transport of the SD-JWT and the KB-JWT.
* SD-JWT と KB-JWT を組み合わせたトランスポート用に SD-JWT 形式を拡張した形式。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
Base64url:
Base64URL:
Denotes the URL-safe base64 encoding without padding defined in Section 2 of [RFC7515].
[RFC7515] のセクション 2 で定義されているパディングなしの URL セーフな Base64 エンコーディングを示します。
Claim:
請求：
In this document, refers generally to object properties (name/ value pairs) as well as array elements.
このドキュメントでは、配列要素だけでなくオブジェクトのプロパティ (名前と値のペア) も指します。
Selective Disclosure:
選択的開示:
Process of a Holder disclosing to a Verifier a subset of claims contained in a JWT issued by an Issuer.
発行者が発行した JWT に含まれるクレームのサブセットを所有者が検証者に開示するプロセス。
Selectively Disclosable JWT (SD-JWT):
選択的に開示可能な JWT (SD-JWT):
A composite structure, consisting of an Issuer-signed JWT (JWS; see [RFC7515]) and zero or more Disclosures, which supports selective disclosure as defined in this document. It can contain both regular claims and digests of selectively disclosable claims.
発行者署名付き JWT (JWS、[RFC7515] を参照) と、この文書で定義されている選択的開示をサポートする 0 個以上の開示で構成される複合構造。通常のクレームと、選択的に開示可能なクレームのダイジェストの両方を含めることができます。
Disclosure:
開示：
A base64url-encoded string of a JSON array that contains a salt, a claim name (present when the claim is a name/value pair and absent when the claim is an array element), and a claim value. The Disclosure is used to calculate a digest for the respective claim. The term Disclosure refers to the whole base64url-encoded string.
ソルト、クレーム名 (クレームが名前と値のペアの場合に存在し、クレームが配列要素の場合には存在しません)、およびクレーム値を含む JSON 配列の Base64URL エンコードされた文字列。開示は、それぞれの請求のダイジェストを計算するために使用されます。「開示」という用語は、base64url でエンコードされた文字列全体を指します。
Key Binding:
キーバインド:
Ability of the Holder to prove possession of an SD-JWT by proving control over a private key during the presentation. When utilizing Key Binding, an SD-JWT contains the public key corresponding to the private key controlled by the Holder (or a reference to this public key).
所有者は、プレゼンテーション中に秘密キーの制御を証明することで、SD-JWT の所有を証明できます。キー バインディングを利用する場合、SD-JWT には、所有者によって管理される秘密鍵に対応する公開鍵 (またはこの公開鍵への参照) が含まれます。
Key Binding JWT (KB-JWT):
キー バインディング JWT (KB-JWT):
A Key Binding JWT is said to "be tied to" a particular SD-JWT when its payload is signed using the key included in the SD-JWT payload, and the KB-JWT contains a hash of the SD-JWT in its sd_hash claim. Its format is defined in Section 4.3.
キー バインディング JWT は、SD-JWT ペイロードに含まれるキーを使用してペイロードが署名され、KB-JWT の sd_hash クレームに SD-JWT のハッシュが含まれている場合、特定の SD-JWT に「関連付けられている」と言われます。その形式はセクション 4.3 で定義されています。
Selectively Disclosable JWT with Key Binding (SD-JWT+KB):
キー バインドを備えた選択的に開示可能な JWT (SD-JWT+KB):
A composite structure, comprising an SD-JWT and a Key Binding JWT tied to that SD-JWT.
SD-JWT と、その SD-JWT に関連付けられたキー バインディング JWT で構成される複合構造。
Processed SD-JWT Payload:
処理された SD-JWT ペイロード:
The JSON object resulting from verification and processing of the Issuer-signed SD-JWT, with digest placeholders replaced by the corresponding values from the Disclosures.
発行者が署名した SD-JWT の検証と処理から得られる JSON オブジェクト。ダイジェスト プレースホルダーは開示情報の対応する値に置き換えられます。
Issuer:
発行者:
An entity that creates SD-JWTs.
SD-JWT を作成するエンティティ。
Holder:
ホルダー：
An entity that received SD-JWTs from the Issuer and has control over them. In the context of this document, the term may refer to the actual user, the supporting hardware and software in their possession, or both.
発行者から SD-JWT を受け取り、それを管理するエンティティ。このドキュメントの文脈では、この用語は実際のユーザー、ユーザーが所有するサポート ハードウェアおよびソフトウェア、またはその両方を指す場合があります。
Verifier:
検証者:
An entity that requests, checks, and extracts the claims from an SD-JWT with its respective Disclosures.
それぞれの開示情報を含む SD-JWT からクレームを要求、確認、抽出するエンティティ。
+------------+
| |
| Issuer |
| |
+------------+
|
Issues SD-JWT
including all Disclosures
|
v
+------------+
| |
| Holder |
| |
+------------+
|
Presents SD-JWT or SD-JWT+KB
including selected Disclosures
|
v
+-------------+
| |+
| Verifiers ||+
| |||
+-------------+||
+-------------+|
+-------------+
Figure 1: SD-JWT Issuance and Presentation Flow
図1: SD-JWTの発行と提示の流れ
This section describes SD-JWTs with their respective Disclosures and Key Binding at a conceptual level, abstracting from the data formats described in Section 4.
このセクションでは、セクション 4 で説明したデータ形式を抽象化して、概念レベルでのそれぞれの開示とキー バインディングを備えた SD-JWT について説明します。
An SD-JWT, at its core, is a digitally signed JSON document containing digests over the selectively disclosable claims with the Disclosures outside the document. Disclosures can be omitted without breaking the signature, and modifications to them can be detected. Selectively disclosable claims can be individual object properties (name/value pairs) or array elements.
SD-JWT の核心は、選択的に開示可能なクレームのダイジェストを含むデジタル署名された JSON ドキュメントであり、開示内容はドキュメントの外側にあります。署名を壊すことなく開示を省略することができ、その変更を検出することができます。選択的に開示可能なクレームは、個々のオブジェクト プロパティ (名前と値のペア) または配列要素にすることができます。
Each digest value ensures the integrity of, and maps to, the respective Disclosure. Digest values are calculated using a hash function over the Disclosures, each of which contains a cryptographically secure random salt, the claim name (only when the claim is an object property), and the claim value. The Disclosures are sent to the Holder with the SD-JWT in the format defined in Section 4. When presenting an SD-JWT to a Verifier, the Holder only includes the Disclosures for the claims that it wants to reveal to that Verifier.
各ダイジェスト値は、それぞれの開示の整合性を保証し、それぞれの開示にマッピングします。ダイジェスト値は、開示に対するハッシュ関数を使用して計算されます。各開示には、暗号的に安全なランダム ソルト、クレーム名 (クレームがオブジェクト プロパティである場合のみ)、クレーム値が含まれます。開示情報は、セクション 4 で定義された形式の SD-JWT とともに保有者に送信されます。SD-JWT を検証者に提示する場合、保有者は、その検証者に明らかにしたいクレームの開示情報のみを含めます。
An SD-JWT MAY also contain cleartext claims that are always disclosed to the Verifier.
SD-JWT には、常に検証者に開示される平文クレームも含めることができます (MAY)。
To disclose to a Verifier a subset of the SD-JWT claim values, a Holder sends only the Disclosures of those selectively released claims to the Verifier as part of the SD-JWT.
SD-JWT クレーム値のサブセットを検証者に開示するために、保有者は選択的に解放されたクレームの開示のみを SD-JWT の一部として検証者に送信します。
Key Binding is an optional feature. When Key Binding is required by the use case, the SD-JWT MUST contain information about the key material controlled by the Holder.
キー バインドはオプションの機能です。ユースケースでキーバインディングが必要な場合、SD-JWT には、ホルダーによって制御されるキーマテリアルに関する情報が含まれなければなりません (MUST)。
Note: How the public key is included in SD-JWT is described in Section 4.1.2.
注: 公開キーが SD-JWT にどのように含まれるかについては、セクション 4.1.2 で説明されています。
When a Verifier requires Key Binding, the Holder presents an SD-JWT+KB, consisting of an SD-JWT as well as a Key Binding JWT tied to that SD-JWT. The Key Binding JWT encodes a signature by the Holder's private key over
検証者がキー バインディングを必要とする場合、所有者は、SD-JWT とその SD-JWT に関連付けられたキー バインディング JWT で構成される SD-JWT+KB を提示します。キー バインディング JWT は、所有者の秘密キーによって署名をエンコードします。
* a hash of the SD-JWT,
* SD-JWT のハッシュ、
* a nonce to ensure the freshness of the signature, and
* 署名の鮮度を保証するためのノンス、および
* an audience value to indicate the intended Verifier for the document.
* ドキュメントの対象となる検証者を示す対象ユーザーの値。
Details of the format of Key Binding JWTs are described in Section 4.3.
キー バインディング JWT の形式の詳細については、セクション 4.3 で説明します。
At a high level, the Verifier
高いレベルでは、検証者は
* receives either an SD-JWT or an SD-JWT+KB from the Holder,
* ホルダーから SD-JWT または SD-JWT+KB を受け取り、
* verifies the signature on the SD-JWT (or the SD-JWT inside the SD-JWT+KB) using the Issuer's public key,
* 発行者の公開鍵を使用して SD-JWT (または SD-JWT+KB 内の SD-JWT) 上の署名を検証します。
* verifies the signature on the KB-JWT using the public key included (or referenced) in the SD-JWT, if the Verifier's policy requires Key Binding, and
* 検証者のポリシーでキー バインドが必要な場合、SD-JWT に含まれる (または参照される) 公開鍵を使用して KB-JWT の署名を検証します。
* calculates the digests over the Holder-Selected Disclosures and verifies that each digest is contained in the SD-JWT.
* 所有者が選択した開示に対してダイジェストを計算し、各ダイジェストが SD-JWT に含まれていることを検証します。
The detailed algorithm is described in Section 7.3.
詳細なアルゴリズムについてはセクション 7.3 で説明します。
An SD-JWT is composed of
SD-JWT は次のもので構成されます
* an Issuer-signed JWT, and
* 発行者が署名した JWT、および
* zero or more Disclosures.
* ゼロ以上の開示。
An SD-JWT+KB is composed of
SD-JWT+KB は次のもので構成されます。
* an SD-JWT (i.e., an Issuer-signed JWT and zero or more Disclosures), and
* SD-JWT (つまり、発行者署名付き JWT と 0 個以上の開示)、および
* a Key Binding JWT.
* キー バインディング JWT。
The Issuer-signed JWT, Disclosures, and Key Binding JWT are explained in Sections 4.1, 4.2, and 4.3, respectively.
発行者署名付き JWT、開示、およびキー バインディング JWT については、それぞれセクション 4.1、4.2、および 4.3 で説明します。
The compact serialized format for the SD-JWT is the concatenation of each part delineated with a single tilde ('~') character as follows, where "D.1" to "D.N" represent the respective Disclosures:
SD-JWT のコンパクトなシリアル化形式は、次のように単一のチルダ ('~') 文字で区切られた各部分を連結したものです。ここで、「D.1」から「D.N」はそれぞれの開示を表します。
<Issuer-signed JWT>~<D.1>~<D.2>~...~<D.N>~
The order of the concatenated parts MUST be the Issuer-signed JWT, a tilde character, zero or more Disclosures each followed by a tilde character, and lastly the optional Key Binding JWT. In the case that there is no Key Binding JWT, the last element MUST be an empty string and the last separating tilde character MUST NOT be omitted.
連結部分の順序は、発行者署名付き JWT、チルダ文字、0 個以上の開示情報、その後にチルダ文字が続き、最後にオプションのキー バインディング JWT でなければなりません。キー バインディング JWT がない場合、最後の要素は空の文字列にする必要があり、最後の分離チルダ文字を省略してはなりません。
The serialized format for an SD-JWT+KB extends the SD-JWT format by concatenating a Key Binding JWT.
SD-JWT+KB のシリアル化された形式は、キー バインディング JWT を連結することによって SD-JWT 形式を拡張します。
<Issuer-signed JWT>~<D.1>~<D.2>~...~<D.N>~<KB-JWT>
The two formats can be distinguished by the final ~ character that is present on an SD-JWT. A Verifier that expects an SD-JWT MUST verify that the final tilde-separated component is empty. A Verifier that expects an SD-JWT+KB MUST verify that its final tilde-separated component is a valid KB-JWT.
2 つの形式は、SD-JWT に存在する最後の ~ 文字によって区別できます。SD-JWT を期待する検証者は、最後のチルダで区切られたコンポーネントが空であることを検証しなければなりません (MUST)。SD-JWT+KB を期待する検証者は、最後のチルダで区切られたコンポーネントが有効な KB-JWT であることを検証しなければなりません (MUST)。
The Disclosures are linked to the Issuer-signed JWT through the digest values included therein.
開示情報は、そこに含まれるダイジェスト値を通じて発行者署名付き JWT にリンクされます。
When issuing to a Holder, the Issuer includes all the relevant Disclosures in the SD-JWT.
保有者に発行する場合、発行者は関連するすべての開示情報を SD-JWT に含めます。
When presenting to a Verifier, the Holder sends only the selected set of the Disclosures in the SD-JWT.
検証者に提示する場合、所有者は SD-JWT 内の選択された開示セットのみを送信します。
The Holder MAY send any subset of the Disclosures to the Verifier, i.e., none, some, or all Disclosures. For data that the Holder does not want to reveal to the Verifier, the Holder MUST NOT send Disclosures or reveal the salt values in any other way. A Holder MUST NOT send a Disclosure that was not included in the issued SD-JWT or send a Disclosure more than once.
保有者は、開示のサブセットを検証者に送信することができます。つまり、開示はまったくないか、一部、またはすべてです。保有者が検証者に明らかにしたくないデータについては、保有者は開示を送信したり、その他の方法でソルト値を明らかにしてはなりません。保有者は、発行された SD-JWT に含まれていない開示情報を送信したり、開示情報を複数回送信してはなりません。
To further illustrate the SD-JWT format, the following examples show a few different SD-JWT permutations, both with and without various constituent parts.
SD-JWT 形式をさらに詳しく説明するために、次の例では、さまざまな構成部分がある場合とない場合の、いくつかの異なる SD-JWT の置換を示します。
An SD-JWT without Disclosures:
開示のない SD-JWT:
<Issuer-signed JWT>~
An SD-JWT with Disclosures:
開示情報を含む SD-JWT:
<Issuer-signed JWT>~<Disclosure 1>~<Disclosure N>~
An SD-JWT+KB without Disclosures:
開示のない SD-JWT+KB:
<Issuer-signed JWT>~<KB-JWT>
An SD-JWT+KB with Disclosures:
開示情報を含む SD-JWT+KB:
<Issuer-signed JWT>~<Disclosure 1>~<Disclosure N>~<KB-JWT>
As an alternative illustration of the SD-JWT format, ABNF [RFC5234] for the SD-JWT, SD-JWT+KB, and various constituent parts is provided here (for those who celebrate):
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
An SD-JWT has a JWT component that MUST be signed using the Issuer's private key. It MUST NOT use the none algorithm.
SD-JWT には、発行者の秘密キーを使用して署名する必要がある JWT コンポーネントがあります。none アルゴリズムを使用してはなりません。
The payload of an SD-JWT is a JSON object according to the following rules:
SD-JWT のペイロードは、次のルールに従った JSON オブジェクトです。
1. The payload MAY contain the _sd_alg key described in Section 4.1.1.
1. ペイロードには、セクション 4.1.1 で説明されている _sd_alg キーが含まれてもよい (MAY)。
2. The payload MAY contain one or more digests of Disclosures to enable selective disclosure of the respective claims, created and formatted as described in Section 4.2.
2. ペイロードには、セクション 4.2 で説明されているように作成およびフォーマットされた、それぞれの請求項の選択的開示を可能にするために、1 つ以上の開示のダイジェストを含めることができます (MAY)。
3. The payload MAY contain one or more decoy digests to obscure the actual number of claims in the SD-JWT, created and formatted as described in Section 4.2.5.
3. ペイロードには、SD-JWT 内のクレームの実際の数を不明瞭にするため、セクション 4.2.5 で説明されているように作成およびフォーマットされた 1 つ以上のおとりダイジェストが含まれてもよい(MAY)。
4. The payload MAY contain one or more permanently disclosed claims.
4. ペイロードには、1 つ以上の永続的に開示されたクレームを含めることができます。
5. The payload MAY contain the Holder's public key(s) or reference(s) thereto, as explained in Section 4.1.2.
5. セクション 4.1.2 で説明されているように、ペイロードには、所有者の公開鍵またはその参照が含まれてもよい (MAY)。
6. The payload MAY contain further claims such as iss, iat, etc. as defined or required by the application using SD-JWTs.
6. ペイロードには、SD-JWT を使用するアプリケーションで定義または要求される iss、iat などのさらなるクレームを含めることができます (MAY)。
7. The payload MUST NOT contain the claims _sd or ... except for the purpose of conveying digests as described in Sections 4.2.4.1 and 4.2.4.2, respectively.
7. セクション 4.2.4.1 および 4.2.4.2 でそれぞれ説明されているダイジェストを伝達する目的を除き、ペイロードにはクレーム _sd または ... を含めてはなりません (MUST NOT)。
The same digest value MUST NOT appear more than once in the SD-JWT.
同じダイジェスト値が SD-JWT 内に複数回出現してはなりません (MUST NOT)。
Application and profiles of SD-JWT SHOULD be explicitly typed. See Section 9.11 for more details.
SD-JWT のアプリケーションとプロファイルは明示的に型指定する必要があります (SHOULD)。詳細については、セクション 9.11 を参照してください。
It is the Issuer who decides which claims are selectively disclosable by the Holder and which are not. Claims MAY be included as plaintext as well, e.g., if hiding the particular claims from the Verifier is not required in the intended use case. See Section 9.7 for considerations on making validity-controlling claims such as exp selectively disclosable.
どのクレームが保有者によって選択的に開示可能であり、どのクレームが開示できないかを決定するのは発行者です。たとえば、意図した使用例で検証者から特定のクレームを隠す必要がない場合、クレームは平文としても含めることができます (MAY)。exp などの有効性を制御するクレームを選択的に開示可能にする際の考慮事項については、セクション 9.7 を参照してください。
Claims that are not selectively disclosable are included in the SD-JWT in plaintext just as they would be in any other JSON structure.
選択的に開示できないクレームは、他の JSON 構造と同様に、平文で SD-JWT に含まれます。
The claim _sd_alg indicates the hash algorithm used by the Issuer to generate the digests as described in Section 4.2. When used, this claim MUST appear at the top level of the SD-JWT payload. It MUST NOT be used in any object nested within the payload. If the _sd_alg claim is not present at the top level, a default value of sha-256 MUST be used.
クレーム _sd_alg は、セクション 4.2 で説明されているように、発行者がダイジェストを生成するために使用するハッシュ アルゴリズムを示します。使用する場合、このクレームは SD-JWT ペイロードの最上位に表示されなければなりません。ペイロード内にネストされたオブジェクトでは使用してはなりません。_sd_alg クレームが最上位に存在しない場合は、デフォルト値の sha-256 を使用しなければなりません (MUST)。
This claim value is a case-sensitive string with the hash algorithm identifier. The hash algorithm identifier MUST be a hash algorithm value from the "Hash Name String" column in the "Named Information Hash Algorithm Registry" [Hash.Algs] or a value defined in another specification and/or profile of this specification.
このクレーム値は、ハッシュ アルゴリズム識別子を含む大文字と小文字が区別される文字列です。ハッシュ アルゴリズム識別子は、「名前付き情報ハッシュ アルゴリズム レジストリ」[Hash.Algs] の「ハッシュ名文字列」列のハッシュ アルゴリズム値、またはこの仕様の別の仕様および/またはプロファイルで定義された値でなければなりません。
To promote interoperability, implementations MUST support the sha-256 hash algorithm.
相互運用性を促進するには、実装は sha-256 ハッシュ アルゴリズムをサポートしなければなりません。
See Section 9 for requirements regarding entropy of the salt, minimum length of the salt, and choice of a hash algorithm.
ソルトのエントロピー、ソルトの最小長、およびハッシュ アルゴリズムの選択に関する要件については、セクション 9 を参照してください。
If the Issuer wants to enable Key Binding, it includes a public key associated with the Holder, or a reference thereto, using the cnf claim as defined in [RFC7800]. The jwk confirmation method, as defined in Section 3.2 of [RFC7800], is suggested for doing so, however, other confirmation methods can be used.
発行者がキーバインディングを有効にしたい場合、[RFC7800] で定義されている cnf クレームを使用して、保有者に関連付けられた公開鍵、またはその参照が含まれます。[RFC7800] のセクション 3.2 で定義されている jwk 確認方法がそのために推奨されていますが、他の確認方法を使用することもできます。
Note that, as was stated in [RFC7800], if an application needs to represent multiple proof-of-possession keys in the same SD-JWT, one way to achieve this is to use other claim names, in addition to cnf, to hold the additional proof-of-possession key information.
[RFC7800] で述べられているように、アプリケーションが同じ SD-JWT 内で複数の所有証明キーを表す必要がある場合、これを実現する 1 つの方法は、cnf に加えて他のクレーム名を使用して、追加の所有証明キー情報を保持することです。
It is outside the scope of this document to describe how the Holder key pair is established. For example, the Holder MAY create a key pair and provide a public key to the Issuer, the Issuer MAY create the key pair for the Holder, or Holder and Issuer MAY use pre-established key material.
Holder キー ペアがどのように確立されるかについては、このドキュメントの範囲外です。たとえば、所有者は鍵ペアを作成して発行者に公開鍵を提供してもよく、発行者が所有者の鍵ペアを作成してもよいし、所有者と発行者が事前に確立された鍵素材を使用してもよいです。
Note: The examples throughout this document use the cnf claim with the jwk member to include the raw public key by value in SD-JWT.
注: このドキュメント全体の例では、jwk メンバーを含む cnf クレームを使用して、SD-JWT に値による生の公開キーを含めます。
Disclosures are created differently depending on whether a claim is an object property (name/value pair) or an array element.
開示は、クレームがオブジェクト プロパティ (名前と値のペア) であるか、配列要素であるかに応じて、異なる方法で作成されます。
* For a claim that is an object property, the Issuer creates a Disclosure as described in Section 4.2.1.
* オブジェクト プロパティであるクレームの場合、発行者はセクション 4.2.1 で説明されている開示情報を作成します。
* For a claim that is an array element, the Issuer creates a Disclosure as described in Section 4.2.2.
* 配列要素であるクレームの場合、発行者はセクション 4.2.2 の説明に従って開示を作成します。
For each claim that is an object property and that is to be made selectively disclosable, the Issuer MUST create a Disclosure as follows:
オブジェクトのプロパティであり、選択的に開示可能にされるクレームごとに、発行者は次のように開示を作成しなければなりません。
* Create a JSON array of three elements in the following order:
* 次の順序で 3 つの要素の JSON 配列を作成します。
1. A salt value. MUST be a string. See Section 9.3 for security considerations. To achieve the recommended entropy of the salt, the Issuer can base64url-encode 128 bits of cryptographically secure random data, producing a string. The salt value MUST be unique for each claim that is to be selectively disclosed. The Issuer MUST NOT reveal the salt value to any party other than the Holder.
1. 塩分の値。文字列でなければなりません。セキュリティに関する考慮事項については、セクション 9.3 を参照してください。推奨されるソルトのエントロピーを達成するために、発行者は暗号的に安全な 128 ビットのランダム データを Base64URL エンコードして文字列を生成できます。ソルト値は、選択的に開示されるクレームごとに一意でなければなりません。発行者は、ソルト値を保有者以外の当事者に明らかにしてはなりません。
2. The claim name, or key, as it would be used in a regular JWT payload. It MUST be a string and MUST NOT be _sd, ..., or a claim name existing in the object as a permanently disclosed claim.
2. 通常の JWT ペイロードで使用されるクレーム名またはキー。これは文字列である必要があり、_sd、...、または永続的に開示されたクレームとしてオブジェクト内に存在するクレーム名であってはなりません。
3. The claim value, as it would be used in a regular JWT payload. The value can be of any type that is allowed in JSON, including numbers, strings, booleans, arrays, null, and objects.
3. 通常の JWT ペイロードで使用されるクレーム値。値には、数値、文字列、ブール値、配列、null、オブジェクトなど、JSON で許可されている任意の型を使用できます。
* base64url-encode the UTF-8 byte sequence of the JSON array. This string is the Disclosure.
* JSON 配列の UTF-8 バイト シーケンスをbase64url エンコードします。この文字列が開示情報です。
Note: The order was decided based on readability considerations: Salts have a constant length within the SD-JWT, claim names would be around the same length all the time, and claim values would vary in size, potentially being large objects.
注: この順序は読みやすさを考慮して決定されました。ソルトは SD-JWT 内で一定の長さを持ち、クレーム名は常にほぼ同じ長さになり、クレーム値はサイズが変化し、大きなオブジェクトになる可能性があります。
The following example illustrates the steps described above.
次の例は、上で説明した手順を示しています。
The array is created as follows:
配列は次のように作成されます。
["_26bc4LT-ac6q2KI6cBW5es", "family_name", "Möbius"]
The resultant Disclosure is:
結果として生じる開示は次のとおりです。
WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNw7ZiaXVzI l0
WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyISICJmYW1pbHlfbmFtZSIsICJNw7ZiaXVzI l0
Note that variations in whitespace, encoding of Unicode characters, ordering of object properties, etc., are allowed in the JSON representation and no canonicalization needs to be performed before base64url encoding because the digest is calculated over the base64url-encoded value itself. For example, the following strings are all valid and encode the same claim value "Möbius":
JSON 表現では空白、Unicode 文字のエンコード、オブジェクト プロパティの順序付けなどのバリエーションが許可されており、ダイジェストは Base64URL でエンコードされた値自体に対して計算されるため、Base64URL エンコードの前に正規化を実行する必要がないことに注意してください。たとえば、次の文字列はすべて有効であり、同じクレーム値「Möbius」をエンコードします。
* A different way to encode the Unicode umlaut:
* Unicode ウムラウトをエンコードする別の方法:
WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNXHUwMG Y2Yml1cyJd
WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyISICJmYW1pbHlfbmFtZSIsICJNXHUwMG Y2Yml1cyJd
* No white space:
* 空白なし:
WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsImZhbWlseV9uYW1lIiwiTcO2Yml1cy Jd
WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsImZhbWlseV9uYW1lIiwiTcO2Yml1cy Jd
* Newline characters between elements:
* 要素間の改行文字:
WwoiXzI2YmM0TFQtYWM2cTJLSTZjQlc1ZXMiLAoiZmFtaWx5X25hbWUiLAoiTcO2Ym l1cyIKXQ
WwoiXzI2YmM0TFQtYWM2cTJLSTZjQlc1ZXMiLAoiZmFtaWx5X25hbWUiLAoiTcO2Ym l1cyIKXQ
However, the digest is calculated over the respective base64url-encoded value itself, which effectively signs the variation chosen by the Issuer and makes it immutable in the context of the particular SD-JWT.
ただし、ダイジェストは、base64url でエンコードされたそれぞれの値自体に対して計算され、発行者によって選択されたバリエーションに効果的に署名され、特定の SD-JWT のコンテキストで不変になります。
See Appendix B for some further considerations on the Disclosure format approach.
開示フォーマットのアプローチに関するさらなる考慮事項については、付録 B を参照してください。
For each claim that is an array element and that is to be made selectively disclosable, the Issuer MUST create a Disclosure as follows:
配列要素であり、選択的に開示可能にされるクレームごとに、発行者は次のように開示を作成しなければなりません。
* The array MUST contain two elements in this order:
* 配列には、次の順序で 2 つの要素が含まれている必要があります。
1. The salt value as described in Section 4.2.1.
1. セクション 4.2.1 で説明されているソルト値。
2. The array element that is to be hidden. This value can be of any type that is allowed in JSON, including numbers, strings, booleans, arrays, and objects.
2. 非表示にする配列要素。この値には、数値、文字列、ブール値、配列、オブジェクトなど、JSON で許可されている任意の型を使用できます。
The Disclosure string is created by base64url-encoding the UTF-8 byte sequence of the resultant JSON array as described in Section 4.2.1. The same considerations regarding variations in the result of the JSON encoding apply.
開示文字列は、セクション 4.2.1 で説明されているように、結果として得られる JSON 配列の UTF-8 バイト シーケンスを Base64url エンコードすることによって作成されます。JSON エンコードの結果の変化に関する同じ考慮事項が適用されます。
For example, a Disclosure for the second element of the nationalities array in the following JWT Claims Set:
たとえば、次の JWT クレーム セットの国籍配列の 2 番目の要素の開示:
{
"nationalities": ["DE", "FR", "US"]
}
could be created by first creating the following array:
最初に次の配列を作成することで作成できます。
["lklxF5jMYlGTPUovMNIvCA", "FR"]
The resultant Disclosure would be:
結果として生じる開示は次のようになります。
WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIkZSIl0
WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIkZSIl0
Note that the size of an array alone can potentially reveal unintended information. The use of decoys, as described in Section 4.2.5, to consistently pad the size of an array can help obscure the actual number of elements present in any particular instance.
配列のサイズだけでは、意図しない情報が明らかになる可能性があることに注意してください。セクション 4.2.5 で説明されているように、配列のサイズを一貫してパディングするためにデコイを使用すると、特定のインスタンスに存在する実際の要素数をわかりにくくするのに役立ちます。
For embedding references to the Disclosures in the SD-JWT, each Disclosure is hashed using the hash algorithm specified in the _sd_alg claim described in Section 4.1.1, or SHA-256 if no algorithm is specified. The resultant digest is then included in the SD-JWT payload instead of the original claim value, as described next.
SD-JWT に開示への参照を埋め込む場合、各開示はセクション 4.1.1 で説明されている _sd_alg クレームで指定されたハッシュ アルゴリズムを使用してハッシュされます。アルゴリズムが指定されていない場合は SHA-256 が使用されます。次に説明するように、結果のダイジェストは、元のクレーム値の代わりに SD-JWT ペイロードに含まれます。
The digest MUST be computed over the US-ASCII bytes of the base64url-encoded value that is the Disclosure. This follows the convention in JWS [RFC7515] and JWE [RFC7516]. The bytes of the digest MUST then be base64url encoded.
ダイジェストは、開示であるbase64urlでエンコードされた値のUS-ASCIIバイトに対して計算されなければなりません(MUST)。これは、JWS [RFC7515] および JWE [RFC7516] の規則に従います。ダイジェストのバイトは、base64url でエンコードされなければなりません (MUST)。
It is important to note that:
以下の点に注意することが重要です。
* The input to the hash function MUST be the base64url-encoded Disclosure, not the bytes encoded by the base64url string.
* ハッシュ関数への入力は、base64url 文字列によってエンコードされたバイトではなく、base64url でエンコードされた開示でなければなりません。
* The bytes of the output of the hash function MUST be base64url encoded, and are not the bytes making up the (sometimes used) hex representation of the bytes of the digest.
* ハッシュ関数の出力のバイトは、base64url でエンコードされなければならず、ダイジェストのバイトの (場合によっては使用される) 16 進表現を構成するバイトではありません。
For example, the base64url-encoded SHA-256 digest of the Disclosure W yJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNw7ZiaXVzIl 0 for the family_name claim from Section 4.2.1 above is X9yH0Ajrdm1Oij4tWso9UzzKJvPoDxwmuEcO3XAdRC0.
たとえば、上記のセクション 4.2.1 の family_name クレームに対する開示情報 W yJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsICJmYW1pbHlfbmFtZSIsICJNw7ZiaXVzIl 0 の Base64url エンコードされた SHA-256 ダイジェストは次のとおりです。X9yH0Ajrdm1Oij4tWso9UzzKJvPoDxwmuEcO3XAdRC0。
For selectively disclosable claims, the digests of the Disclosures are embedded into the Issuer-signed JWT instead of the claims themselves. The precise way of embedding depends on whether a claim is an object property (name/value pair) or an array element.
選択的に開示可能なクレームの場合、クレーム自体ではなく、開示のダイジェストが発行者の署名付き JWT に埋め込まれます。埋め込みの正確な方法は、クレームがオブジェクト プロパティ (名前と値のペア) であるか、配列要素であるかによって異なります。
* For a claim that is an object property, the Issuer embeds a Disclosure digest as described in Section 4.2.4.1.
* オブジェクト プロパティであるクレームの場合、発行者はセクション 4.2.4.1 で説明されている開示ダイジェストを埋め込みます。
* For a claim that is an array element, the Issuer creates a Disclosure digest as described in Section 4.2.4.2.
* 配列要素であるクレームの場合、発行者はセクション 4.2.4.2 で説明されている開示ダイジェストを作成します。
Digests of Disclosures for object properties are added to an array under the new key _sd in the object. The _sd key MUST refer to an array of strings, each string being a digest of a Disclosure or a decoy digest as described in Section 4.2.5. An _sd key can be present at any level of the JSON object hierarchy, including at the top-level, nested deeper as described in Section 6, or in recursive Disclosures as described in Section 4.2.6.
オブジェクト プロパティの開示のダイジェストは、オブジェクト内の新しいキー _sd の下の配列に追加されます。_sd キーは文字列の配列を参照しなければなりません (MUST)。各文字列は、セクション 4.2.5 で説明されている開示のダイジェストまたはおとりダイジェストです。_sd キーは、JSON オブジェクト階層の任意のレベル (セクション 6 で説明するように最上位、より深くネストされたもの、またはセクション 4.2.6 で説明するように再帰的開示を含む) に存在できます。
The array MAY be empty in case the Issuer decided not to selectively disclose any of the claims at that level. However, it is RECOMMENDED to omit the _sd key in this case to save space.
発行者がそのレベルでクレームを選択的に開示しないことを決定した場合、配列は空であってもよい(MAY)。ただし、スペースを節約するために、この場合は _sd キーを省略することをお勧めします。
The Issuer MUST hide the original order of the claims in the array. To ensure this, it is RECOMMENDED to shuffle the array of hashes, e.g., by sorting it alphanumerically or randomly, after potentially adding decoy digests as described in Section 4.2.5. The precise method does not matter as long as it does not depend on the original order of elements.
発行者は、配列内のクレームの元の順序を非表示にしなければなりません。これを確実にするために、セクション 4.2.5 で説明されているように、おとりダイジェストを追加する可能性がある後、ハッシュの配列を英数字順またはランダムにソートするなどしてシャッフルすることが推奨されます。要素の元の順序に依存しない限り、正確な方法は問題ではありません。
For example, using the digest of the Disclosure from Section 4.2.3, the Issuer could create the following SD-JWT payload to make family_name selectively disclosable:
たとえば、発行者はセクション 4.2.3 の開示のダイジェストを使用して、次の SD-JWT ペイロードを作成して family_name を選択的に開示可能にすることができます。
{
"given_name": "Alice",
"_sd": ["X9yH0Ajrdm1Oij4tWso9UzzKJvPoDxwmuEcO3XAdRC0"]
}
Digests of Disclosures for array elements are added to the array in the same position as the original claim value in the array. For each digest, an object of the form {"...": "<digest>"} is added to the array. The key MUST always be the string ... (three dots). The value MUST be the digest of the Disclosure created as described in Section 4.2.3. There MUST NOT be any other keys in the object. Note that the string ... was chosen because the ellipsis character, typically entered as three period characters, is commonly used in places where content is omitted from the present context.
配列要素の開示のダイジェストは、配列内の元のクレーム値と同じ位置に配列に追加されます。ダイジェストごとに、{"...": "<digest>"} という形式のオブジェクトが配列に追加されます。キーは常に文字列 ... (3 つのドット) でなければなりません。値は、セクション 4.2.3 で説明されているように作成された開示のダイジェストでなければなりません。オブジェクト内に他のキーが存在してはなりません。文字列 ... が選択されたのは、通常 3 つのピリオド文字として入力される省略記号文字が、現在のコンテキストからコンテンツが省略される場所でよく使用されるためです。
For example, using the digest of the array element Disclosure created in Section 4.2.2, the Issuer could create the following SD-JWT payload to make the second element of the nationalities array selectively disclosable:
たとえば、セクション 4.2.2 で作成した配列要素 Disclosure のダイジェストを使用して、発行者は次の SD-JWT ペイロードを作成し、国籍配列の 2 番目の要素を選択的に開示可能にすることができます。
{
"nationalities":
["DE", {"...":"w0I8EKcdCtUPkGCNUrfwVp2xEgNjtoIDlOxc9-PlOhs"},
"US"]
}
As described in Section 7.3, Verifiers ignore all selectively disclosable array elements for which they did not receive a Disclosure. In the example above, the verification process would output an array with only two elements, ["DE", "US"], unless the matching Disclosure for the second element is received, in which case the output would be a three-element array, ["DE", "FR", "US"].
セクション 7.3 で説明されているように、検証者は、開示を受け取らなかった選択的に開示可能な配列要素をすべて無視します。上記の例では、2 番目の要素に一致する開示が受信されない限り、検証プロセスは 2 つの要素のみを含む配列 ["DE", "US"] を出力します。その場合、出力は 3 要素の配列 ["DE", "FR", "US"] になります。
An Issuer MAY add additional digests to the SD-JWT payload that are not associated with any claim. The purpose of such "decoy" digests is to make it more difficult for an adversarial Verifier to see the original number of claims or array elements contained in the SD-JWT. Decoy digests MAY be added both to the _sd array for objects as well as in arrays.
発行者は、いかなるクレームにも関連付けられていない追加のダイジェストを SD-JWT ペイロードに追加してもよい (MAY)。このような「おとり」ダイジェストの目的は、敵対的な検証者が SD-JWT に含まれる元のクレームまたは配列要素の数を確認することをより困難にすることです。おとりダイジェストは、オブジェクトの _sd 配列と配列の両方に追加できます (MAY)。
It is RECOMMENDED to create the decoy digests by hashing over a cryptographically secure random number. The bytes of the digest MUST then be base64url encoded as above. The same digest function as for the Disclosures MUST be used.
暗号的に安全な乱数をハッシュすることによって、おとりダイジェストを作成することが推奨されます。ダイジェストのバイトは、上記のようにbase64urlでエンコードされなければなりません(MUST)。開示と同じダイジェスト関数を使用しなければなりません。
For decoy digests, no Disclosure is sent to the Holder, i.e., the Holder will see digests that do not correspond to any Disclosure. See Section 10.4 for additional privacy considerations.
おとりダイジェストの場合、開示は保有者に送信されません。つまり、保有者はどの開示にも対応しないダイジェストを見ることになります。プライバシーに関するその他の考慮事項については、セクション 10.4 を参照してください。
To ensure readability and replicability, the examples in this specification do not contain decoy digests unless explicitly stated. For an example with decoy digests, see Appendix A.1.
読みやすさと再現性を確保するために、明示的に記載されていない限り、この仕様の例にはおとりダイジェストは含まれていません。おとりダイジェストの例については、付録 A.1 を参照してください。
The algorithms above are compatible with "recursive Disclosures", in which one selectively disclosed field reveals the existence of more selectively disclosable fields. For example, consider the following JSON structure:
上記のアルゴリズムは、1 つの選択的に開示されたフィールドが、より選択的に開示可能なフィールドの存在を明らかにする「再帰的開示」と互換性があります。たとえば、次の JSON 構造について考えてみましょう。
{
"family_name": "Möbius",
"nationalities": ["DE", "FR", "UK"]
}
When the Holder has multiple nationalities, the Issuer may wish to conceal the presence of any statement regarding nationalities while also allowing the Holder to reveal each of those nationalities individually. This can be accomplished by first making the entries within the "nationalities" array selectively disclosable, and then making the whole "nationalities" field selectively disclosable.
保有者が複数の国籍を有する場合、発行者は、保有者が各国籍を個別に明らかにできるようにしながら、国籍に関する記述の存在を隠したい場合があります。これは、最初に「国籍」配列内のエントリを選択的に開示可能にし、次に「国籍」フィールド全体を選択的に開示可能にすることによって実現できます。
The following shows each of the entries within the "nationalities" array being made selectively disclosable:
以下は、「国籍」配列内の各エントリが選択的に公開可能になっている様子を示しています。
{
"family_name": "Möbius",
"nationalities": [
{ "...": "PmnlrRjhLcwf8zTDdK15HVGwHtPYjddvD362WjBLwro" }
{ "...": "r823HFN6Ba_lpSANYtXqqCBAH-TsQlIzfOK0lRAFLCM" },
{ "...": "nP5GYjwhFm6ESlAeC4NCaIliW4tz0hTrUeoJB3lb5TA" }
]
}
Content of Disclosures:
開示内容：
PmnlrRj... = ["16_mAd0GiwaZokU26_0i0h","DE"]
r823HFN... = ["fn9fN0rD-fFs2n303ZI-0c","FR"]
nP5GYjw... = ["YIKesqOkXXNzMQtsX_-_lw","UK"]
Followed by making the whole "nationalities" array selectively disclosable:
続いて、「国籍」配列全体を選択的に開示可能にします。
{
"family_name": "Möbius",
"_sd": [ "5G1srw3RG5W4pVTwSsYxeOWosRBbzd18ZoWKkC-hBL4" ]
}
Content of Disclosures:
開示内容：
PmnlrRj... = ["16_mAd0GiwaZokU26_0i0h","DE"]
r823HFN... = ["fn9fN0rD-fFs2n303ZI-0c","FR"]
nP5GYjw... = ["YIKesqOkXXNzMQtsX_-_lw","UK"]
5G1srw3... = ["4drfeTtSUK3aY_-PF12gcX","nationalities",
[
{ "...": "PmnlrRjhLcwf8zTDdK15HVGwHtPYjddvD362WjBLwro" },
{ "...": "r823HFN6Ba_lpSANYtXqqCBAH-TsQlIzfOK0lRAFLCM" },
{ "...": "nP5GYjwhFm6ESlAeC4NCaIliW4tz0hTrUeoJB3lb5TA" }
]
]
With this set of Disclosures, the Holder could include the Disclosure with hash PmnlrRj... to disclose only the "DE" nationality, or include both PmnlrRj... and r823HFN... to disclose both the "DE" and "FR" nationalities, but hide the "UK" nationality. In either case, the Holder would also need to include the Disclosure with hash 5G1srw3... to disclose the nationalities field that contains the respective elements.
この開示セットを使用すると、保有者はハッシュ PmnlrRj... を含む開示を含めて「DE」国籍のみを開示することも、PmnlrRj... と r823HFN... の両方を含めて「DE」と「FR」国籍の両方を開示するが、「UK」国籍を隠すこともできます。いずれの場合も、保有者は、それぞれの要素を含む国籍フィールドを開示するために、ハッシュ 5G1srw3... を含む開示情報も含める必要があります。
Note that making recursive redactions introduces dependencies between the Disclosure objects in an SD-JWT. The r823HFN... Disclosure cannot be used without the 5G1srw3... Disclosure; since a Verifier would not have a matching hash that would tell it where the content of the r823HFN... Disclosure should be inserted. If a Disclosure object is included in an SD-JWT, then the SD-JWT MUST include any other Disclosure objects necessary to process the first Disclosure object. In other words, any Disclosure object in an SD-JWT must "connect" to the claims in the issuer-signed JWT, possibly via an intermediate Disclosure object. In the above example, it would be illegal to include any one of the PmnlrRj..., r823HFN..., nP5GYjw... Disclosure objects without also including the 5G1srw3... Disclosure object.
再帰的なリダクションを行うと、SD-JWT 内の Disclosure オブジェクト間に依存関係が生じることに注意してください。r823HFN... 開示は 5G1srw3... 開示なしでは使用できません。なぜなら、Verifier は、r823HFN... Disclosure のコンテンツをどこに挿入すべきかを示す一致するハッシュを持たないからです。Disclosure オブジェクトが SD-JWT に含まれている場合、SD-JWT には最初の Disclosure オブジェクトを処理するために必要な他の Disclosure オブジェクトが含まれなければなりません (MUST)。言い換えれば、SD-JWT 内の Disclosure オブジェクトは、場合によっては中間の Disclosure オブジェクトを介して、発行者署名付き JWT 内のクレームに「接続」する必要があります。上記の例では、5G1srw3... Disclosure オブジェクトを含めずに、PmnlrRj...、r823HFN...、nP5GYjw... Disclosure オブジェクトのいずれかを含めることは違法です。
This section defines the Key Binding JWT, which encodes a signature over an SD-JWT by the Holder's private key.
このセクションでは、所有者の秘密キーによって SD-JWT 上の署名をエンコードするキー バインディング JWT を定義します。
The Key Binding JWT MUST be a JWT according to [RFC7519], and it MUST contain the following elements:
キー バインディング JWT は [RFC7519] に準拠した JWT でなければならず、次の要素を含まなければなりません。
* in the JOSE header,
* JOSEヘッダーで、
- typ: REQUIRED. MUST be kb+jwt, which explicitly types the Key Binding JWT as recommended in Section 3.11 of [RFC8725].
- タイプ: 必須。[RFC8725] のセクション 3.11 で推奨されているように、キー バインディング JWT を明示的に型指定する kb+jwt でなければなりません。
- alg: REQUIRED. A digital signature algorithm identifier such as per the IANA "JSON Web Signature and Encryption Algorithms" registry. It MUST NOT be "none".
- alg: 必須。IANA「JSON Web Signature and Encryption Algorithms」レジストリなどのデジタル署名アルゴリズム識別子。「なし」であってはなりません。
* in the JWT payload,
* JWT ペイロード内で、
- iat: REQUIRED. The value of this claim MUST be the time at which the Key Binding JWT was issued using the syntax defined in [RFC7519].
- iat: 必須。このクレームの値は、[RFC7519] で定義された構文を使用してキー バインディング JWT が発行された時刻でなければなりません (MUST)。
- aud: REQUIRED. The value MUST be a single string that identifies the intended receiver of the Key Binding JWT. How the value is represented is up to the protocol used and is out of scope for this specification.
- aud: 必須。値は、キー バインディング JWT の対象受信者を識別する単一の文字列である必要があります。値がどのように表現されるかは使用されるプロトコルに依存し、この仕様の範囲外です。
- "nonce": REQUIRED. Ensures the freshness of the signature or its binding to the given transaction. The value type of this claim MUST be a string. How this value is obtained is up to the protocol used and is out of scope for this specification.
- 「ノンス」: 必須。署名の鮮度、または指定されたトランザクションへの署名のバインディングを保証します。このクレームの値のタイプは文字列でなければなりません。この値がどのように取得されるかは使用されるプロトコルに依存し、この仕様の範囲外です。
- sd_hash: REQUIRED. The base64url-encoded hash value over the Issuer-signed JWT and the selected Disclosures as defined below.
- sd_hash: 必須。以下に定義されているように、発行者が署名した JWT および選択された開示に対する、base64url でエンコードされたハッシュ値。
The general extensibility model of JWT means that additional claims and header parameters can be added to the Key Binding JWT. However, unless there is a compelling reason, this SHOULD be avoided, as it may harm interoperability and burden conceptual integrity.
JWT の一般的な拡張性モデルは、追加のクレームとヘッダー パラメーターをキー バインディング JWT に追加できることを意味します。ただし、やむを得ない理由がない限り、これは避けるべきです。相互運用性を損ない、概念的な整合性に負担がかかる可能性があるためです。
The hash value in the sd_hash claim binds the KB-JWT to the specific SD-JWT. The sd_hash value MUST be computed over the US-ASCII bytes of the encoded SD-JWT, i.e., the Issuer-signed JWT, a tilde character, and zero or more Disclosures selected for presentation to the Verifier, each followed by a tilde character:
sd_hash クレームのハッシュ値は、KB-JWT を特定の SD-JWT にバインドします。sd_hash 値は、エンコードされた SD-JWT、つまり発行者が署名した JWT、チルダ文字、および検証者への提示用に選択された 0 個以上の開示の US-ASCII バイトに対して計算されなければなりません (それぞれの後にチルダ文字が続きます)。
<Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclosure N>~
The bytes of the digest MUST then be base64url encoded.
ダイジェストのバイトは、base64url でエンコードされなければなりません (MUST)。
The same hash algorithm as for the Disclosures MUST be used (defined by the _sd_alg element in the Issuer-signed JWT or the default value, as defined in Section 4.1.1).
開示と同じハッシュ アルゴリズムを使用しなければなりません (発行者署名済み JWT の _sd_alg 要素によって定義されるか、セクション 4.1.1 で定義されるデフォルト値によって定義されます)。
Whether to require Key Binding is up to the Verifier's policy, based on the set of trust requirements (such as trust frameworks) it belongs to. See Section 9.5 for security considerations.
キー バインディングを要求するかどうかは、検証者が属する一連の信頼要件 (信頼フレームワークなど) に基づいて、検証者のポリシーによって決まります。セキュリティに関する考慮事項については、セクション 9.5 を参照してください。
If the Verifier requires Key Binding, the Verifier MUST ensure that the key with which it validates the signature on the Key Binding JWT is the key specified in the SD-JWT as the Holder's public key. For example, if the SD-JWT contains a cnf value with a jwk member, the Verifier would parse the provided JWK and use it to verify the Key Binding JWT.
検証者がキー バインディングを必要とする場合、検証者は、キー バインディング JWT 上の署名を検証するために使用したキーが、SD-JWT で所有者の公開キーとして指定されたキーであることを確認しなければなりません。たとえば、SD-JWT に jwk メンバーを含む cnf 値が含まれている場合、検証者は提供された JWK を解析し、それを使用してキー バインディング JWT を検証します。
Details of the validation process are defined in Section 7.3.
検証プロセスの詳細はセクション 7.3 で定義されています。
In this example, a simple SD-JWT is demonstrated. This example is split into issuance and presentation.
この例では、単純な SD-JWT を示します。この例は、発行とプレゼンテーションに分かれています。
Note: Throughout the examples in this document, line breaks were added to JSON strings and base64-encoded strings to adhere to the line-length limit in RFCs and for readability. JSON does not allow line breaks within strings.
注: このドキュメントの例では、RFC の行長制限を遵守し、読みやすくするために、JSON 文字列と Base64 でエンコードされた文字列に改行が追加されています。JSON では文字列内での改行は許可されません。
The following data about the user comprises the input JWT Claims Set used by the Issuer:
ユーザーに関する次のデータは、発行者が使用する入力 JWT クレーム セットを構成します。
{
"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"
]
}
In this example, the following decisions were made by the Issuer in constructing the SD-JWT:
この例では、SD-JWT を構築する際に発行者によって次の決定が行われました。
* The nationalities array is always visible, but its contents are selectively disclosable.
* 国籍配列は常に表示されますが、その内容は選択的に公開できます。
* The sub element as well as essential verification data (iss, exp, cnf, etc.) are always visible.
* サブ要素と重要な検証データ (iss、exp、cnf など) は常に表示されます。
* All other claims are selectively disclosable.
* 他のすべての請求項は選択的に開示可能です。
* For address, the Issuer is using a flat structure, i.e., all the claims in the address claim can only be disclosed in full. Other options are discussed in Section 6.
* アドレスについては、発行者はフラット構造を使用しています。つまり、アドレス クレーム内のすべてのクレームは完全にのみ開示できます。他のオプションについてはセクション 6 で説明します。
The following payload is used for the SD-JWT:
次のペイロードが 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"
}
}
}
The respective Disclosures, created by the Issuer, are listed below. In the text below and in other locations in this specification, the label "SHA-256 Hash:" is used as a shorthand for the label "Base64url-Encoded SHA-256 Hash:".
発行者によって作成されたそれぞれの開示は以下にリストされています。以下のテキストおよびこの仕様の他の場所では、ラベル「SHA-256 ハッシュ:」はラベル「Base64url-Encoded SHA-256 Hash:」の短縮形として使用されます。
* Claim given_name:
* 指定された名前を要求します:
- SHA-256 Hash:
- SHA-256 ハッシュ:
jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4
jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4
- Disclosure:
- 開示：
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9obiJ d
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9obiJ d
- Contents:
- コンテンツ：
["2GLC42sKQveCfGfryNRN9w", "given_name", "John"]
["2GLC42sKQveCfGfryNRN9w"、"指定された名前"、"ジョン"]
* Claim family_name:
* family_name を主張します:
- SHA-256 Hash:
- SHA-256 ハッシュ:
TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo
TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo
- Disclosure:
- 開示：
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIkRvZSJ d
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIkRvZSJ d
- Contents:
- コンテンツ：
["eluV5Og3gSNII8EYnsxA_A", "family_name", "Doe"]
["eluV5Og3gSNII8EYnsxA_A", "family_name", "Doe"]
* Claim email:
* 請求メール:
- SHA-256 Hash:
- SHA-256 ハッシュ:
JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYlSE
JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYLSE
- Disclosure:
- 開示：
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImVtYWlsIiwgImpvaG5kb2VAZXh hbXBsZS5jb20iXQ
WyI2SWo3dE0tyTVpVlBHYm9TNXRtdlZBIiwgImVtYWlsIiwgImpvaG5kb2VAZXh hbXBsZS5jb20iXQ
- Contents:
- コンテンツ：
["6Ij7tM-a5iVPGboS5tmvVA", "email", "johndoe@example.com"]
["6Ij7tM-a5iVPGboS5tmvVA"、"電子メール"、"johndoe@example.com"]
* Claim phone_number:
* 電話番号を請求してください:
- SHA-256 Hash:
- SHA-256 ハッシュ:
PorFbpKuVu6xymJagvkFsFXAbRoc2JGlAUA2BA4o7cI
PorFbpKuVu6xymJagvkFsFXAbRoc2JGlAUA2BA4o7cI
- Disclosure:
- 開示：
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInBob25lX251bWJlciIsICIrMS0 yMDItNTU1LTAxMDEiXQ
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInBob25lX251bWJlciICIRMS0 yMDItNTU1LTAxMDEiXQ
- Contents:
- コンテンツ：
["eI8ZWm9QnKPpNPeNenHdhQ", "phone_number", "+1-202-555-0101"]
["eI8ZWm9QnKPpNPeNenHdhQ"、"電話番号"、"+1-202-555-0101"]
* Claim phone_number_verified:
* Phone_number_verified を要求します:
- SHA-256 Hash:
- SHA-256 ハッシュ:
XQ_3kPKt1XyX7KANkqVR6yZ2Va5NrPIvPYbyMvRKBMM
XQ_3kPKt1XyX7KANkqVR6yZ2Va5NrPIvPYbyMvRKBMM
- Disclosure:
- 開示：
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJlcl92ZXJpZml lZCIsIHRydWVd
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJlcl92ZXJpZml lZCIsIHRydWVd
- Contents:
- コンテンツ：
["Qg_O64zqAxe412a108iroA", "phone_number_verified", true]
["Qg_O64zqAxe412a108iroA"、"電話番号_認証済み"、true]
* Claim address:
* 請求先住所:
- SHA-256 Hash:
- SHA-256 ハッシュ:
XzFrzwscM6Gn6CJDc6vVK8BkMnfG8vOSKfpPIZdAfdE
XzFrzwscM6Gn6CJDc6vVK8BkMnfG8vOSKfpPIZDAfDE
- Disclosure:
- 開示：
WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImFkZHJlc3MiLCB7InN0cmVldF9 hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRvd24iLC AicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0
WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImFkZHJlc3MiLCB7InN0cmVldF9 hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRvd24iLCAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0
- Contents:
- コンテンツ：
["AJx-095VPrpTtN4QMOqROA", "address", {"street_address": "123 Main St", "locality": "Anytown", "region": "Anystate", "country": "US"}]
["AJx-095VPrpTtN4QMOqROA", "住所", {"番地": "123 Main St", "地域": "任意の町", "地域": "任意の州", "国": "米国"}]
* Claim birthdate:
* 生年月日を主張します:
- SHA-256 Hash:
- SHA-256 ハッシュ:
gbOsI4Edq2x2Kw-w5wPEzakob9hV1cRD0ATN3oQL9JM
gbOSI4Edq2x2Kw-w5wPEzakob9hV1cRD0ATN3oQL9JM
- Disclosure:
- 開示：
WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImJpcnRoZGF0ZSIsICIxOTQwLTA xLTAxIl0
WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImJpcnRoZGF0ZSIsICIxOTQwLTA xLTAxIl0
- Contents:
- コンテンツ：
["Pc33JM2LchcU_lHggv_ufQ", "birthdate", "1940-01-01"]
["Pc33JM2LchcU_lHggv_ufQ"、"生年月日"、"1940-01-01"]
* Claim updated_at:
* updated_at を要求:
- SHA-256 Hash:
- SHA-256 ハッシュ:
CrQe7S5kqBAHt-nMYXgc6bdt2SH5aTY1sU_M-PgkjPI
CrQe7S5kqBAHt-nMYXgc6bdt2SH5aTY1sU_M-PgkjPI
- Disclosure:
- 開示：
WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInVwZGF0ZWRfYXQiLCAxNTcwMDA wMDAwXQ
WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInVwZGF0ZWRfYXQiLCAxNTcwMDA wMDAwXQ
- Contents:
- コンテンツ：
["G02NSrQfjFXQ7Io09syajA", "updated_at", 1570000000]
["G02NSrQfjFXQ7Io09syajA"、"updated_at"、1570000000]
* Array Entry:
* 配列エントリ:
- SHA-256 Hash:
- SHA-256 ハッシュ:
pFndjkZ_VCzmyTa6UjlZo3dh-ko8aIKQc9DlGzhaVYo
pFndjkZ_VCzmyTa6UjlZo3dh-ko8aIKQc9DlGzhaVYo
- Disclosure:
- 開示：
WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIlVTIl0
WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIlVTIl0
- Contents:
- コンテンツ：
["lklxF5jMYlGTPUovMNIvCA", "US"]
["lklxF5jMYlGTPUovMNIvCA", "米国"]
* Array Entry:
* 配列エントリ:
- SHA-256 Hash:
- SHA-256 ハッシュ:
7Cf6JkPudry3lcbwHgeZ8khAv1U1OSlerP0VkBJrWZ0
7Cf6JkPudry3lcbwHgeZ8khAv1U1OSlerP0VkBJrWZ0
- Disclosure:
- 開示：
WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIkRFIl0
WyJuUHVvUW5rUkZxM0JJZUFTN0FuWEZBIiwgIkRFIl0
- Contents:
- コンテンツ：
["nPuoQnkRFq3BIeAm7AnXFA", "DE"]
["nPuoQnkRFq3BIeAm7AnXFA", "DE"]
The payload is then signed by the Issuer to create the following Issuer-signed JWT:
次に、ペイロードは発行者によって署名され、次の発行者署名付き JWT が作成されます。
eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb
IkNyUWU3UzVrcUJBSHQtbk1ZWGdjNmJkdDJTSDVhVFkxc1VfTS1QZ2tqUEkiLCAiSnpZ
akg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQWWxTRSIsICJQb3JGYnBL
dVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1
SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAiWFFfM2tQS3QxWHlYN0tB
TmtxVlI2eVoyVmE1TnJQSXZQWWJ5TXZSS0JNTSIsICJYekZyendzY002R242Q0pEYzZ2
Vks4QmtNbmZHOHZPU0tmcFBJWmRBZmRFIiwgImdiT3NJNEVkcTJ4Mkt3LXc1d1BFemFr
b2I5aFYxY1JEMEFUTjNvUUw5Sk0iLCAianN1OXlWdWx3UVFsaEZsTV8zSmx6TWFTRnpn
bGhRRzBEcGZheVF3TFVLNCJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu
Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAic3ViIjog
InVzZXJfNDIiLCAibmF0aW9uYWxpdGllcyI6IFt7Ii4uLiI6ICJwRm5kamtaX1ZDem15
VGE2VWpsWm8zZGgta284YUlLUWM5RGxHemhhVllvIn0sIHsiLi4uIjogIjdDZjZKa1B1
ZHJ5M2xjYndIZ2VaOGtoQXYxVTFPU2xlclAwVmtCSnJXWjAifV0sICJfc2RfYWxnIjog
InNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0y
NTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VH
ZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlG
MkhaUSJ9fX0.MczwjBFGtzf-6WMT-hIvYbkb11NrV1WMO-jTijpMPNbswNzZ87wY2uHz
-CXo6R04b7jYrpj9mNRAvVssXou1iw
Adding the Disclosures produces the SD-JWT:
開示情報を追加すると、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~
The following non-normative example shows an SD-JWT+KB as it would be sent from the Holder to the Verifier. Note that it consists of six tilde-separated parts, with the Issuer-signed JWT as shown above in the beginning, four Disclosures (for the claims given_name, family_name, address, and one of the nationalities) in the middle, and the Key Binding JWT as the last element.
次の非標準的な例は、ホルダーから検証者に送信される SD-JWT+KB を示しています。これは、チルダで区切られた 6 つの部分で構成されており、上に示したように発行者署名付き JWT が先頭にあり、中央に 4 つの開示 (クレームの Given_name、family_name、住所、国籍の 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
The following Key Binding JWT payload was created and signed for this presentation by the Holder:
次のキー バインディング JWT ペイロードは、このプレゼンテーションのために所有者によって作成され、署名されました。
{
"nonce": "1234567890",
"aud": "https://verifier.example.org",
"iat": 1748537244,
"sd_hash": "0_Af-2B-EhLWX5ydh_w2xzwmO6iM66B_2QCEanI4fUY"
}
If the Verifier did not require Key Binding, then the Holder could have presented the SD-JWT with selected Disclosures directly, instead of encapsulating it in an SD-JWT+KB.
検証者がキー バインディングを必要としなかった場合、所有者は、SD-JWT+KB にカプセル化する代わりに、選択した開示情報を SD-JWT に直接提示することができたでしょう。
After validation, the Verifier will have the following Processed SD-JWT Payload available for further handling:
検証後、検証者は次の処理済み SD-JWT ペイロードをさらに処理できるようになります。
{
"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"
}
Being JSON, an object in an SD-JWT payload MAY contain name/value pairs where the value is another object or objects MAY be elements in arrays. In SD-JWT, the Issuer decides for each claim individually, on each level of the JSON, whether or not the claim should be selectively disclosable. This choice can be made on each level independent of whether keys higher in the hierarchy are selectively disclosable.
JSON であるため、SD-JWT ペイロード内のオブジェクトには、値が別のオブジェクトであるか、オブジェクトが配列内の要素である場合がある、名前と値のペアが含まれる場合があります。SD-JWT では、発行者は、JSON の各レベルで、クレームごとに個別に、クレームを選択的に開示するかどうかを決定します。この選択は、階層内の上位のキーが選択的に公開可能かどうかに関係なく、各レベルで行うことができます。
From this it follows that the _sd key containing digests MAY appear multiple times in an SD-JWT, and likewise, there MAY be multiple arrays within the hierarchy with each having selectively disclosable elements. Digests of selectively disclosable claims MAY even appear within other Disclosures.
このことから、ダイジェストを含む _sd キーは SD-JWT 内に複数回出現してもよく、同様に、それぞれが選択的に公開可能な要素を持つ複数の配列が階層内にあってもよいということになります。選択的に開示可能な請求のダイジェストは、他の開示内に掲載される場合もあります。
The following examples illustrate some of the options an Issuer has. It is up to the Issuer to decide which structure to use, depending on, for example, the expected use cases for the SD-JWT, requirements for privacy, size considerations, or operating environment requirements. For more examples with nested structures, see Appendices A.1 and A.2.
次の例は、発行者が持つオプションのいくつかを示しています。SD-JWT の予想されるユースケース、プライバシーの要件、サイズの考慮事項、または動作環境の要件などに応じて、どの構造を使用するかを決定するのは発行者の責任です。入れ子構造のその他の例については、付録 A.1 および A.2 を参照してください。
The following input JWT Claims Set is used as an example throughout this section:
このセクションでは、次の入力 JWT クレーム セットが例として使用されます。
{
"sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c",
"address": {
"street_address": "Schulstr. 12",
"locality": "Schulpforta",
"region": "Sachsen-Anhalt",
"country": "DE"
}
}
Note: The following examples of the structures are non-normative and are not intended to represent all possible options. They are also not meant to define or restrict how address claim can be represented in an SD-JWT.
注: 次の構造例は非標準的なものであり、考えられるすべてのオプションを表すことを意図したものではありません。また、SD-JWT でアドレス要求を表現する方法を定義または制限することも意図されていません。
The Issuer can decide to treat the address claim as a block that can either be disclosed completely or not at all. The following example shows that in this case, the entire address claim is treated as an object in the Disclosure.
発行者は、アドレス要求を完全に開示できるブロックとして扱うか、まったく開示しないかを決定できます。次の例は、この場合、アドレス要求全体が開示のオブジェクトとして扱われることを示しています。
{
"_sd": [
"fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do"
],
"iss": "https://issuer.example.com",
"iat": 1683000000,
"exp": 1883000000,
"sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c",
"_sd_alg": "sha-256"
}
The Issuer would create the following Disclosure referenced by the one hash in the SD-JWT:
発行者は、SD-JWT 内の 1 つのハッシュによって参照される次の開示を作成します。
* Claim address:
* 請求先住所:
- SHA-256 Hash:
- SHA-256 ハッシュ:
fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do
fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do
- Disclosure:
- 開示：
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImFkZHJlc3MiLCB7InN0cmVldF9 hZGRyZXNzIjogIlNjaHVsc3RyLiAxMiIsICJsb2NhbGl0eSI6ICJTY2h1bHBmb3 J0YSIsICJyZWdpb24iOiAiU2FjaHNlbi1BbmhhbHQiLCAiY291bnRyeSI6ICJER SJ9XQ
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImFkZHJlc3MiLCB7InN0cmVldF9 hZGRyZXNzIjogIlNjaHVsc3RyLiAxMiISICJsb2NhbGl0eSI6ICJTY2h1bHBmb3J0YSISICJyZWdpb24iOiAiU2FjaHNlbi1BbmhhbHQiLCAiY291bnRyeSI6ICJER SJ9XQ
- Contents:
- コンテンツ：
["2GLC42sKQveCfGfryNRN9w", "address", {"street_address": "Schulstr. 12", "locality": "Schulpforta", "region": "Sachsen-Anhalt", "country": "DE"}]
["2GLC42sKQveCfGfryNRN9w", "住所", {"番地": "Schulstr. 12", "地域": "Schulpforta", "地域": "ザクセン アンハルト州", "国": "DE"}]
The Issuer may instead decide to make the address claim contents selectively disclosable individually:
代わりに、発行者は、アドレス要求の内容を個別に選択的に開示可能にすることを決定する場合があります。
{
"iss": "https://issuer.example.com",
"iat": 1683000000,
"exp": 1883000000,
"sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c",
"address": {
"_sd": [
"6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0",
"9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM",
"KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88",
"WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM"
]
},
"_sd_alg": "sha-256"
}
In this case, the Issuer would use the following data in the Disclosures for the address sub-claims:
この場合、発行者はアドレスサブクレームの開示で次のデータを使用します。
* Claim street_address:
* 請求番地番地:
- SHA-256 Hash:
- SHA-256 ハッシュ:
9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM
9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM
- Disclosure:
- 開示：
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN0cmVldF9hZGRyZXNzIiwgIlN jaHVsc3RyLiAxMiJd
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN0cmVldF9hZGRyZXNzIiwgIlN jaHVsc3RyLiAxMiJd
- Contents:
- コンテンツ：
["2GLC42sKQveCfGfryNRN9w", "street_address", "Schulstr. 12"]
["2GLC42sKQveCfGfryNRN9w"、"番地"、"Schulstr. 12"]
* Claim locality:
* 主張の場所:
- SHA-256 Hash:
- SHA-256 ハッシュ:
6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0
6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0
- Disclosure:
- 開示：
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImxvY2FsaXR5IiwgIlNjaHVscGZ vcnRhIl0
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImxvY2FsaXR5IiwgIlNjaHVscGZ vcnRhIl0
- Contents:
- コンテンツ：
["eluV5Og3gSNII8EYnsxA_A", "locality", "Schulpforta"]
["eluV5Og3gSNII8EYnsxA_A"、"地域"、"シュルプフォルタ"]
* Claim region:
* クレーム領域:
- SHA-256 Hash:
- SHA-256 ハッシュ:
KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88
KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88
- Disclosure:
- 開示：
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInJlZ2lvbiIsICJTYWNoc2VuLUF uaGFsdCJd
WyI2SWo3dE0tyTVpVlBHYm9TNXRtdlZBIiwgInJlZ2lvbiISICJTYWNoc2VuLUF uaGFsdCJd
- Contents:
- コンテンツ：
["6Ij7tM-a5iVPGboS5tmvVA", "region", "Sachsen-Anhalt"]
["6Ij7tM-a5iVPGboS5tmvVA"、"地域"、"ザクセン-アンハルト州"]
* Claim country:
* 請求国:
- SHA-256 Hash:
- SHA-256 ハッシュ:
WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM
WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM
- Disclosure:
- 開示：
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImNvdW50cnkiLCAiREUiXQ
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImNvdW50cnkiLCAiREUiXQ
- Contents:
- コンテンツ：
["eI8ZWm9QnKPpNPeNenHdhQ", "country", "DE"]
["eI8ZWm9QnKPpNPeNenHdhQ"、"国"、"DE"]
The Issuer may also make one sub-claim of address permanently disclosed and hide only the other sub-claims:
発行者は、住所の 1 つのサブクレームを永久に公開し、他のサブクレームのみを非表示にすることもできます。
{
"iss": "https://issuer.example.com",
"iat": 1683000000,
"exp": 1883000000,
"sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c",
"address": {
"_sd": [
"6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0",
"9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM",
"KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88"
],
"country": "DE"
},
"_sd_alg": "sha-256"
}
In this case, there would be no Disclosure for country, since it is provided in the clear.
この場合、平文で提供されるため、国に関する開示はありません。
The Issuer may also decide to make the address claim contents selectively disclosable recursively, i.e., the address claim is made selectively disclosable as well as its sub-claims:
発行者は、アドレス クレームの内容を再帰的に選択的に開示可能にすることも決定できます。つまり、アドレス クレームとそのサブクレームが選択的に開示可能になります。
{
"_sd": [
"HvrKX6fPV0v9K_yCVFBiLFHsMaxcD_114Em6VT8x1lg"
],
"iss": "https://issuer.example.com",
"iat": 1683000000,
"exp": 1883000000,
"sub": "6c5c0a49-b589-431d-bae7-219122a9ec2c",
"_sd_alg": "sha-256"
}
The Issuer first creates Disclosures for the sub-claims and then includes their digests in the Disclosure for the address claim:
発行者は最初にサブクレームの開示を作成し、次にそのダイジェストをアドレスクレームの開示に含めます。
* Claim street_address:
* 請求番地番地:
- SHA-256 Hash:
- SHA-256 ハッシュ:
9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM
9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM
- Disclosure:
- 開示：
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN0cmVldF9hZGRyZXNzIiwgIlN jaHVsc3RyLiAxMiJd
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN0cmVldF9hZGRyZXNzIiwgIlN jaHVsc3RyLiAxMiJd
- Contents:
- コンテンツ：
["2GLC42sKQveCfGfryNRN9w", "street_address", "Schulstr. 12"]
["2GLC42sKQveCfGfryNRN9w"、"番地"、"Schulstr. 12"]
* Claim locality:
* 主張の場所:
- SHA-256 Hash:
- SHA-256 ハッシュ:
6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0
6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0
- Disclosure:
- 開示：
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImxvY2FsaXR5IiwgIlNjaHVscGZ vcnRhIl0
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImxvY2FsaXR5IiwgIlNjaHVscGZ vcnRhIl0
- Contents:
- コンテンツ：
["eluV5Og3gSNII8EYnsxA_A", "locality", "Schulpforta"]
["eluV5Og3gSNII8EYnsxA_A"、"地域"、"シュルプフォルタ"]
* Claim region:
* クレーム領域:
- SHA-256 Hash:
- SHA-256 ハッシュ:
KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88
KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88
- Disclosure:
- 開示：
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInJlZ2lvbiIsICJTYWNoc2VuLUF uaGFsdCJd
WyI2SWo3dE0tyTVpVlBHYm9TNXRtdlZBIiwgInJlZ2lvbiISICJTYWNoc2VuLUF uaGFsdCJd
- Contents:
- コンテンツ：
["6Ij7tM-a5iVPGboS5tmvVA", "region", "Sachsen-Anhalt"]
["6Ij7tM-a5iVPGboS5tmvVA"、"地域"、"ザクセン-アンハルト州"]
* Claim country:
* 請求国:
- SHA-256 Hash:
- SHA-256 ハッシュ:
WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM
WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM
- Disclosure:
- 開示：
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImNvdW50cnkiLCAiREUiXQ
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImNvdW50cnkiLCAiREUiXQ
- Contents:
- コンテンツ：
["eI8ZWm9QnKPpNPeNenHdhQ", "country", "DE"]
["eI8ZWm9QnKPpNPeNenHdhQ"、"国"、"DE"]
* Claim address:
* 請求先住所:
- SHA-256 Hash:
- SHA-256 ハッシュ:
HvrKX6fPV0v9K_yCVFBiLFHsMaxcD_114Em6VT8x1lg
HvrKX6fPV0v9K_yCVFBiLFHsMaxcD_114Em6VT8x1lg
- Disclosure:
- 開示：
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImFkZHJlc3MiLCB7Il9zZCI6IFs iNnZoOWJxLXpTNEdLTV83R3BnZ1ZiWXp6dTZvT0dYcm1OVkdQSFA3NVVkMCIsIC I5Z2pWdVh0ZEZST0NnUnJ0TmNHVVhtRjY1cmRlemlfNkVyX2o3NmttWXlNIiwgI ktVUkRQaDRaQzE5LTN0aXotRGYzOVY4ZWlkeTFvVjNhM0gxRGEyTjBnODgiLCAi V045cjlkQ0JKOEhUQ3NTMmpLQVN4VGpFeVc1bTV4NjVfWl8ycm8yamZYTSJdfV0
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImFkZHJlc3MiLCB7Il9zZCI6IFs iNnZoOWJxLXpTNEdLTV83R3BnZ1ZiWXp6dTZvT0dYcm1OVkdQSFA3NVVkMCISICI5Z2pWdVh0ZEZST0NnUnJ0TmNHVVhtRjY1cmRlemlfNkVyX2o3NmttWXlNIiwgI ktVUkRQaDRaQzE5LTN0aXotRGYzOVY4ZWlkeTFvVjNhM0gxRGEyTjBnODgiLCAiV045cjlkQ0JKOEhUQ3NTMmpLQVN4VGpFeVc1bTV4NjVfWl8ycm8yamZYTSJdfV0
- Contents:
- コンテンツ：
["Qg_O64zqAxe412a108iroA", "address", {"_sd": ["6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0", "9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM", "KURDPh4ZC19- 3tiz-Df39V8eidy1oV3a3H1Da2N0g88", "WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM"]}]
["Qg_O64zqAxe412a108iroA", "アドレス", {"_sd": ["6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0", "9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM","KURDPh4ZC19- 3tiz-Df39V8eidy1oV3a3H1Da2N0g88"、"WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM"]}]
Upon receiving an SD-JWT, either directly or as a component of an SD-JWT+KB, a Holder or Verifier needs to ensure that:
SD-JWT を直接、または SD-JWT+KB のコンポーネントとして受信すると、所有者または検証者は次のことを確認する必要があります。
* the Issuer-signed JWT is valid, and
* 発行者の署名付き JWT が有効であり、かつ
* all Disclosures are valid and correspond to a respective digest value in the Issuer-signed JWT (directly in the payload or recursively included in the contents of other Disclosures).
* すべての開示は有効であり、発行者が署名した JWT 内のそれぞれのダイジェスト値に対応します (ペイロード内に直接、または他の開示の内容に再帰的に含まれます)。
The Holder or the Verifier MUST perform the following checks when receiving an SD-JWT to validate the SD-JWT and extract the payload:
所有者または検証者は、SD-JWT を受信したときに次のチェックを実行して、SD-JWT を検証し、ペイロードを抽出しなければなりません。
1. Separate the SD-JWT into the Issuer-signed JWT and the Disclosures (if any).
1. SD-JWT を発行者署名 JWT と開示情報 (存在する場合) に分離します。
2. Validate the Issuer-signed JWT:
2. 発行者が署名した JWT を検証します。
a. Ensure that the used signing algorithm was deemed secure for the application. Refer to [RFC8725], Sections 3.1 and 3.2 for details. The "none" algorithm MUST NOT be accepted.
a. 使用された署名アルゴリズムがアプリケーションにとって安全であるとみなされていることを確認してください。詳細については、[RFC8725] のセクション 3.1 および 3.2 を参照してください。「なし」アルゴリズムは受け入れてはなりません。
b. Validate the signature over the Issuer-signed JWT per Section 5.2 of [RFC7515].
b. [RFC7515] のセクション 5.2 に従って、発行者が署名した JWT で署名を検証します。
c. Validate the Issuer and that the signing key belongs to this Issuer.
c. 発行者を検証し、署名キーがこの発行者に属していることを検証します。
d. Check that the _sd_alg claim value is understood and the hash algorithm is deemed secure according to the Holder or Verifier's policy (see Section 4.1.1).
d. _sd_alg クレーム値が理解されており、所有者または検証者のポリシーに従ってハッシュ アルゴリズムが安全であるとみなされていることを確認します (セクション 4.1.1 を参照)。
3. Process the Disclosures and embedded digests in the Issuer-signed JWT as follows:
3. 発行者署名済み JWT 内の開示情報と埋め込みダイジェストを次のように処理します。
a. For each Disclosure provided:
a. 提供される各開示について:
i. Calculate the digest over the base64url-encoded string as described in Section 4.2.3.
i. セクション 4.2.3 の説明に従って、base64url でエンコードされた文字列のダイジェストを計算します。
b. (*) Identify all embedded digests in the Issuer-signed JWT as follows:
b. (*) 発行者署名付き JWT 内のすべての埋め込みダイジェストを次のように識別します。
i. Find all objects having an _sd key that refers to an array of strings.
i. 文字列の配列を参照する _sd キーを持つすべてのオブジェクトを検索します。
ii. Find all array elements that are objects with one key, that key being ... and referring to a string.
ii.1 つのキーを持つオブジェクトであるすべての配列要素を検索します。そのキーは ... であり、文字列を参照します。
c. (**) For each embedded digest found in the previous step:
c. (**) 前のステップで見つかった各埋め込みダイジェストについて:
i. Compare the value with the digests calculated previously and find the matching Disclosure. If no such Disclosure can be found, the digest MUST be ignored.
i. 値を以前に計算したダイジェストと比較し、一致する開示を見つけます。そのような開示が見つからない場合、ダイジェストは無視されなければなりません。
ii. If the digest was found in an object's _sd key:
ii.オブジェクトの _sd キーでダイジェストが見つかった場合:
1. If the contents of the respective Disclosure is not a JSON array of three elements (salt, claim name, claim value), the SD-JWT MUST be rejected.
1. それぞれの開示の内容が 3 つの要素 (ソルト、クレーム名、クレーム値) の JSON 配列ではない場合、SD-JWT は拒否されなければなりません (MUST)。
2. If the claim name is _sd or ..., the SD-JWT MUST be rejected.
2. クレーム名が _sd または ... の場合、SD-JWT は拒否されなければなりません。
3. If the claim name already exists at the level of the _sd key, the SD-JWT MUST be rejected.
3. クレーム名が _sd キーのレベルにすでに存在する場合、SD-JWT は拒否されなければなりません (MUST)。
4. Insert, at the level of the _sd key, a new claim using the claim name and claim value from the Disclosure.
4. _sd キーのレベルに、開示のクレーム名とクレーム値を使用して新しいクレームを挿入します。
5. Recursively process the value using the steps described in (*) and (**).
5. (*) および (**) で説明されている手順を使用して、値を再帰的に処理します。
iii. If the digest was found in an array element:
iii.ダイジェストが配列要素で見つかった場合:
1. If the contents of the respective Disclosure is not a JSON array of two elements (salt, value), the SD-JWT MUST be rejected.
1. それぞれの Disclosure の内容が 2 つの要素 (salt、value) からなる JSON 配列ではない場合、SD-JWT は拒否されなければなりません (MUST)。
2. Replace the array element with the value from the Disclosure.
2. 配列要素を開示情報の値に置き換えます。
3. Recursively process the value using the steps described in (*) and (**).
3. (*) および (**) で説明されている手順を使用して、値を再帰的に処理します。
d. Remove all array elements for which the digest was not found in the previous step.
d. 前の手順でダイジェストが見つからなかったすべての配列要素を削除します。
e. Remove all _sd keys and their contents from the Issuer-signed JWT payload. If this results in an object with no properties, it should be represented as an empty object {}.
e. すべての _sd キーとその内容を発行者署名の JWT ペイロードから削除します。この結果、プロパティのないオブジェクトが生成される場合は、空のオブジェクト {} として表す必要があります。
f. Remove the claim _sd_alg from the SD-JWT payload.
f. SD-JWT ペイロードからクレーム _sd_alg を削除します。
4. If any digest value is encountered more than once in the Issuer-signed JWT payload (directly or recursively via other Disclosures), the SD-JWT MUST be rejected.
4. 発行者が署名した JWT ペイロード内でダイジェスト値が (直接または他の開示を介して再帰的に) 複数回検出された場合、SD-JWT は拒否されなければなりません (MUST)。
5. If any Disclosure was not referenced by digest value in the Issuer-signed JWT (directly or recursively via other Disclosures), the SD-JWT MUST be rejected.
5. いずれかの開示が、発行者署名付き JWT 内のダイジェスト値によって (直接または他の開示を介して再帰的に) 参照されていない場合、SD-JWT は拒否されなければなりません (MUST)。
6. Check that the SD-JWT is valid using claims such as nbf, exp, and aud in the processed payload, if present. If a required validity-controlling claim is missing (see Section 9.7), the SD-JWT MUST be rejected.
6. 処理されたペイロードに nbf、exp、aud などのクレームが存在する場合は、それを使用して SD-JWT が有効であることを確認します。必要な有効性制御クレームが欠落している場合 (セクション 9.7 を参照)、SD-JWT は拒否されなければなりません (MUST)。
If any step fails, the SD-JWT is not valid, and processing MUST be aborted. Otherwise, the JSON document resulting from the preceding processing and verification steps, herein referred to as the "Processed SD-JWT Payload", can be made available to the application to be used for its intended purpose.
いずれかのステップが失敗した場合、SD-JWT は無効であるため、処理は中止されなければなりません。それ以外の場合、前述の処理および検証ステップで生成された JSON ドキュメント (本明細書では「処理された SD-JWT ペイロード」と呼ぶ) を、アプリケーションが意図した目的で使用できるようにすることができます。
Note that these processing steps do not yield any guarantees to the Holder about having received a complete set of Disclosures. That is, for some digest values in the Issuer-signed JWT (which are not decoy digests), there may be no corresponding Disclosures, for example, if the message from the Issuer was truncated. It is up to the Holder how to maintain the mapping between the Disclosures and the plaintext claim values to be able to display them to the user when needed.
これらの処理ステップは、保有者が開示情報の完全なセットを受け取ったという保証を与えるものではないことに注意してください。つまり、発行者が署名した JWT 内の一部のダイジェスト値 (おとりダイジェストではない) については、たとえば発行者からのメッセージが切り詰められている場合、対応する開示が存在しない可能性があります。必要なときにユーザーに開示情報を表示できるように、開示情報と平文クレーム値の間のマッピングを維持する方法は保有者次第です。
The Issuer provides the Holder with an SD-JWT, not an SD-JWT+KB. If the Holder receives an SD-JWT+KB, it MUST be rejected.
発行者は保有者に SD-JWT+KB ではなく SD-JWT を提供します。所有者が SD-JWT+KB を受け取った場合、それを拒否しなければなりません。
When receiving an SD-JWT, the Holder MUST do the following:
SD-JWT を受信する場合、所有者は次のことを行う必要があります。
1. Process the SD-JWT as defined in Section 7.1 to validate it and extract the payload.
1. セクション 7.1 で定義されているように SD-JWT を処理して検証し、ペイロードを抽出します。
2. Ensure that the contents of claims in the payload are acceptable (depending on the application; for example, check that any values the Holder can check are correct).
2. ペイロード内のクレームの内容が受け入れられることを確認します (アプリケーションによって異なります。たとえば、所有者が確認できる値が正しいかどうかを確認します)。
For presentation to a Verifier, the Holder MUST perform the following (or equivalent) steps (in addition to the checks described in Section 7.1 performed after receiving the SD-JWT):
検証者に提示する場合、所有者は、(SD-JWT を受信した後に実行されるセクション 7.1 で説明されているチェックに加えて) 以下の (または同等の) ステップを実行しなければなりません。
1. Decide which Disclosures to release to the Verifier, obtaining consent if necessary (note that if and how consent is attained is out of scope for this document).
1. 必要に応じて同意を得て、どの開示を検証者に公開するかを決定します (同意を取得するかどうか、および取得する方法はこの文書の範囲外であることに注意してください)。
2. Verify that each selected Disclosure satisfies one of the two following conditions:
2. 選択した各開示が次の 2 つの条件のいずれかを満たしていることを確認します。
a. The hash of the Disclosure is contained in the Issuer-signed JWT claims.
a. 開示のハッシュは、発行者が署名した JWT クレームに含まれています。
b. The hash of the Disclosure is contained in the claim value of another selected Disclosure.
b. 開示のハッシュは、選択した別の開示のクレーム値に含まれています。
3. Assemble the SD-JWT, including the Issuer-signed JWT and the selected Disclosures (see Section 4 for the format).
3. 発行者が署名した JWT と選択した開示情報を含む SD-JWT をアセンブルします (形式についてはセクション 4 を参照)。
4. If Key Binding is not required:
4. キーバインドが必要ない場合:
a. Send the SD-JWT to the Verifier.
a. SD-JWT を検証者に送信します。
5. If Key Binding is required:
5. キーバインドが必要な場合:
a. Create a Key Binding JWT tied to the SD-JWT.
a. SD-JWT に関連付けられたキー バインディング JWT を作成します。
b. Assemble the SD-JWT+KB by concatenating the SD-JWT and the Key Binding JWT.
b. SD-JWT とキー バインディング JWT を連結して、SD-JWT+KB をアセンブルします。
c. Send the SD-JWT+KB to the Verifier.
c. SD-JWT+KB を検証者に送信します。
Upon receiving a presentation from a Holder, in the form of either an SD-JWT or an SD-JWT+KB, in addition to the checks described in Section 7.1, Verifiers need to ensure that
SD-JWT または SD-JWT+KB の形式で所有者からプレゼンテーションを受け取ると、セクション 7.1 で説明されているチェックに加えて、検証者は次のことを確認する必要があります。
* if Key Binding is required, then the Holder has provided an SD-JWT+KB, and
* キー バインディングが必要な場合、所有者は SD-JWT+KB を提供しており、
* the Key Binding JWT is signed by the Holder and valid.
* キー バインディング JWT は所有者によって署名されており、有効です。
To this end, Verifiers MUST follow the following steps (or equivalent):
この目的を達成するために、検証者は次の手順 (または同等の手順) に従わなければなりません。
1. Determine if Key Binding is to be checked according to the Verifier's policy for the use case at hand. This decision MUST NOT be based on whether or not a Key Binding JWT is provided by the Holder. Refer to Section 9.5 for details.
1. 現在のユースケースに対する検証者のポリシーに従って、キー バインディングをチェックするかどうかを決定します。この決定は、キー バインディング JWT が所有者によって提供されるかどうかに基づいてはなりません (MUST NOT)。詳細については、セクション 9.5 を参照してください。
2. If Key Binding is required and the Holder has provided an SD-JWT (without Key Binding), the Verifier MUST reject the presentation.
2. キー バインディングが必要で、所有者が SD-JWT (キー バインディングなし) を提供した場合、検証者はプレゼンテーションを拒否しなければなりません (MUST)。
3. If the Holder has provided an SD-JWT+KB, parse it into an SD-JWT and a Key Binding JWT.
3. 所有者が SD-JWT+KB を提供した場合、それを SD-JWT とキー バインディング JWT に解析します。
4. Process the SD-JWT as defined in Section 7.1 to validate the presentation and extract the payload.
4. セクション 7.1 で定義されているように SD-JWT を処理して、プレゼンテーションを検証し、ペイロードを抽出します。
5. If Key Binding is required:
5. キーバインドが必要な場合:
a. Determine the public key for the Holder from the SD-JWT (see Section 4.1.2).
a. SD-JWT からホルダーの公開鍵を決定します (セクション 4.1.2 を参照)。
b. Ensure that a signing algorithm was used that was deemed secure for the application. Refer to [RFC8725], Sections 3.1 and 3.2 for details. The "none" algorithm MUST NOT be accepted.
b. アプリケーションにとって安全であるとみなされる署名アルゴリズムが使用されていることを確認してください。詳細については、[RFC8725] のセクション 3.1 および 3.2 を参照してください。「なし」アルゴリズムは受け入れてはなりません。
c. Validate the signature over the Key Binding JWT per Section 5.2 of [RFC7515].
c. [RFC7515] のセクション 5.2 に従って、キー バインディング JWT 上の署名を検証します。
d. Check that the typ of the Key Binding JWT is kb+jwt (see Section 4.3).
d. キー バインディング JWT のタイプが kb+jwt であることを確認します (セクション 4.3 を参照)。
e. Check that the creation time of the Key Binding JWT, as determined by the iat claim, is within an acceptable window.
e. iat クレームによって決定されるキー バインディング JWT の作成時間が許容範囲内であることを確認します。
f. Determine that the Key Binding JWT is bound to the current transaction and was created for this Verifier (replay detection) by validating nonce and aud claims.
f. nonce クレームと aud クレームを検証することで、キー バインディング JWT が現在のトランザクションにバインドされており、この Verifier (リプレイ検出) 用に作成されたことを確認します。
g. Calculate the digest over the Issuer-signed JWT and Disclosures as defined in Section 4.3.1 and verify that it matches the value of the sd_hash claim in the Key Binding JWT.
g. セクション 4.3.1 で定義されているように、発行者が署名した JWT と開示に対してダイジェストを計算し、それがキー バインディング JWT の sd_hash クレームの値と一致することを確認します。
h. Check that the Key Binding JWT is a valid JWT in all other respects, per [RFC7519] and [RFC8725].
h. [RFC7519] および [RFC8725] に従って、キー バインディング JWT が他のすべての点で有効な JWT であることを確認してください。
If any step fails, the presentation is not valid and processing MUST be aborted.
いずれかのステップが失敗した場合、プレゼンテーションは無効となり、処理は中止されなければなりません。
Otherwise, the Processed SD-JWT Payload can be passed to the application to be used for the intended purpose.
それ以外の場合は、処理された SD-JWT ペイロードをアプリケーションに渡して、意図した目的に使用できます。
This section describes an alternative format for SD-JWTs and SD-JWT+KBs using the JWS JSON Serialization from [RFC7515]. Supporting this format is OPTIONAL.
このセクションでは、[RFC7515] の JWS JSON シリアル化を使用した SD-JWT および SD-JWT+KB の代替形式について説明します。この形式のサポートはオプションです。
For both the General and Flattened JSON Serialization, the SD-JWT or SD-JWT+KB is represented as a JSON object according to Section 7.2 of [RFC7515]. The following new unprotected header parameters are defined:
一般およびフラット化された JSON シリアル化の両方で、SD-JWT または SD-JWT+KB は、[RFC7515] のセクション 7.2 に従って JSON オブジェクトとして表されます。次の新しい保護されていないヘッダー パラメーターが定義されています。
disclosures:
開示:
An array of strings where each element is an individual Disclosure as described in Section 4.2.
セクション 4.2 で説明されているように、各要素が個別の開示である文字列の配列。
kb_jwt:
kb_jwt:
Present only in an SD-JWT+KB, the Key Binding JWT as described in Section 4.3.
SD-JWT+KB (セクション 4.3 で説明されているキー バインディング JWT) にのみ存在します。
In an SD-JWT+KB, kb_jwt MUST be present when using the JWS JSON Serialization, and the digest in the sd_hash claim MUST be computed over the SD-JWT as described in Section 4.3.1. This means that even when using the JWS JSON Serialization, the representation as a regular SD-JWT Compact Serialization MUST be created temporarily to calculate the digest. In detail, the SD-JWT Compact Serialization part is built by concatenating the protected header, the payload, and the signature of the JWS JSON serialized SD-JWT using a . character as a separator, and using the Disclosures from the disclosures member of the unprotected header.
SD-JWT+KB では、JWS JSON シリアル化を使用するときに kb_jwt が存在しなければならず、セクション 4.3.1 で説明されているように sd_hash クレームのダイジェストが SD-JWT 上で計算されなければなりません (MUST)。これは、JWS JSON シリアル化を使用する場合でも、ダイジェストを計算するために通常の SD-JWT コンパクト シリアル化としての表現を一時的に作成する必要があることを意味します。詳細には、SD-JWT コンパクト シリアル化部分は、保護されたヘッダー、ペイロード、および JWS JSON でシリアル化された SD-JWT の署名を を使用して連結することによって構築されます。文字を区切り文字として使用し、保護されていないヘッダーの Disclosures メンバーからの Disclosures を使用します。
Unprotected headers other than disclosures are not covered by the digest, and therefore, as usual, are not protected against tampering.
開示以外の保護されていないヘッダーはダイジェストの対象外であるため、通常どおり改ざんから保護されません。
In the case of Flattened JSON Serialization, there is only one unprotected header.
フラット化された JSON シリアル化の場合、保護されていないヘッダーは 1 つだけです。
The following is a non-normative example of a JWS JSON serialized SD-JWT as issued using the Flattened JSON Serialization:
以下は、フラット化された JSON シリアル化を使用して発行された JWS JSON シリアル化された SD-JWT の非標準的な例です。
{
"header": {
"disclosures": [
"WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN1YiIsICJqb2huX2RvZV80M
iJd",
"WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiSm9ob
iJd",
"WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIkRvZ
SJd",
"WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImJpcnRoZGF0ZSIsICIxOTQwL
TAxLTAxIl0"
]
},
"payload": "eyJfc2QiOiBbIjRIQm42YUlZM1d0dUdHV1R4LXFVajZjZGs2V0JwWn
lnbHRkRmF2UGE3TFkiLCAiOHNtMVFDZjAyMXBObkhBQ0k1c1A0bTRLWmd5Tk9PQV
ljVGo5SE5hQzF3WSIsICJjZ0ZkaHFQbzgzeFlObEpmYWNhQ2FhN3VQOVJDUjUwVk
U1UjRMQVE5aXFVIiwgImpNQ1hWei0tOWI4eDM3WWNvRGZYUWluencxd1pjY2NmRl
JCQ0ZHcWRHMm8iXSwgImlzcyI6ICJodHRwczovL2lzc3Vlci5leGFtcGxlLmNvbS
IsICJpYXQiOiAxNjgzMDAwMDAwLCAiZXhwIjogMTg4MzAwMDAwMCwgIl9zZF9hbG
ciOiAic2hhLTI1NiIsICJjbmYiOiB7Imp3ayI6IHsia3R5IjogIkVDIiwgImNydi
I6ICJQLTI1NiIsICJ4IjogIlRDQUVSMTladnUzT0hGNGo0VzR2ZlNWb0hJUDFJTG
lsRGxzN3ZDZUdlbWMiLCAieSI6ICJaeGppV1diWk1RR0hWV0tWUTRoYlNJaXJzVm
Z1ZWNDRTZ0NGpUOUYySFpRIn19fQ",
"protected":
"eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0",
"signature": "3oOtvPxU3QdDWUmfGexVB5rWyON2f1atg5rL825bvvD1g7ywjKDK
y2UHqHoH2QS4FA99JbG5qnlqFaGXFChfjQ"
}
The following is an SD-JWT+KB with two Disclosures:
以下は、2 つの開示情報を含む SD-JWT+KB です。
{
"header": {
"disclosures": [
"WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIkRvZ
SJd",
"WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiSm9ob
iJd"
],
"kb_jwt": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dCJ9.eyJub25j
ZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaWVyLmV4YW
1wbGUub3JnIiwgImlhdCI6IDE3NDg1MzcyNDQsICJzZF9oYXNoIjogIlZqdFBz
Z1pwUVRSeEtKdkRwU0otblhsWktFOVo5TGdENEZ5Q3d3b05NUncifQ.GrDvJ2j
hYNmUvqdwVEIrxeTFEuI5qKSM7I6P95JmA6Wko-FBB5vPGQn0wvmdgjLCE2iDR
h1r82zchjmABQ3V8w"
},
"payload": "eyJfc2QiOiBbIjRIQm42YUlZM1d0dUdHV1R4LXFVajZjZGs2V0JwWn
lnbHRkRmF2UGE3TFkiLCAiOHNtMVFDZjAyMXBObkhBQ0k1c1A0bTRLWmd5Tk9PQV
ljVGo5SE5hQzF3WSIsICJjZ0ZkaHFQbzgzeFlObEpmYWNhQ2FhN3VQOVJDUjUwVk
U1UjRMQVE5aXFVIiwgImpNQ1hWei0tOWI4eDM3WWNvRGZYUWluencxd1pjY2NmRl
JCQ0ZHcWRHMm8iXSwgImlzcyI6ICJodHRwczovL2lzc3Vlci5leGFtcGxlLmNvbS
IsICJpYXQiOiAxNjgzMDAwMDAwLCAiZXhwIjogMTg4MzAwMDAwMCwgIl9zZF9hbG
ciOiAic2hhLTI1NiIsICJjbmYiOiB7Imp3ayI6IHsia3R5IjogIkVDIiwgImNydi
I6ICJQLTI1NiIsICJ4IjogIlRDQUVSMTladnUzT0hGNGo0VzR2ZlNWb0hJUDFJTG
lsRGxzN3ZDZUdlbWMiLCAieSI6ICJaeGppV1diWk1RR0hWV0tWUTRoYlNJaXJzVm
Z1ZWNDRTZ0NGpUOUYySFpRIn19fQ",
"protected":
"eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0",
"signature": "3oOtvPxU3QdDWUmfGexVB5rWyON2f1atg5rL825bvvD1g7ywjKDK
y2UHqHoH2QS4FA99JbG5qnlqFaGXFChfjQ"
}
In the case of General JSON Serialization, there are multiple unprotected headers (one per signature). If present, disclosures and kb_jwt MUST be included in the first unprotected header and MUST NOT be present in any following unprotected headers.
一般的な JSON シリアル化の場合、保護されていないヘッダーが複数存在します (署名ごとに 1 つ)。存在する場合、開示と kb_jwt は最初の保護されていないヘッダーに含まれなければならず、その後の保護されていないヘッダーには存在してはなりません。
The following is a non-normative example of a presentation of a JWS JSON serialized SD-JWT, including a Key Binding JWT using the General JSON Serialization:
以下は、一般的な JSON シリアル化を使用したキー バインディング JWT を含む、JWS JSON シリアル化された SD-JWT のプレゼンテーションの非規範的な例です。
{
"payload": "eyJfc2QiOiBbIjRIQm42YUlZM1d0dUdHV1R4LXFVajZjZGs2V0JwWn
lnbHRkRmF2UGE3TFkiLCAiOHNtMVFDZjAyMXBObkhBQ0k1c1A0bTRLWmd5Tk9PQV
ljVGo5SE5hQzF3WSIsICJjZ0ZkaHFQbzgzeFlObEpmYWNhQ2FhN3VQOVJDUjUwVk
U1UjRMQVE5aXFVIiwgImpNQ1hWei0tOWI4eDM3WWNvRGZYUWluencxd1pjY2NmRl
JCQ0ZHcWRHMm8iXSwgImlzcyI6ICJodHRwczovL2lzc3Vlci5leGFtcGxlLmNvbS
IsICJpYXQiOiAxNjgzMDAwMDAwLCAiZXhwIjogMTg4MzAwMDAwMCwgIl9zZF9hbG
ciOiAic2hhLTI1NiIsICJjbmYiOiB7Imp3ayI6IHsia3R5IjogIkVDIiwgImNydi
I6ICJQLTI1NiIsICJ4IjogIlRDQUVSMTladnUzT0hGNGo0VzR2ZlNWb0hJUDFJTG
lsRGxzN3ZDZUdlbWMiLCAieSI6ICJaeGppV1diWk1RR0hWV0tWUTRoYlNJaXJzVm
Z1ZWNDRTZ0NGpUOUYySFpRIn19fQ",
"signatures": [
{
"header": {
"disclosures": [
"WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgI
kRvZSJd",
"WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiS
m9obiJd"
],
"kid": "issuer-key-1",
"kb_jwt": "eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dCJ9.eyJu
b25jZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodHRwczovL3ZlcmlmaW
VyLmV4YW1wbGUub3JnIiwgImlhdCI6IDE3NDg1MzcyNDQsICJzZF9oYXNo
IjogInFieUlXUDNwaFZneEVzRFJpd2R3OVc2QkozZHhpUEx1bWNZcFBidT
RFYjgifQ.VyZqxaVHh1XE6M-kuax_7Laq42uFDrx17lLG2jluyKgy_PqC8
5z4DVpISdMZDdSANGs-0zN2N7xnM-E1Pg0sOw"
},
"protected":
"eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0",
"signature": "dz1N3uvhVHJjldyXwppmBLieTj0vuBMbzL06rnrLIuxEQb9B
HoIOwGrWh-UadW4orRpEiEtjf7xyHDONMJ6tBw"
},
{
"header": {
"kid": "issuer-key-2"
},
"protected":
"eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0",
"signature": "kuXio_U88RH_-fihAPET4AFUjj0BpxsT6yddMFIr6pfHKtAe
0FOJNWQxU42rfnORuNQNTgGsf2A8LjEba5inNg"
}
]
}
Verification of the JWS JSON serialized SD-JWT follows the rules defined in Section 3.4, except for the following aspects:
JWS JSON シリアル化 SD-JWT の検証は、次の点を除き、セクション 3.4 で定義されたルールに従います。
* The SD-JWT or SD-JWT+KB does not need to be split into component parts and the Disclosures can be found in the disclosures member of the unprotected header.
* SD-JWT または SD-JWT+KB をコンポーネント部分に分割する必要はなく、開示情報は保護されていないヘッダーの開示メンバー内にあります。
* To verify the digest in sd_hash in the Key Binding JWT of an SD-JWT+KB, the Verifier MUST assemble the string to be hashed as described in Section 8.1.
* SD-JWT+KB のキー バインディング JWT 内の sd_hash のダイジェストを検証するには、検証者はセクション 8.1 で説明されているようにハッシュされる文字列をアセンブルしなければなりません (MUST)。
The security considerations help achieve the following properties:
セキュリティに関する考慮事項は、次の特性を実現するのに役立ちます。
Selective Disclosure:
選択的開示:
An adversary in the role of the Verifier cannot obtain information from an SD-JWT about any claim name or claim value that was not explicitly disclosed by the Holder unless that information can be derived from other disclosed claims or sources other than the presented SD-JWT.
検証者の役割を持つ敵対者は、提示された SD-JWT 以外の他の開示されたクレームまたはソースから情報を導き出すことができない限り、所有者によって明示的に開示されていないクレーム名またはクレーム値に関する情報を SD-JWT から取得することはできません。
Integrity:
誠実さ：
A malicious Holder cannot modify names or values of selectively disclosable claims without detection by the Verifier.
悪意のある所有者は、検証者による検出なしに、選択的に開示可能なクレームの名前や値を変更することはできません。
Additionally, as described in Section 9.5, the application of Key Binding can ensure that the presenter of an SD-JWT credential is the Holder of the credential.
さらに、セクション 9.5 で説明されているように、キー バインディングを適用すると、SD-JWT 資格情報の提示者が資格情報の所有者であることを保証できます。
The JWT MUST be signed by the Issuer to protect the integrity of the issued claims. An attacker can modify or add claims if this JWT is not signed (e.g., change the "email" attribute to take over the victim's account or add an attribute indicating a fake academic qualification).
発行されたクレームの整合性を保護するために、JWT は発行者によって署名されなければなりません。この JWT が署名されていない場合、攻撃者はクレームを変更または追加することができます (例: 「電子メール」属性を変更して被害者のアカウントを乗っ取る、または偽の学歴を示す属性を追加する)。
The Verifier MUST always check the signature of the Issuer-signed JWT to ensure that it has not been tampered with since its issuance. The Issuer-signed JWT MUST be rejected if the signature cannot be verified.
検証者は、発行者が署名した JWT の署名を常にチェックして、発行以降に改ざんされていないことを確認しなければなりません (MUST)。署名が検証できない場合、発行者が署名した JWT は拒否されなければなりません (MUST)。
The security of the Issuer-signed JWT depends on the security of the signature algorithm. Per the last paragraph of Section 5.2 of [RFC7515], it is an application-specific decision to choose the appropriate JWS algorithm from [JWS.Algs], including post-quantum algorithms, when they are ready.
発行者署名付き JWT のセキュリティは、署名アルゴリズムのセキュリティに依存します。[RFC7515] のセクション 5.2 の最後の段落に従って、ポスト量子アルゴリズムを含む適切な JWS アルゴリズムを、準備ができたときに [JWS.Algs] から選択するかどうかは、アプリケーション固有の決定となります。
Holders can manipulate the Disclosures by changing the values of the claims before sending them to the Verifier. The Verifier MUST check the Disclosures to ensure that the values of the claims are correct, i.e., the digests of the Disclosures are actually present in the signed SD-JWT.
所有者は、検証者に送信する前にクレームの値を変更することで開示を操作できます。検証者は、開示をチェックして、クレームの値が正しいこと、つまり開示のダイジェストが署名された SD-JWT に実際に存在することを確認しなければなりません (MUST)。
A naive Verifier that extracts all claim values from the Disclosures (without checking the hashes) and inserts them into the SD-JWT payload is vulnerable to this attack. However, in a structured SD-JWT, without comparing the digests of the Disclosures, such an implementation could not determine the correct place in a nested object where a claim needs to be inserted. Therefore, the naive implementation would not only be insecure, but also incorrect.
開示情報からすべてのクレーム値を (ハッシュをチェックせずに) 抽出し、SD-JWT ペイロードに挿入する単純な Verifier は、この攻撃に対して脆弱です。ただし、構造化された SD-JWT では、開示のダイジェストを比較しないと、そのような実装では、クレームを挿入する必要があるネストされたオブジェクト内の正しい場所を決定できません。したがって、単純な実装は安全ではないだけでなく、不正確でもあります。
The steps described in Section 7.3 ensure that the Verifier checks the Disclosures correctly.
セクション 7.3 で説明されている手順により、検証者が開示情報を正しくチェックすることが保証されます。
The security model that conceals the plaintext claims relies on the high entropy random data of the salt as additional input to the hash function. The randomness ensures that the same plaintext claim value does not produce the same digest value. It also makes it infeasible to guess the preimage of the digest (thereby learning the plaintext claim value) by enumerating the potential value space for a claim into the hash function to search for a matching digest value. It is therefore vitally important that unrevealed salts cannot be learned or guessed, even if other salts have been revealed. As such, each salt MUST be created in such a manner that it is cryptographically random, sufficiently long, and has high enough entropy that it is infeasible to guess. A new salt MUST be chosen for each claim independently of other salts. See "Randomness Requirements for Security" [RFC4086] for considerations on generating random values.
平文の主張を隠蔽するセキュリティ モデルは、ハッシュ関数への追加入力としてソルトの高エントロピーのランダム データに依存します。ランダム性により、同じ平文クレーム値が同じダイジェスト値を生成しないことが保証されます。また、クレームの潜在的な値空間をハッシュ関数に列挙して一致するダイジェスト値を検索することにより、ダイジェストの事前イメージを推測する (これにより平文のクレーム値を学習する) ことも不可能になります。したがって、たとえ他の塩が明らかになったとしても、未公開の塩を学習したり推測したりできないことが非常に重要です。したがって、各ソルトは、暗号的にランダムで、十分に長く、推測不可能なほど十分に高いエントロピーを持つような方法で作成されなければなりません。新しい塩は、他の塩とは独立して、各請求項に対して選択されなければなりません。ランダム値の生成に関する考慮事項については、「セキュリティのためのランダム性要件」[RFC4086] を参照してください。
The RECOMMENDED minimum length of the randomly generated portion of the salt is 128 bits.
ソルトのランダムに生成された部分の推奨される最小長は 128 ビットです。
The Issuer MUST ensure that a new salt value is chosen for each claim, including when the same claim name occurs at different places in the structure of the SD-JWT. This can be seen in the example in Appendix A.2, where multiple claims with the name type appear, but each of them has a different salt.
発行者は、SD-JWT の構造内の異なる場所で同じクレーム名が出現する場合も含めて、クレームごとに新しいソルト値が選択されることを保証しなければなりません (MUST)。これは、付録 A.2 の例で見ることができます。type という名前の複数のクレームが表示されますが、それぞれに異なるソルトがあります。
To ensure privacy of claims that are selectively disclosable but are not being disclosed in a given presentation, the hash function MUST ensure that it is infeasible to calculate any portion of the three elements (salt, claim name, claim value) from a particular digest. This implies the hash function MUST be preimage resistant and should also not allow an observer to infer any partial information about the undisclosed content. In the terminology of cryptographic commitment schemes, the hash function needs to be computationally hiding.
選択的に開示可能であるが、特定のプレゼンテーションでは開示されていないクレームのプライバシーを確保するために、ハッシュ関数は、特定のダイジェストから 3 つの要素 (ソルト、クレーム名、クレーム値) のどの部分も計算できないことを保証しなければなりません (MUST)。これは、ハッシュ関数がプリイメージ耐性を持たなければならず、また、観察者が未公開のコンテンツに関する部分的な情報を推測できるようにすべきではないことを意味します。暗号化コミットメント スキームの用語では、ハッシュ関数は計算によって隠蔽される必要があります。
To ensure the integrity of selectively disclosable claims, the hash function MUST be second-preimage resistant. That is, for any combination of salt, claim name, and claim value, it is infeasible to find a different combination of salt, claim name, and claim value that results in the same digest.
選択的に開示可能なクレームの完全性を保証するために、ハッシュ関数は二次プリイメージ耐性を持たなければなりません。つまり、ソルト、クレーム名、クレーム値のどのような組み合わせでも、同じダイジェストが得られるソルト、クレーム名、クレーム値の異なる組み合わせを見つけることは不可能です。
The hash function SHOULD also be collision resistant. Although not essential to the anticipated uses of SD-JWT, without collision resistance an Issuer may be able to find multiple Disclosures that have the same hash value. In which case, the signature over the SD-JWT would not then commit the Issuer to the contents of the JWT. The collision resistance of the hash function used to generate digests SHOULD match the collision resistance of the hash function used by the signature scheme. For example, use of the ES512 signature algorithm would require a Disclosure hash function with at least 256-bit collision resistance, such as SHA-512.
ハッシュ関数も衝突耐性を持つべきです(SHOULD)。SD-JWT の予想される用途には必須ではありませんが、衝突耐性がなければ、発行者は同じハッシュ値を持つ複数の開示情報を見つけることができる可能性があります。この場合、SD-JWT 上の署名は発行者を JWT のコンテンツにコミットしません。ダイジェストの生成に使用されるハッシュ関数の衝突耐性は、署名スキームで使用されるハッシュ関数の衝突耐性と一致する必要があります (SHOULD)。たとえば、ES512 署名アルゴリズムを使用するには、SHA-512 など、少なくとも 256 ビットの耐衝突性を持つ開示ハッシュ関数が必要です。
Inclusion in the "Named Information Hash Algorithm Registry" [Hash.Algs] alone does not indicate a hash algorithm's suitability for use in SD-JWT (it contains several heavily truncated digests, such as sha-256-32 and sha-256-64, which are unfit for security applications).
「Named Information Hash Algorithm Registry」[Hash.Algs] に含まれていることだけでは、ハッシュ アルゴリズムが SD-JWT での使用に適していることを示すものではありません (これには、セキュリティ アプリケーションには適さない、sha-256-32 や sha-256-64 など、大幅に切り詰められたダイジェストがいくつか含まれています)。
Key Binding aims to ensure that the presenter of an SD-JWT credential is actually the Holder of the credential. An SD-JWT compatible with Key Binding contains a public key, or a reference to a public key, that corresponds to a private key possessed by the Holder. The Verifier requires that the Holder prove possession of that private key when presenting the SD-JWT credential.
キー バインディングは、SD-JWT 資格情報の提示者が実際に資格情報の所有者であることを確認することを目的としています。Key Binding と互換性のある SD-JWT には、Holder が所有する秘密鍵に対応する公開鍵、または公開鍵への参照が含まれています。検証者は、SD-JWT 資格情報を提示するときに、所有者がその秘密キーの所有を証明することを要求します。
Without Key Binding, a Verifier only gets the proof that the credential was issued by a particular Issuer, but the credential itself can be replayed by anyone who gets access to it. This means that, for example, after the credential was leaked to an attacker, the attacker can present the credential to any Verifier that does not require a binding. Also, a malicious Verifier to which the Holder presented the credential can present the credential to another Verifier if that other Verifier does not require Key Binding.
キー バインドを使用しない場合、検証者は資格情報が特定の発行者によって発行されたという証拠のみを取得しますが、資格情報自体は、それにアクセスできる誰でも再生できます。これは、たとえば、認証情報が攻撃者に漏洩した後、攻撃者はバインディングを必要としない検証者に認証情報を提示できることを意味します。また、所有者が資格情報を提示した悪意のある検証者は、他の検証者がキー バインドを必要としない場合、その資格情報を別の検証者に提示することができます。
Verifiers MUST decide whether Key Binding is required for a particular use case before verifying a credential. This decision can be informed by various factors including but not limited to the following: business requirements, the use case, the type of binding between a Holder and its credential that is required for a use case, the sensitivity of the use case, the expected properties of a credential, the type and contents of other credentials expected to be presented at the same time, etc.
検証者は、資格情報を検証する前に、特定のユースケースにキー バインディングが必要かどうかを判断しなければなりません (MUST)。この決定は、ビジネス要件、ユース ケース、ユース ケースに必要なホルダーとその資格情報の間のバインディングの種類、ユース ケースの機密性、資格情報の予期されるプロパティ、同時に提示されることが予想される他の資格情報の種類と内容などを含むがこれらに限定されないさまざまな要因によって通知されます。
It is important that a Verifier not make its security policy decisions based on data that can be influenced by an attacker. For this reason, when deciding whether or not Key Binding is required, Verifiers MUST NOT take into account whether the Holder has provided an SD-JWT+KB or a bare SD-JWT; otherwise, an attacker could strip the KB-JWT from an SD-JWT+KB and present the resultant SD-JWT.
検証者は、攻撃者の影響を受ける可能性のあるデータに基づいてセキュリティ ポリシーを決定しないことが重要です。このため、キー バインディングが必要かどうかを決定する際、検証者は所有者が SD-JWT+KB を提供したか、裸の SD-JWT を提供したかを考慮してはなりません (MUST NOT)。そうしないと、攻撃者が SD-JWT+KB から KB-JWT を剥ぎ取り、その結果として得られる SD-JWT を提示する可能性があります。
Furthermore, Verifiers should be aware that Key Binding information may have been added to an SD-JWT in a format that they do not recognize and therefore may not be able to tell whether or not the SD-JWT supports Key Binding.
さらに、検証者は、キー バインディング情報が認識できない形式で SD-JWT に追加されている可能性があるため、SD-JWT がキー バインディングをサポートしているかどうかを判断できない可能性があることに注意する必要があります。
If a Verifier determines that Key Binding is required for a particular use case and the Holder presents either a bare SD-JWT or an SD-JWT+KB with an invalid Key Binding JWT, then the Verifier will reject the presentation when following the verification steps described in Section 7.3.
検証者が特定のユースケースにはキーバインディングが必要であると判断し、所有者がベア SD-JWT または無効なキーバインディング JWT を含む SD-JWT+KB を提示した場合、検証者はセクション 7.3 で説明されている検証手順に従うと提示を拒否します。
SD-JWT ensures that names of claims that are selectively disclosable are always concealed unless the claim's value is disclosed. This prevents an attacker from learning the names of such claims. However, the names of the claims that are permanently disclosed are not hidden. This includes the keys of objects that themselves are not concealed, but contain concealed claims. This limitation needs to be taken into account by Issuers when creating the structure of the SD-JWT.
SD-JWT は、選択的に開示可能なクレームの名前が、クレームの価値が開示されない限り常に隠蔽されることを保証します。これにより、攻撃者がそのようなクレームの名前を知ることができなくなります。ただし、永久に開示されるクレームの名前は隠蔽されません。これには、それ自体は隠蔽されていないが、隠蔽されたクレームを含むオブジェクトのキーが含まれます。発行者は SD-JWT の構造を作成するときに、この制限を考慮する必要があります。
An Issuer MUST NOT allow any content to be selectively disclosable that is critical for evaluating the SD-JWT's authenticity or validity. The exact list of such content will depend on the application and SHOULD be listed by any application-specific profiles of SD-JWT. The following is a list of registered JWT claim names that SHOULD be considered as security critical:
発行者は、SD-JWT の信頼性または有効性を評価するために重要なコンテンツを選択的に開示できるようにしてはなりません (MUST NOT)。このようなコンテンツの正確なリストはアプリケーションによって異なり、SD-JWT のアプリケーション固有のプロファイルによってリストされるべきです (SHOULD)。以下は、セキュリティ上重要であるとみなされるべき、登録済みの JWT クレーム名のリストです。
* iss (Issuer)
* iss (発行者)
* aud (Audience), although issuers MAY allow individual entries in the array to be selectively disclosable
* aud (対象者)、ただし発行者は配列内の個々のエントリを選択的に開示できるようにしてもよい (MAY)
* exp (Expiration Time)
* exp (有効期限)
* nbf (Not Before)
* nbf (以前ではない)
* cnf (Confirmation Key)
* cnf (確認キー)
Issuers will typically include claims controlling the validity of the SD-JWT in plaintext in the SD-JWT payload, but there is no guarantee they will do so. Therefore, Verifiers cannot reliably depend on that and need to operate as though security-critical claims might be selectively disclosable.
通常、発行者は SD-JWT の有効性を制御するクレームを SD-JWT ペイロードに平文で含めますが、そうするという保証はありません。したがって、検証者はそれに確実に依存することができず、セキュリティ クリティカルなクレームが選択的に開示可能であるかのように動作する必要があります。
Verifiers therefore MUST ensure that all claims they deem necessary for checking the validity of an SD-JWT in the given context are present (or disclosed, respectively) during validation of the SD-JWT. This is implemented in the last step of the verification defined in Section 7.1.
したがって、検証者は、SD-JWT の検証中に、特定のコンテキストにおける SD-JWT の有効性をチェックするために必要と思われるすべてのクレームが存在する (またはそれぞれ開示される) ことを保証しなければなりません (MUST)。これは、セクション 7.1 で定義された検証の最後のステップで実装されます。
The precise set of required validity claims will typically be defined by operating environment rules, an application-specific profile, or the credential format, and MAY include claims other than those listed herein.
必要な有効性クレームの正確なセットは、通常、動作環境ルール、アプリケーション固有のプロファイル、または資格情報の形式によって定義され、ここにリストされているもの以外のクレームを含めてもよい(MAY)。
This specification does not define how signature verification keys of Issuers are distributed to Verifiers. However, it is RECOMMENDED that Issuers publish their keys in a way that allows for efficient and secure key rotation and revocation, for example, by publishing keys at a predefined location using the JSON Web Key Set (JWKS) format [RFC7517]. Verifiers need to ensure that they are not using expired or revoked keys for signature verification using reasonable and appropriate means for the given key-distribution method.
この仕様は、発行者の署名検証キーが検証者に配布される方法を定義しません。ただし、発行者は、たとえば、JSON Web Key Set (JWKS) 形式 [RFC7517] を使用して事前定義された場所で鍵を公開するなど、効率的かつ安全な鍵のローテーションと失効を可能にする方法で鍵を公開することが推奨されます。検証者は、指定されたキー配布方法に適した合理的かつ適切な手段を使用して、署名検証に期限切れまたは失効したキーを使用していないことを確認する必要があります。
Any entity in possession of an SD-JWT (including an SD-JWT extracted from an SD-JWT+KB) can forward it to any third party that does not enforce Key Binding. When doing so, that entity may remove Disclosures such that the receiver learns only a subset of the claims contained in the original SD-JWT.
SD-JWT (SD-JWT+KB から抽出された SD-JWT を含む) を所有するエンティティは、キー バインドを強制しないサード パーティに SD-JWT を転送できます。そうするとき、そのエンティティは、受信者が元の SD-JWT に含まれるクレームのサブセットのみを学習するように、開示を削除する場合があります。
For example, a device manufacturer might produce an SD-JWT containing information about upstream and downstream supply chain contributors. Each supply chain party can verify only the claims that were selectively disclosed to them by an upstream party, and they can choose to further reduce the disclosed claims when presenting to a downstream party.
たとえば、デバイス メーカーは、上流および下流のサプライ チェーンの貢献者に関する情報を含む SD-JWT を作成する場合があります。各サプライチェーン当事者は、上流当事者によって選択的に開示されたクレームのみを検証でき、下流当事者に提示するときに、開示されたクレームをさらに減らすことを選択できます。
In some scenarios, this behavior could be desirable; if it is not, Issuers need to support and Verifiers need to enforce Key Binding.
シナリオによっては、この動作が望ましい場合もあります。そうでない場合、発行者はキー バインドをサポートし、検証者はキー バインドを強制する必要があります。
With an SD-JWT, the Issuer-signed JWT is integrity protected by the Issuer's signature, and the values of the Disclosures are integrity protected by the digests included therein. The specific set of Disclosures, however, is not integrity protected; the SD-JWT can be modified by adding or removing Disclosures and still be valid.
SD-JWT では、発行者の署名付き JWT は発行者の署名によって完全性が保護され、開示の値はそこに含まれるダイジェストによって完全性が保護されます。ただし、特定の開示セットは完全性が保護されていません。SD-JWT は開示情報を追加または削除することで変更でき、引き続き有効です。
With an SD-JWT+KB, the set of selected Disclosures is integrity protected. The signature in the Key Binding JWT covers a specific SD-JWT, with a specific Issuer-signed JWT and a specific set of Disclosures. Thus, the signature on the Key Binding JWT, in addition to proving Key Binding, also assures the authenticity and integrity of the set of Disclosures the Holder disclosed. The set of Disclosures in an SD-JWT+KB is the set that the Holder intended to send; no intermediate party has added, removed, or modified the list of Disclosures.
SD-JWT+KB を使用すると、選択した開示セットの整合性が保護されます。キー バインディング JWT の署名は、特定の発行者署名付き JWT および特定の開示セットを含む特定の SD-JWT をカバーします。したがって、キー バインディング JWT 上の署名は、キー バインディングを証明するだけでなく、所有者が開示した一連の開示の信頼性と完全性も保証します。SD-JWT+KB 内の一連の開示情報は、保有者が送信することを意図したセットです。中間当事者は開示リストを追加、削除、または変更していません。
Section 3.11 of [RFC8725] describes the use of explicit typing as one mechanism to prevent confusion attacks (described in Section 2.8 of [RFC8725]) in which one kind of JWT is mistaken for another. SD-JWTs are also potentially subject to such confusion attacks, so in the absence of other techniques, it is RECOMMENDED that application profiles of SD-JWT specify an explicit type by including the typ header parameter when the SD-JWT is issued, and that Verifiers check this value.
[RFC8725] のセクション 3.11 では、ある種類の JWT を別の種類と取り違える混乱攻撃 ([RFC8725] のセクション 2.8 で説明) を防ぐメカニズムの 1 つとして、明示的型付けの使用について説明しています。SD-JWT もこのような混乱攻撃を受ける可能性があるため、他の技術がない場合、SD-JWT の発行時に typ ヘッダー パラメーターを含めることで SD-JWT のアプリケーション プロファイルに明示的な型を指定し、検証者がこの値をチェックすることが推奨されます。
When explicit typing using the typ header is employed for an SD-JWT, it is RECOMMENDED that a media type name of the format "application/ example+sd-jwt" be used, where "example" is replaced by the identifier for the specific kind of SD-JWT. The definition of typ in Section 4.1.9 of [RFC7515] recommends that the "application/" prefix be omitted, so "example+sd-jwt" would be the value of the typ header parameter.
typ ヘッダーを使用した明示的な型指定が SD-JWT に採用される場合、「application/ example+sd-jwt」形式のメディア タイプ名を使用することが推奨されます。ここで、「example」は特定の種類の SD-JWT の識別子に置き換えられます。[RFC7515] のセクション 4.1.9 の typ の定義では、「application/」プレフィックスを省略することが推奨されているため、「example+sd-jwt」が typ ヘッダー パラメータの値になります。
Use of the cty content type header parameter to indicate the content type of the SD-JWT payload can also be used to distinguish different types of JSON objects or different kinds of JWT Claim Sets.
SD-JWT ペイロードのコンテンツ タイプを示す cty コンテンツ タイプ ヘッダー パラメーターの使用は、さまざまな種類の JSON オブジェクトまたはさまざまな種類の JWT クレーム セットを区別するためにも使用できます。
Implementations of SD-JWT rely on asymmetric cryptographic keys and must therefore ensure that key pair generation, handling, storage, and lifecycle management are performed securely.
SD-JWT の実装は非対称暗号キーに依存しているため、キー ペアの生成、処理、保管、ライフサイクル管理が安全に実行されることを保証する必要があります。
While the specific mechanisms for secure key management are out of scope for this document, implementers should follow established best practices, such as those outlined in NIST SP 800-57 Part 1 [NIST.SP.800-57pt1r5]. This includes:
安全な鍵管理のための特定のメカニズムはこの文書の範囲外ですが、実装者は、NIST SP 800-57 Part 1 [NIST.SP.800-57pt1r5] で概説されているものなど、確立されたベスト プラクティスに従う必要があります。これには以下が含まれます。
* Secure Generation: Using cryptographically secure methods and random number generators.
* 安全な生成: 暗号的に安全な方法と乱数生成器を使用します。
* Secure Storage: Protecting private keys from unauthorized access.
* 安全なストレージ: 秘密キーを不正アクセスから保護します。
* Lifecycle Management: Ensuring secure key rotation, revocation, and disposal as needed.
* ライフサイクル管理: 必要に応じて、安全なキーのローテーション、失効、廃棄を保証します。
Appropriate key management is essential, as any compromise can lead to unauthorized disclosure or forgery of SD-JWTs.
侵害があれば SD-JWT の不正開示や偽造につながる可能性があるため、適切なキー管理が不可欠です。
Unlinkability is a property whereby adversaries are prevented from correlating credential presentations of the same user beyond the user's consent. Without unlinkability, an adversary might be able to learn more about the user than the user intended to disclose, for example:
リンク解除性は、敵対者がユーザーの同意を超えて同じユーザーの資格情報の提示を関連付けることができないようにする特性です。リンクを解除できないと、攻撃者はユーザーが開示しようとしていた以上にユーザーについて知ることができる可能性があります。たとえば、次のとおりです。
* Cooperating Verifiers might want to track users across services to build advertising profiles.
* 協力する検証者は、広告プロファイルを構築するためにサービス全体でユーザーを追跡したい場合があります。
* Issuers might want to track where users present their credentials to enable surveillance.
* 発行者は、監視を有効にするために、ユーザーが認証情報を提示する場所を追跡したい場合があります。
* After a data breach at multiple Verifiers, publicly available information might allow linking identifiable information presented to Verifier A with originally anonymous information presented to Verifier B, therefore revealing the identities of users of Verifier B.
* 複数の検証者でデータ侵害が発生した後、公開されている情報により、検証者 A に提示された識別可能な情報と検証者 B に提示された元々匿名の情報とのリンクが許可される可能性があり、その結果、検証者 B のユーザーの身元が明らかになります。
The following types of unlinkability are discussed below:
次の種類のリンク解除可能性については、以下で説明します。
* Presentation Unlinkability: A Verifier should not be able to link two presentations of the same credential.
* プレゼンテーションのリンク不可能性: 検証者は、同じ資格情報の 2 つのプレゼンテーションをリンクできてはなりません。
* Verifier/Verifier Unlinkability: The presentations made to two different Verifiers should not reveal that the same credential was presented (e.g., if the two Verifiers collude, or if they are forced by a third party to reveal the presentations made to them, or data leaks from one Verifier to the other).
* 検証者/検証者のリンク不可能性: 2 つの異なる検証者に対して行われたプレゼンテーションは、同じ資格情報が提示されたことを明らかにすべきではありません (たとえば、2 つの検証者が共謀した場合、第三者によって行われたプレゼンテーションを明らかにするよう強制された場合、または一方の検証者から他方の検証者にデータが漏洩した場合)。
* Issuer/Verifier Unlinkability (Honest Verifier): An Issuer of a credential should not be able to know that a user presented this credential unless the Verifier is sharing presentation data with the Issuer accidentally, deliberately, or because it is forced to do so.
* 発行者/検証者のリンク不可能性 (正直な検証者): 認証情報の発行者は、検証者が偶然、意図的に、または強制的に提示データを発行者と共有しない限り、ユーザーがこの認証情報を提示したことを知ることができません。
* Issuer/Verifier Unlinkability (Careless/Colluding/Compromised/ Coerced Verifier): >An Issuer of a credential should under no circumstances be able to tell that a user presented this credential to a certain Verifier. In particular, this includes cases when the Verifier accidentally or deliberately shares presentation data with the Issuer or is forced to do so.
* 発行者/検証者のリンク不可能性 (不注意/共謀/侵害/強制された検証者): > 資格情報の発行者は、いかなる状況においても、ユーザーがこの資格情報を特定の検証者に提示したことを知ることができてはなりません。特に、これには、検証者が偶然または意図的にプレゼンテーション データを発行者と共有した場合、またはそうすることを強制された場合が含まれます。
In all cases, unlinkability is limited to cases where the disclosed claims do not contain information that directly or indirectly identifies the user. For example, when a taxpayer identification number is contained in the disclosed claims, the Issuer and Verifier can easily link the user's transactions. However, when the user only discloses a birthdate to one Verifier and a postal code to another Verifier, the two Verifiers should not be able to determine that they were interacting with the same user.
いずれの場合も、リンク解除は、開示された請求項にユーザーを直接的または間接的に特定する情報が含まれていない場合に限定されます。たとえば、開示された請求項に納税者識別番号が含まれている場合、発行者と検証者はユーザーの取引を簡単に結び付けることができます。ただし、ユーザーが 1 人の検証者に生年月日を公開し、別の検証者に郵便番号のみを公開した場合、2 つの検証者は同じユーザーと対話していたと判断できません。
Issuer/Verifier unlinkability with a careless, colluding, compromised, or coerced Verifier cannot be achieved in salted hash-based selective disclosure approaches, such as SD-JWT, as the issued credential with the Issuer's signature is directly presented to the Verifier, who can forward it to the Issuer. To reduce the risk of revealing the data later on, Section 10.2 defines requirements to reduce the amount of data stored.
不注意、共謀、侵害、または強要された検証者との発行者と検証者のリンクの解除は、SD-JWT などのソルテッド ハッシュ ベースの選択的開示アプローチでは実現できません。これは、発行者の署名が付いた発行された資格情報が検証者に直接提示され、検証者がそれを発行者に転送できるためです。後でデータが漏洩するリスクを軽減するために、セクション 10.2 では、保存されるデータの量を減らすための要件を定義しています。
In considering Issuer/Verifier unlinkability, it is important to note the potential for an asymmetric power dynamic between Issuers and Verifiers. This dynamic can compel an otherwise Honest Verifier into collusion. For example, a governmental Issuer might have the authority to mandate that a Verifier report back information about the credentials presented to it. Legal requirements could further enforce this, explicitly undermining Issuer/Verifier unlinkability. Similarly, a large service provider issuing credentials might implicitly pressure Verifiers into collusion by incentivizing participation in their larger operating environment. Deployers of SD-JWT must be aware of these potential power dynamics, mitigate them as much as possible, and/or make the risks transparent to the user.
発行者と検証者の非リンク性を検討する際には、発行者と検証者の間で非対称な力関係が生じる可能性があることに留意することが重要です。この力関係により、本来は正直な検証者が共謀を強いられる可能性があります。たとえば、政府発行者は、提示された資格情報に関する情報を検証者に報告するよう義務付ける権限を持っている場合があります。法的要件によりこれがさらに強化され、発行者と検証者の非リンク性が明らかに損なわれる可能性があります。同様に、資格情報を発行する大規模なサービス プロバイダーは、大規模な運用環境への参加を奨励することで、検証者に暗黙的に圧力をかけて共謀させる可能性があります。SD-JWT の導入者は、これらの潜在的な電力関係を認識し、可能な限り緩和し、リスクをユーザーに透過的にする必要があります。
Contrary to that, Issuer/Verifier unlinkability with an Honest Verifier can generally be achieved. However, a callback from the Verifier to the Issuer, such as a revocation check, could potentially disclose information about the credential's usage to the Issuer. Where such callbacks are necessary, they need to be executed in a manner that preserves privacy and does not disclose details about the credential to the Issuer (the mechanism described in [TSL] is an example of an approach that discloses minimal information towards the Issuer). It is important to note that the timing of such requests could potentially serve as a side channel.
それとは対照的に、発行者/検証者と正直な検証者とのリンク解除は、一般に実現できます。ただし、失効チェックなどの検証者から発行者へのコールバックにより、資格情報の使用法に関する情報が発行者に開示される可能性があります。このようなコールバックが必要な場合、プライバシーを保護し、発行者に資格情報の詳細を開示しない方法で実行する必要があります ([TSL] で説明されているメカニズムは、発行者に対して最小限の情報を開示するアプローチの一例です)。このようなリクエストのタイミングがサイドチャネルとして機能する可能性があることに注意することが重要です。
Verifier/Verifier unlinkability and presentation unlinkability can be achieved using batch issuance: A batch of credentials based on the same claims is issued to the Holder instead of just a single credential. The Holder can then use a different credential for each Verifier or even for each session with a Verifier. New Key Binding keys and salts MUST be used for each credential in the batch to ensure that the Verifiers cannot link the credentials using these values. Likewise, claims carrying time information, like iat, exp, and nbf, MUST either be randomized within a time period considered appropriate (e.g., randomize iat within the last 24 hours and calculate exp accordingly) or rounded (e.g., rounded down to the beginning of the day).
検証者/検証者のリンク解除およびプレゼンテーションのリンク解除は、バッチ発行を使用して実現できます。単一の資格情報ではなく、同じクレームに基づく資格情報のバッチが所有者に発行されます。その後、所有者は検証者ごとに、または検証者とのセッションごとに異なる資格情報を使用できます。検証者がこれらの値を使用して資格情報をリンクできないようにするために、バッチ内の各資格情報に新しいキー バインディング キーとソルトを使用する必要があります。同様に、iat、exp、nbf などの時間情報を含むクレームは、適切と考えられる期間内でランダム化するか (たとえば、過去 24 時間以内に iat をランダム化し、それに応じて exp を計算する)、または四捨五入する (たとえば、一日の初めまで切り捨てる) 必要があります。
SD-JWT only conceals the value of claims that are not revealed. It does not meet the security properties for anonymous credentials [CL01]. In particular, colluding Verifiers and Issuers can know when they have seen the same credential no matter what fields have been disclosed, even when none have been disclosed. This behavior may not align with what users naturally anticipate or are guided to expect from user-interface interactions, potentially causing them to make decisions they might not otherwise make. Workarounds such as batch issuance, as described above, help with keeping Verifiers from linking different presentations, but cannot work for Issuer/Verifier unlinkability. This issue applies to all salted hash-based approaches, including mDL/mDoc [ISO.18013-5] and SD-CWT [SD-CWT].
SD-JWT は、明らかにされていないクレームの価値を隠蔽するだけです。匿名資格情報 [CL01] のセキュリティ プロパティを満たしていません。特に、共謀している検証者と発行者は、どのフィールドが開示されているかに関係なく、たとえ何も開示されていない場合でも、同じ資格情報をいつ見たかを知ることができます。この動作は、ユーザーがユーザー インターフェイスの操作から自然に期待すること、またはユーザー インターフェイスの操作から期待するように導かれていることと一致しない可能性があり、他の方法では行わないような決定を下す原因となる可能性があります。前述のバッチ発行などの回避策は、検証者が異なるプレゼンテーションをリンクしないようにするのに役立ちますが、発行者と検証者のリンクが解除された場合には機能しません。この問題は、mDL/mDoc [ISO.18013-5] や SD-CWT [SD-CWT] を含む、すべてのソルテッド ハッシュ ベースのアプローチに当てはまります。
Wherever user data is stored, it represents a potential target for an attacker. This target can be of particularly high value when the data is signed by a trusted authority like an official national identity service. For example, in OpenID Connect [OpenID.Core], signed ID Tokens can be stored by Relying Parties. In the case of SD-JWT, Holders have to store SD-JWTs, and Issuers and Verifiers may decide to do so as well.
ユーザー データが保存されている場所は常に、攻撃者の潜在的なターゲットとなります。この目標は、データが公式の国民 ID サービスなどの信頼できる機関によって署名されている場合に特に価値が高くなります。たとえば、OpenID Connect [OpenID.Core] では、署名付き ID トークンを証明書利用者が保存できます。SD-JWT の場合、保有者は SD-JWT を保存する必要があり、発行者と検証者も同様に保存することを決定できます。
Not surprisingly, a leak of such data risks revealing private data of users to third parties. Signed user data, the authenticity of which can be easily verified by third parties, further exacerbates the risk. As discussed in Section 9.5, leaked SD-JWTs may also allow attackers to impersonate Holders unless Key Binding is enforced and the attacker does not have access to the Holder's cryptographic keys.
当然のことですが、そのようなデータが漏洩すると、ユーザーの個人データが第三者に公開される危険があります。署名されたユーザーデータは、その信頼性が第三者によって簡単に検証されるため、リスクがさらに悪化します。セクション 9.5 で説明したように、キー バインドが強制され、攻撃者がホルダーの暗号キーにアクセスできない限り、漏洩した SD-JWT により攻撃者がホルダーになりすますことができる可能性があります。
Due to these risks, and the risks described in Section 10.1, systems implementing SD-JWT SHOULD be designed to minimize the amount of data that is stored. All involved parties SHOULD NOT store SD-JWTs longer than strictly necessary, including in log files.
これらのリスク、およびセクション 10.1 で説明されているリスクのため、SD-JWT を実装するシステムは、保存されるデータの量を最小限に抑えるように設計される必要があります。すべての関係者は、ログ ファイルも含め、厳密に必要な期間を超えて SD-JWT を保存すべきではありません。
After Issuance, Issuers SHOULD NOT store the Issuer-signed JWT or the respective Disclosures.
発行後、発行者は発行者が署名した JWT またはそれぞれの開示情報を保存すべきではありません。
Holders SHOULD store SD-JWTs only in encrypted form, and, wherever possible, use hardware-backed encryption in particular for the private Key Binding key. Decentralized storage of data, e.g., on user devices, SHOULD be preferred for user credentials over centralized storage. Expired SD-JWTs SHOULD be deleted as soon as possible.
所有者は、SD-JWT を暗号化された形式でのみ保存し、可能な限り、特に秘密キー バインディング キーにはハードウェアによる暗号化を使用する必要があります (SHOULD)。ユーザー資格情報については、集中ストレージよりも、ユーザーデバイスなどのデータの分散ストレージを優先すべきです(SHOULD)。期限切れの SD-JWT はできるだけ早く削除すべきです。
After Verification, Verifiers SHOULD NOT store the Issuer-signed JWT or the respective Disclosures. It may be sufficient to store the result of the verification and any user data that is needed for the application.
検証後、検証者は発行者が署名した JWT またはそれぞれの開示情報を保存すべきではありません。検証の結果とアプリケーションに必要なユーザー データを保存するだけで十分な場合があります。
Exceptions from the rules above can be made if there are strong requirements to do so (e.g., functional requirements or legal audit requirements), secure storage can be ensured, and the privacy impact has been assessed.
強力な要件 (機能要件や法的監査要件など) があり、安全なストレージが確保でき、プライバシーへの影響が評価されている場合は、上記のルールからの例外を設けることができます。
If an SD-JWT or SD-JWT+KB is transmitted over an insecure channel during issuance or presentation, an adversary may be able to intercept and read the user's personal data or correlate the information with previous uses.
SD-JWT または SD-JWT+KB が発行または提示中に安全でないチャネル経由で送信されると、敵対者がユーザーの個人データを傍受して読み取ったり、情報を以前の使用と関連付けたりできる可能性があります。
Usually, transport protocols for issuance and presentation of credentials are designed to protect the confidentiality of the transmitted data, for example, by requiring the use of TLS.
通常、資格情報の発行および提示のためのトランスポート プロトコルは、たとえば TLS の使用を要求することによって、送信データの機密性を保護するように設計されています。
This specification therefore considers the confidentiality of the data to be provided by the transport protocol and does not specify any encryption mechanism.
したがって、この仕様では、トランスポート プロトコルによって提供されるデータの機密性が考慮されており、暗号化メカニズムは指定されていません。
Implementers MUST ensure that the transport protocol provides confidentiality if the privacy of user data or correlation attacks by passive observers are a concern.
ユーザーデータのプライバシーやパッシブオブザーバーによる相関攻撃が懸念される場合、実装者はトランスポートプロトコルが機密性を提供することを保証しなければなりません(MUST)。
To encrypt an SD-JWT or SD-JWT+KB during transit over potentially insecure or leakage-prone channels, implementers MAY use JSON Web Encryption (JWE) [RFC7516], encapsulating the SD-JWT or SD-JWT+KB as the plaintext payload of the JWE. Especially, when an SD-JWT is transmitted via a URL and information may be stored/cached in the browser or end up in web server logs, the SD-JWT SHOULD be encrypted using JWE.
潜在的に安全でない、または漏洩が起こりやすいチャネルでの転送中に SD-JWT または SD-JWT+KB を暗号化するために、実装者は JSON Web Encryption (JWE) [RFC7516] を使用して、SD-JWT または SD-JWT+KB を JWE の平文ペイロードとしてカプセル化してもよい(MAY)。特に、SD-JWT が URL 経由で送信され、情報がブラウザーに保存/キャッシュされるか、Web サーバーのログに記録される可能性がある場合、SD-JWT は JWE を使用して暗号化されるべきです(SHOULD)。
The use of decoy digests is RECOMMENDED when the number of claims (or the existence of particular claims) can be a side channel disclosing information about otherwise undisclosed claims. In particular, if a claim in an SD-JWT is present only if a certain condition is met (e.g., a membership number is only contained if the user is a member of a group), the Issuer SHOULD add decoy digests when the condition is not met.
クレームの数（または特定のクレームの存在）が、他の方法では開示されていないクレームに関する情報を開示するサイドチャネルとなる可能性がある場合には、おとりダイジェストの使用が推奨されます。特に、特定の条件が満たされた場合にのみ SD-JWT 内のクレームが存在する場合 (たとえば、ユーザーがグループのメンバーである場合にのみ会員番号が含まれる)、発行者は、条件が満たされない場合におとりダイジェストを追加すべきです(SHOULD)。
Decoy digests increase the size of the SD-JWT. The number of decoy digests (or whether to use them at all) is a trade-off between the size of the SD-JWT and the privacy of the user's data.
デコイ ダイジェストにより、SD-JWT のサイズが増加します。おとりダイジェストの数 (または、おとりダイジェストを使用するかどうか) は、SD-JWT のサイズとユーザー データのプライバシーとの間のトレードオフです。
An Issuer issuing only one type of SD-JWT might have privacy implications, because if the Holder has an SD-JWT issued by that Issuer, its type and claim names can be determined.
発行者が 1 種類の SD-JWT のみを発行すると、プライバシーに影響を及ぼす可能性があります。これは、所有者がその発行者によって発行された SD-JWT を所有している場合、その種類とクレーム名が特定される可能性があるためです。
For example, if a cancer research institute only issued SD-JWTs with cancer registry information, it is possible to deduce that the Holder owning its SD-JWT is a cancer patient.
たとえば、がん研究機関ががん登録情報を含む SD-JWT のみを発行した場合、SD-JWT を所有する保有者はがん患者であると推定できます。
Moreover, the Issuer identifier alone may reveal information about the user.
さらに、発行者識別子だけでもユーザーに関する情報が明らかになる可能性があります。
For example, when a military organization or a drug rehabilitation center issues a vaccine credential, Verifiers can deduce that the Holder is a military member or may have a substance use disorder.
たとえば、軍事組織または麻薬リハビリテーションセンターがワクチン証明書を発行すると、検証者は、その保有者が軍関係者であるか、または薬物使用障害を患っている可能性があると推測できます。
To mitigate this issue, a group of issuers may elect to use a common Issuer identifier. A group signature scheme outside the scope of this specification may also be used, instead of an individual signature.
この問題を軽減するために、発行者のグループは共通の発行者識別子の使用を選択する場合があります。個別の署名の代わりに、この仕様の範囲外のグループ署名スキームを使用することもできます。
IANA has registered the following Claims in the "JSON Web Token Claims" registry [JWT.Claims] established by [RFC7519].
IANA は、[RFC7519] によって確立された「JSON Web Token Claims」レジストリ [JWT.Claims] に以下のクレームを登録しました。
Claim Name:
クレーム名:
_sd
_sd
Claim Description:
クレームの説明:
Digests of Disclosures for object properties
オブジェクトのプロパティに関する開示のダイジェスト
Change Controller:
コントローラを変更します:
IETF
IETF
Specification Document(s):
仕様書:
Section 4.2.4.1 of RFC 9901
RFC 9901 のセクション 4.2.4.1
Claim Name:
クレーム名:
...
...
Claim Description:
クレームの説明:
Digest of the Disclosure for an array element
配列要素の開示のダイジェスト
Change Controller:
コントローラを変更します:
IETF
IETF
Specification Document(s):
仕様書:
Section 4.2.4.2 of RFC 9901
RFC 9901 のセクション 4.2.4.2
Claim Name:
クレーム名:
_sd_alg
_sd_alg
Claim Description:
クレームの説明:
Hash algorithm used to generate Disclosure digests and digest over presentation
開示ダイジェストとプレゼンテーション上のダイジェストの生成に使用されるハッシュ アルゴリズム
Change Controller:
コントローラを変更します:
IETF
IETF
Specification Document(s):
仕様書:
Section 4.1.1 of RFC 9901
RFC 9901 のセクション 4.1.1
Claim Name:
クレーム名:
sd_hash
sd_ハッシュ
Claim Description:
クレームの説明:
Digest of the SD-JWT to which the KB-JWT is tied
KB-JWT が関連付けられている SD-JWT のダイジェスト
Change Controller:
コントローラを変更します:
IETF
IETF
Specification Document(s):
仕様書:
Section 4.3 of RFC 9901
RFC 9901 のセクション 4.3
IANA has registered the following media types [RFC2046] in the "Media Types" registry [MediaTypes] in the manner described in [RFC6838].
IANA は、[RFC6838] で説明されている方法で、次のメディア タイプ [RFC2046] を「メディア タイプ」レジストリ [MediaTypes] に登録しました。
Note: For the media type value used in the typ header in the Issuer-signed JWT itself, see Section 9.11.
注: 発行者署名付き JWT 自体の typ ヘッダーで使用されるメディア タイプの値については、セクション 9.11 を参照してください。
To indicate that the content is an SD-JWT:
コンテンツが SD-JWT であることを示すには、次のようにします。
Type name:
型名:
application
応用
Subtype name:
サブタイプ名:
sd-jwt
SD-JWT
Required parameters:
必須パラメータ:
n/a
該当なし
Optional parameters:
オプションのパラメータ:
n/a
該当なし
Encoding considerations:
エンコーディングに関する考慮事項:
binary; application/sd-jwt values are a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') and tilde ('~') characters.
バイナリ;application/sd-jwt 値は、ピリオド (「.」) とチルダ (「~」) 文字で区切られた一連の Base64url エンコード値 (一部は空の文字列である場合があります) です。
Security considerations:
セキュリティに関する考慮事項:
See the Security Considerations sections of RFC 9901, [RFC7519], and [RFC8725].
RFC 9901、[RFC7519]、および [RFC8725] のセキュリティに関する考慮事項のセクションを参照してください。
Interoperability considerations:
相互運用性に関する考慮事項:
n/a
該当なし
Published specification:
公開された仕様:
RFC 9901
RFC 9901
Applications that use this media type:
このメディア タイプを使用するアプリケーション:
Applications requiring selective disclosure of integrity-protected content.
完全性が保護されたコンテンツの選択的な開示を必要とするアプリケーション。
Fragment identifier considerations:
フラグメント識別子の考慮事項:
n/a
該当なし
Additional information:
追加情報：
Magic number(s):
マジックナンバー:
n/a
該当なし
File extension(s):
ファイル拡張子:
n/a
該当なし
Macintosh file type code(s):
Macintosh ファイルタイプコード:
n/a
該当なし
Person & email address to contact for further information:
詳細についての連絡先の担当者と電子メール アドレス:
Daniel Fett, mail@danielfett.de
ダニエル・フェット、mail@danielfett.de
Intended usage:
使用目的:
COMMON
一般
Restrictions on usage:
使用上の制限:
none
なし
Author:
著者：
Daniel Fett, mail@danielfett.de
ダニエル・フェット、mail@danielfett.de
Change Controller:
コントローラを変更します:
IETF
IETF
To indicate that the content is a JWS JSON serialized SD-JWT:
コンテンツが JWS JSON でシリアル化された SD-JWT であることを示すには、次のようにします。
Type name:
型名:
application
応用
Subtype name:
サブタイプ名:
sd-jwt+json
SD-JWT+JSON
Required parameters:
必須パラメータ:
n/a
該当なし
Optional parameters:
オプションのパラメータ:
n/a
該当なし
Encoding considerations:
エンコーディングに関する考慮事項:
binary; application/sd-jwt+json values are represented as a JSON Object.
バイナリ;application/sd-jwt+json 値は JSON オブジェクトとして表されます。
Security considerations:
セキュリティに関する考慮事項:
See the Security Considerations sections of RFC 9901 and [RFC7515].
RFC 9901 および [RFC7515] の「セキュリティに関する考慮事項」セクションを参照してください。
Interoperability considerations:
相互運用性に関する考慮事項:
n/a
該当なし
Published specification:
公開された仕様:
RFC 9901
RFC 9901
Applications that use this media type:
このメディア タイプを使用するアプリケーション:
Applications requiring selective disclosure of content protected by ETSI JAdES compliant signatures.
ETSI JAdES 準拠の署名によって保護されたコンテンツの選択的開示を必要とするアプリケーション。
Fragment identifier considerations:
フラグメント識別子の考慮事項:
n/a
該当なし
Additional information:
追加情報：
Magic number(s):
マジックナンバー:
n/a
該当なし
File extension(s):
ファイル拡張子:
n/a
該当なし
Macintosh file type code(s):
Macintosh ファイルタイプコード:
n/a
該当なし
Person & email address to contact for further information:
詳細についての連絡先の担当者と電子メール アドレス:
Daniel Fett, mail@danielfett.de
ダニエル・フェット、mail@danielfett.de
Intended usage:
使用目的:
COMMON
一般
Restrictions on usage:
使用上の制限:
none
なし
Author:
著者：
Daniel Fett, mail@danielfett.de
ダニエル・フェット、mail@danielfett.de
Change Controller:
コントローラを変更します:
IETF
IETF
To indicate that the content is a Key Binding JWT:
コンテンツがキー バインディング JWT であることを示すには、次のようにします。
Type name:
型名:
application
応用
Subtype name:
サブタイプ名:
kb+jwt
kb+jwt
Required parameters:
必須パラメータ:
n/a
該当なし
Optional parameters:
オプションのパラメータ:
n/a
該当なし
Encoding considerations:
エンコーディングに関する考慮事項:
binary; A Key Binding JWT is a JWT; JWT values are encoded as a series of base64url-encoded values separated by period ('.') characters.
バイナリ;キー バインディング JWT は JWT です。JWT 値は、ピリオド (「.」) 文字で区切られた一連の Base64URL エンコード値としてエンコードされます。
Security considerations:
セキュリティに関する考慮事項:
See the Security Considerations sections of RFC 9901, [RFC7519], and [RFC8725].
RFC 9901、[RFC7519]、および [RFC8725] のセキュリティに関する考慮事項のセクションを参照してください。
Interoperability considerations:
相互運用性に関する考慮事項:
n/a
該当なし
Published specification:
公開された仕様:
RFC 9901
RFC 9901
Applications that use this media type:
このメディア タイプを使用するアプリケーション:
Applications utilizing a JWT-based proof-of-possession mechanism.
JWT ベースの所有証明メカニズムを利用するアプリケーション。
Fragment identifier considerations:
フラグメント識別子の考慮事項:
n/a
該当なし
Additional information:
追加情報：
Magic number(s):
マジックナンバー:
n/a
該当なし
File extension(s):
ファイル拡張子:
n/a
該当なし
Macintosh file type code(s):
Macintosh ファイルタイプコード:
n/a
該当なし
Person & email address to contact for further information:
詳細についての連絡先の担当者と電子メール アドレス:
Daniel Fett, mail@danielfett.de
ダニエル・フェット、mail@danielfett.de
Intended usage:
使用目的:
COMMON
一般
Restrictions on usage:
使用上の制限:
none
なし
Author:
著者：
Daniel Fett, mail@danielfett.de
ダニエル・フェット、mail@danielfett.de
Change Controller:
コントローラを変更します:
IETF
IETF
IANA has registered "+sd-jwt" in the "Structured Syntax Suffixes" registry [StructuredSuffix] in the manner described in [RFC6838], which can be used to indicate that the media type is encoded as an SD-JWT.
IANA は、[RFC6838] で説明されている方法で、「構造化構文サフィックス」レジストリ [StructuredSuffix] に「+sd-jwt」を登録しました。これは、メディア タイプが SD-JWT としてエンコードされていることを示すために使用できます。
Name:
名前：
SD-JWT
SD-JWT
+suffix:
+接尾辞:
+sd-jwt
+sd-jwt
References:
参考文献:
RFC 9901
RFC 9901
Encoding considerations:
エンコーディングに関する考慮事項:
binary; SD-JWT values are a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') or tilde ('~') characters.
バイナリ;SD-JWT 値は、ピリオド (「.」) またはチルダ (「~」) 文字で区切られた、base64url でエンコードされた一連の値 (一部は空の文字列である場合があります) です。
Interoperability considerations:
相互運用性に関する考慮事項:
n/a
該当なし
Fragment identifier considerations:
フラグメント識別子の考慮事項:
n/a
該当なし
Security considerations:
セキュリティに関する考慮事項:
See the Security Considerations sections of RFC 9901, [RFC7519], and [RFC8725].
RFC 9901、[RFC7519]、および [RFC8725] のセキュリティに関する考慮事項のセクションを参照してください。
Contact:
接触：
Daniel Fett, mail@danielfett.de
ダニエル・フェット、mail@danielfett.de
Author/Change controller:
作成者/変更コントローラー:
IETF
IETF
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<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, January 2013,
<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, May
2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015,
<https://www.rfc-editor.org/info/rfc7516>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
Possession Key Semantics for JSON Web Tokens (JWTs)",
RFC 7800, DOI 10.17487/RFC7800, April 2016,
<https://www.rfc-editor.org/info/rfc7800>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
Current Practices", BCP 225, RFC 8725,
DOI 10.17487/RFC8725, February 2020,
<https://www.rfc-editor.org/info/rfc8725>.
[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, September 2021,
<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, May 2020,
<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", 1 October 2024, <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", 15 December 2023,
<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, November 1996,
<https://www.rfc-editor.org/info/rfc2046>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<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, June 2020,
<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, 20
October 2025, <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, 6 November
2025, <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, 20 October 2025,
<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, May 2025,
<https://www.w3.org/TR/vc-data-model-2.0/>.
The following examples are not normative and are provided for illustrative purposes only. In particular, neither the structure of the claims nor the selection of selectively disclosable claims is normative.
以下の例は規範的なものではなく、説明のみを目的として提供されています。特に、請求項の構造も、選択的に開示可能な請求項の選択も、規範的なものではない。
Line breaks have been added for readability.
読みやすくするために改行が追加されています。
In this example, in contrast to Section 5, the Issuer decided to create a structured object for the address claim, allowing individual members of the claim to be disclosed separately.
この例では、セクション 5 とは対照的に、発行者はアドレス クレームの構造化オブジェクトを作成し、クレームの個々のメンバーを個別に開示できるようにすることにしました。
The following data about the user comprises the input JWT Claims Set used by the Issuer:
ユーザーに関する次のデータは、発行者が使用する入力 JWT クレーム セットを構成します。
{
"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"
}
The Issuer also decided to add decoy digests to prevent the Verifier from deducing the true number of claims.
発行者はまた、検証者が実際のクレーム数を推定できないようにするために、おとりダイジェストを追加することも決定しました。
The following payload is used for the SD-JWT:
次のペイロードが 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"
}
The digests in the SD-JWT payload reference the following Disclosures:
SD-JWT ペイロード内のダイジェストは、次の開示情報を参照しています。
* Claim sub:
* クレームサブ:
- SHA-256 Hash:
- SHA-256 ハッシュ:
X6ZAYOII2vPN40V7xExZwVwz7yRmLNcVwt5DL8RLv4g
X6ZAYOII2vPN40V7xExZwVwz7yRmLNcVwt5DL8RLv4g
- Disclosure:
- 開示：
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN1YiIsICI2YzVjMGE0OS1iNTg 5LTQzMWQtYmFlNy0yMTkxMjJhOWVjMmMiXQ
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN1YiICI2YzVjMGE0OS1iNTg 5LTQzMWQtYmFlNy0yMTkxMjJhOWVjMmMiXQ
- Contents:
- コンテンツ：
["2GLC42sKQveCfGfryNRN9w", "sub", "6c5c0a49-b589-431d-bae7-219122a9ec2c"]
["2GLC42sKQveCfGfryNRN9w"、"サブ"、"6c5c0a49-b589-431d-bae7-219122a9ec2c"]
* Claim given_name:
* 指定された名前を要求します:
- SHA-256 Hash:
- SHA-256 ハッシュ:
ommFAicVT8LGHCB0uywx7fYuo3MHYKO15cz-RZEYM5Q
ommFAicVT8LGHCB0uywx7fYuo3MHYKO15cz-RZEYM5Q
- Disclosure:
- 開示：
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiXHU1OTJ hXHU5MGNlIl0
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiXHU1OTJ hXHU5MGNlIl0
- Contents:
- コンテンツ：
["eluV5Og3gSNII8EYnsxA_A", "given_name", "\u592a\u90ce"]
["eluV5Og3gSNII8EYnsxA_A"、"指定された名前"、"\u592a\u90ce"]
* Claim family_name:
* family_name を主張します:
- SHA-256 Hash:
- SHA-256 ハッシュ:
C9inp6YoRaEXR427zYJP7Qrk1WH_8bdwOA_YUrUnGQU
C9inp6YoRaEXR427zYJP7Qrk1WH_8bdwOA_YurUnGQU
- Disclosure:
- 開示：
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIlx1NWM 3MVx1NzUzMCJd
WyI2SWo3dE0tyTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIlx1NWM 3MVx1NzUzMCJd
- Contents:
- コンテンツ：
["6Ij7tM-a5iVPGboS5tmvVA", "family_name", "\u5c71\u7530"]
["6Ij7tM-a5iVPGboS5tmvVA"、"family_name"、"\u5c71\u7530"]
* Claim email:
* 請求メール:
- SHA-256 Hash:
- SHA-256 ハッシュ:
Kuet1yAa0HIQvYnOVd59hcViO9Ug6J2kSfqYRBeowvE
Kuet1yAa0HIQvYnOVd59hcViO9Ug6J2kSfqYRBeowvE
- Disclosure:
- 開示：
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImVtYWlsIiwgIlwidW51c3VhbCB lbWFpbCBhZGRyZXNzXCJAZXhhbXBsZS5qcCJd
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImVtYWlsIiwgIlwidW51c3VhbCB lbWFpbCBhZGRyZXNzXCJAZXhhbXBsZS5qcCJd
- Contents:
- コンテンツ：
["eI8ZWm9QnKPpNPeNenHdhQ", "email", "\"unusual email address\"@example.jp"]
["eI8ZWm9QnKPpNPeNenHdhQ", "メール", "\"異常なメールアドレス\"@example.jp"]
* Claim phone_number:
* 電話番号を請求してください:
- SHA-256 Hash:
- SHA-256 ハッシュ:
s0BKYsLWxQQeU8tVlltM7MKsIRTrEIa1PkJmqxBBf5U
s0BKYsLWxQQeU8tVlltM7MKsIRTREIa1PkJmqxBBf5U
- Disclosure:
- 開示：
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJlciIsICIrODE tODAtMTIzNC01Njc4Il0
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJlciICIRODE TODATMTIzNC01Njc4Il0
- Contents:
- コンテンツ：
["Qg_O64zqAxe412a108iroA", "phone_number", "+81-80-1234-5678"]
["Qg_O64zqAxe412a108iroA"、"電話番号"、"+81-80-1234-5678"]
* Claim street_address:
* 請求番地番地:
- SHA-256 Hash:
- SHA-256 ハッシュ:
6aUhzYhZ7SJ1kVmagQAO3u2ETN2CC1aHheZpKnaF0_E
6aUhzYhZ7SJ1kVmagQAO3u2ETN2CC1aHheZpKnaF0_E
- Disclosure:
- 開示：
WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInN0cmVldF9hZGRyZXNzIiwgIlx 1Njc3MVx1NGVhY1x1OTBmZFx1NmUyZlx1NTMzYVx1ODI5ZFx1NTE2Y1x1NTcxMl x1ZmYxNFx1NGUwMVx1NzZlZVx1ZmYxMlx1MjIxMlx1ZmYxOCJd
WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInN0cmVldF9hZGRyZXNzIiwgIlx 1Njc3MVx1NGVhY1x1OTBmZFx1NmUyZlx1NTMzYVx1ODI5ZFx1NTE2Y1x1NTcxMlx1ZmYxNFx1NGUwMVx1NzZlZVx1ZmYxMlx1MjIxMlx1ZmYxOCJd
- Contents:
- コンテンツ：
["AJx-095VPrpTtN4QMOqROA", "street_address", "\u6771\u4eac\u90f d\u6e2f\u533a\u829d\u516c\u5712\uff14\u4e01\u76ee\uff12\u2212\u ff18"]
["AJx-095VPrpTtN4QMOqROA", "番地", "\u6771\u4eac\u90f d\u6e2f\u533a\u829d\u516c\u5712\uff14\u4e01\u76ee\uff12\u2212\u ff18"]
* Claim locality:
* 主張の場所:
- SHA-256 Hash:
- SHA-256 ハッシュ:
rvJd6iq6T5ejmsBMoGwuNXh9qAAFATAci40oidEeVsA
rvJd6iq6T5ejmsBMoGwuNXh9qAAFATAci40oidEeVsA
- Disclosure:
- 開示：
WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImxvY2FsaXR5IiwgIlx1Njc3MVx 1NGVhY1x1OTBmZCJd
WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImxvY2FsaXR5IiwgIlx1Njc3MVx 1NGVhY1x1OTBmZCJd
- Contents:
- コンテンツ：
["Pc33JM2LchcU_lHggv_ufQ", "locality", "\u6771\u4eac\u90fd"]
["Pc33JM2LchcU_lHggv_ufQ"、"地域"、"\u6771\u4eac\u90fd"]
* Claim region:
* クレーム領域:
- SHA-256 Hash:
- SHA-256 ハッシュ:
PzzcVu0qbMuBGSjulfewzkesD9zutOExn5EWNwkrQ-k
PzzcVu0qbMuBGSjulfewzkesD9zutOExn5EWNwkrQ-k
- Disclosure:
- 開示：
WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInJlZ2lvbiIsICJcdTZlMmZcdTU zM2EiXQ
WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInJlZ2lvbiISICJcdTZlMmZcdTU zM2EiXQ
- Contents:
- コンテンツ：
["G02NSrQfjFXQ7Io09syajA", "region", "\u6e2f\u533a"]
["G02NSrQfjFXQ7Io09syajA"、"地域"、"\u6e2f\u533a"]
* Claim country:
* 請求国:
- SHA-256 Hash:
- SHA-256 ハッシュ:
uNHoWYhXsZhVJCNE2Dqy-zqt7t69gJKy5QaFv7GrMX4
uNHowYhXsZhVJCNE2Dqy-zqt7t69gJKy5QaFv7GrMX4
- Disclosure:
- 開示：
WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImNvdW50cnkiLCAiSlAiXQ
WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImNvdW50cnkiLCAiSlAiXQ
- Contents:
- コンテンツ：
["lklxF5jMYlGTPUovMNIvCA", "country", "JP"]
["lklxF5jMYlGTPUovMNIvCA", "国", "JP"]
* Claim birthdate:
* 主張の生年月日:
- SHA-256 Hash:
- SHA-256 ハッシュ:
MMldOFFzB2d0umlmpTIaGerhWdU_PpYfLvKhh_f_9aY
MMldOFFzB2d0umlmpTIaGerhWdU_PpYfLvKhh_f_9aY
- Disclosure:
- 開示：
WyJ5eXRWYmRBUEdjZ2wyckk0QzlHU29nIiwgImJpcnRoZGF0ZSIsICIxOTQwLTA xLTAxIl0
WyJ5eXRWYmRBUEdjZ2wyckk0QzlHU29nIiwgImJpcnRoZGF0ZSIsICIxOTQwLTA xLTAxIl0
- Contents:
- コンテンツ：
["yytVbdAPGcgl2rI4C9GSog", "birthdate", "1940-01-01"]
["yytVbdAPGcgl2rI4C9GSog", "生年月日", "1940-01-01"]
The following decoy digests are added:
次のデコイ ダイジェストが追加されます。
* AzLlFobkJ2xiaupREPyoJz-9-NSldB6Cgjr7fUyoHzg
* AzLlFobkJ2xiaupREPyoJz-9-NSldB6Cgjr7fUyoHzg
* cPYJHIZ8Vu-f9CCyVub2UfgEk8jvvXezwK1p_JneeXQ
* cPYJHIZ8Vu-f9CCyVub2UfgEk8jvvXezwK1p_JneeXQ
* glT3hrSU7fSWgwF5UDZmWwBTw32gnUldIhi8hGVCaV4
* glT3hrSU7fSWgwF5UDZmWwBTw32gnUldIhi8hGVCaV4
* b2Dkw0jcIF9rGg8_PF8ZcvncW7zwZj5ryBWvXfrpzek
* b2Dkw0jcIF9rGg8_PF8ZcvncW7zwZj5ryBWvXfrpzek
* fyGp0WTwwPv2JDQln1lSiaeobZsMWA10bQ5989-9DTs
* fyGp0WTwwPv2JDQln1lSiaeobZsMWA10bQ5989-9DTs
* Y34zmIo0QLLOtdMpXGwjBgLvr17yEhhYT0FGofR-aIE
* Y34zmIo0QLLOTdMpXGwjBgLvr17yEhhYT0FGofR-aIE
The following is a presentation of the SD-JWT that discloses only region and country of the address property:
以下は、住所プロパティの地域と国のみを開示する 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~
After validation, the Verifier will have the following Processed SD-JWT Payload available for further handling:
検証後、検証者は次の処理済み SD-JWT ペイロードをさらに処理できるようになります。
{
"iss": "https://issuer.example.com",
"iat": 1683000000,
"exp": 1883000000,
"address": {
"region": "港区",
"country": "JP"
}
}
In this example, an SD-JWT with a complex object is represented. The data structures defined in OpenID Connect for Identity Assurance [OIDC.IDA] are used.
この例では、複雑なオブジェクトを含む SD-JWT が表されています。OpenID Connect for Identity Assurance [OIDC.IDA] で定義されたデータ構造が使用されます。
The Issuer is using the following user data as the input JWT Claims Set:
発行者は、次のユーザー データを入力 JWT クレーム セットとして使用します。
{
"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"
}
The following payload is used for the SD-JWT:
次のペイロードが SD-JWT に使用されます。
{
"_sd": [
"-aSznId9mWM8ocuQolCllsxVggq1-vHW4OtnhUtVmWw",
"IKbrYNn3vA7WEFrysvbdBJjDDU_EvQIr0W18vTRpUSg",
"otkxuT14nBiwzNJ3MPaOitOl9pVnXOaEHal_xkyNfKI"
],
"iss": "https://issuer.example.com",
"iat": 1683000000,
"exp": 1883000000,
"verified_claims": {
"verification": {
"_sd": [
"7h4UE9qScvDKodXVCuoKfKBJpVBfXMF_TmAGVaZe3Sc",
"vTwe3raHIFYgFA3xaUD2aMxFz5oDo8iBu05qKlOg9Lw"
],
"trust_framework": "de_aml",
"evidence": [
{
"...": "tYJ0TDucyZZCRMbROG4qRO5vkPSFRxFhUELc18CSl3k"
}
]
},
"claims": {
"_sd": [
"RiOiCn6_w5ZHaadkQMrcQJf0Jte5RwurRs54231DTlo",
"S_498bbpKzB6Eanftss0xc7cOaoneRr3pKr7NdRmsMo",
"WNA-UNK7F_zhsAb9syWO6IIQ1uHlTmOU8r8CvJ0cIMk",
"Wxh_sV3iRH9bgrTBJi-aYHNCLt-vjhX1sd-igOf_9lk",
"_O-wJiH3enSB4ROHntToQT8JmLtz-mhO2f1c89XoerQ",
"hvDXhwmGcJQsBCA2OtjuLAcwAMpDsaU0nkovcKOqWNE"
]
}
},
"_sd_alg": "sha-256"
}
The digests in the SD-JWT payload reference the following Disclosures:
SD-JWT ペイロード内のダイジェストは、次の開示情報を参照しています。
* Claim time:
* 請求時間:
- SHA-256 Hash:
- SHA-256 ハッシュ:
vTwe3raHIFYgFA3xaUD2aMxFz5oDo8iBu05qKlOg9Lw
vTwe3raHIFYgFA3xaUD2aMxFz5oDo8iBu05qKlOg9Lw
- Disclosure:
- 開示：
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInRpbWUiLCAiMjAxMi0wNC0yM1Q xODoyNVoiXQ
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInRpbWUiLCAiMjAxMi0wNC0yM1Q xODoyNVoiXQ
- Contents:
- コンテンツ：
["2GLC42sKQveCfGfryNRN9w", "time", "2012-04-23T18:25Z"]
["2GLC42sKQveCfGfryNRN9w"、"時間"、"2012-04-23T18:25Z"]
* Claim verification_process:
* 請求の検証_プロセス:
- SHA-256 Hash:
- SHA-256 ハッシュ:
7h4UE9qScvDKodXVCuoKfKBJpVBfXMF_TmAGVaZe3Sc
7h4UE9qScvDKodXVCuoKfKBJpVBfXMF_TmAGVaZe3Sc
- Disclosure:
- 開示：
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgInZlcmlmaWNhdGlvbl9wcm9jZXN zIiwgImYyNGM2Zi02ZDNmLTRlYzUtOTczZS1iMGQ4NTA2ZjNiYzciXQ
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgInZlcmlmaWNhdGlvbl9wcm9jZXN zIiwgImYyNGM2Zi02ZDNmLTRlYzUtczZS1iMGQ4NTA2ZjNiYzciXQ
- Contents:
- コンテンツ：
["eluV5Og3gSNII8EYnsxA_A", "verification_process", "f24c6f-6d3f-4ec5-973e-b0d8506f3bc7"]
["eluV5Og3gSNII8EYnsxA_A"、"検証プロセス"、"f24c6f-6d3f-4ec5-973e-b0d8506f3bc7"]
* Claim type:
* 請求の種類:
- SHA-256 Hash:
- SHA-256 ハッシュ:
G5EnhOAOoU9X_6QMNvzFXjpEA_Rc-AEtm1bG_wcaKIk
G5EnhoOAOoU9X_6QMNvzFXjpEA_Rc-AEtm1bG_wcaKIk
- Disclosure:
- 開示：
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInR5cGUiLCAiZG9jdW1lbnQiXQ
WyI2SWo3dE0tyTVpVlBHYm9TNXRtdlZBIiwgInR5cGUILCAiZG9jdW1lbnQiXQ
- Contents:
- コンテンツ：
["6Ij7tM-a5iVPGboS5tmvVA", "type", "document"]
["6Ij7tM-a5iVPGboS5tmvVA"、"タイプ"、"ドキュメント"]
* Claim method:
* 請求方法:
- SHA-256 Hash:
- SHA-256 ハッシュ:
WpxQ4HSoEtcTmCCKOeDslB_emucYLz2oO8oHNr1bEVQ
WpxQ4HSoEtcTmCCKOeDslB_emucYLz2oO8oHNr1bEVQ
- Disclosure:
- 開示：
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm1ldGhvZCIsICJwaXBwIl0
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm1ldGhvZCIsICJwaXBwIl0
- Contents:
- コンテンツ：
["eI8ZWm9QnKPpNPeNenHdhQ", "method", "pipp"]
["eI8ZWm9QnKPpNPeNenHdhQ"、"メソッド"、"pipp"]
* Claim time:
* 請求時間:
- SHA-256 Hash:
- SHA-256 ハッシュ:
9wpjVPWuD7PK0nsQDL8B06lmdgV3LVybhHydQpTNyLI
9wpjVPWuD7PK0nsQDL8B06lmdgV3LVybhHydQpTNyLI
- Disclosure:
- 開示：
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInRpbWUiLCAiMjAxMi0wNC0yMlQ xMTozMFoiXQ
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInRpbWUiLCAiMjAxMi0wNC0yMlQ xMTozMFoiXQ
- Contents:
- コンテンツ：
["Qg_O64zqAxe412a108iroA", "time", "2012-04-22T11:30Z"]
["Qg_O64zqAxe412a108iroA"、"時間"、"2012-04-22T11:30Z"]
* Claim document:
* 請求書類:
- SHA-256 Hash:
- SHA-256 ハッシュ:
IhwFrWUB63RcZq9yvgZ0XPc7Gowh3O2kqXeBIswg1B4
IhwFrWUB63RcZq9yvgZ0XPc7Gowh3O2kqXeBIswg1B4
- Disclosure:
- 開示：
WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRvY3VtZW50IiwgeyJ0eXBlIjo gImlkY2FyZCIsICJpc3N1ZXIiOiB7Im5hbWUiOiAiU3RhZHQgQXVnc2J1cmciLC AiY291bnRyeSI6ICJERSJ9LCAibnVtYmVyIjogIjUzNTU0NTU0IiwgImRhdGVfb 2ZfaXNzdWFuY2UiOiAiMjAxMC0wMy0yMyIsICJkYXRlX29mX2V4cGlyeSI6ICIy MDIwLTAzLTIyIn1d
WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRvY3VtZW50IiwgeyJ0eXBlIjo gimlkY2FyZCIsICJpc3N1ZXIiOiB7Im5hbWUiOiAiU3RhZHQgQXVnc2J1cmciLCAiY291bnRyeSI6ICJERSJ9LCAibnVtYmVyIjogIjUzNTU0NTU0IiwgImRhdGVfb 2ZfaXNzdWFuY2UiOiAiMjAxMC0wMy0yMyIICJkYXRlX29mX2V4cGlyeSI6ICIyMDIwLTAzLTIyIn1d
- Contents:
- コンテンツ：
["AJx-095VPrpTtN4QMOqROA", "document", {"type": "idcard", "issuer": {"name": "Stadt Augsburg", "country": "DE"}, "number": "53554554", "date_of_issuance": "2010-03-23", "date_of_expiry": "2020-03-22"}]
["AJx-095VPrpTtN4QMOqROA", "文書", {"タイプ": "idcard", "発行者": {"名前": "Stadt Augsburg", "country": "DE"}, "number": "53554554", "発行日": "2010-03-23", "有効期限の日付":"2020-03-22"}]
* Array Entry:
* 配列エントリ:
- SHA-256 Hash:
- SHA-256 ハッシュ:
tYJ0TDucyZZCRMbROG4qRO5vkPSFRxFhUELc18CSl3k
tYJ0TDucyZZCRMbROG4qRO5vkPSFRxFhUELc18CSl3k
- Disclosure:
- 開示：
WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgeyJfc2QiOiBbIjl3cGpWUFd1RDd QSzBuc1FETDhCMDZsbWRnVjNMVnliaEh5ZFFwVE55TEkiLCAiRzVFbmhPQU9vVT lYXzZRTU52ekZYanBFQV9SYy1BRXRtMWJHX3djYUtJayIsICJJaHdGcldVQjYzU mNacTl5dmdaMFhQYzdHb3doM08ya3FYZUJJc3dnMUI0IiwgIldweFE0SFNvRXRj VG1DQ0tPZURzbEJfZW11Y1lMejJvTzhvSE5yMWJFVlEiXX1d
WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgeyJfc2QiOiBbIjl3cGpWUFd1RDd QSzBuc1FETDhCMDZsbWRnVjNMVnliaEh5ZFFwVE55TEkiLCAiRzVFbmhPQU9vVTLYXzZRTU52ekZYanBFQV9SYy1BRXRtMWJHX3djYUtJayISICJJaHdGcldVQjYzUmNacTl5dmdaMFhQYzdHb3doM08ya3FYZUJJc3dnMUI0IiwgIldweFE0SFNvRXRjVG1DQ0tPZURzbEJfZW11Y1lMejJvTzhvSE5yMWJFVlEiXX1d
- Contents:
- コンテンツ：
["Pc33JM2LchcU_lHggv_ufQ", {"_sd": ["9wpjVPWuD7PK0nsQDL8B06lmdgV3LVybhHydQpTNyLI", "G5EnhOAOoU9X_6QMNvzFXjpEA_Rc-AEtm1bG_wcaKIk", "IhwFrWUB63RcZq9yvgZ0XPc7Gowh3O2kqXeBIswg1B4", "WpxQ4HSoEtcTmCCKOeDslB_emucYLz2oO8oHNr1bEVQ"]}]
["Pc33JM2LchcU_lHggv_ufQ", {"_sd": ["9wpjVPWuD7PK0nsQDL8B06lmdgV3LVybhHydQpTNyLI", "G5EnhOAOoU9X_6QMNvzFXjpEA_Rc-AEtm1bG_wcaKIk","IhwFrWUB63RcZq9yvgZ0XPc7Gowh3O2kqXeBIswg1B4", "WpxQ4HSoEtcTmCCKOeDslB_emucYLz2oO8oHNr1bEVQ"]}]
* Claim given_name:
* 指定された名前を要求します:
- SHA-256 Hash:
- SHA-256 ハッシュ:
S_498bbpKzB6Eanftss0xc7cOaoneRr3pKr7NdRmsMo
S_498bbpKzB6Eanftss0xc7cOaoneRr3pKr7NdRmsMo
- Disclosure:
- 開示：
WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdpdmVuX25hbWUiLCAiTWF4Il0
WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdpdmVuX25hbWUiLCAiTWF4Il0
- Contents:
- コンテンツ：
["G02NSrQfjFXQ7Io09syajA", "given_name", "Max"]
["G02NSrQfjFXQ7Io09syajA", "指定された名前", "マックス"]
* Claim family_name:
* family_name を主張します:
- SHA-256 Hash:
- SHA-256 ハッシュ:
Wxh_sV3iRH9bgrTBJi-aYHNCLt-vjhX1sd-igOf_9lk
Wxh_sV3iRH9bgrTBJi-aYHNCLt-vjhX1sd-igOf_9lk
- Disclosure:
- 開示：
WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImZhbWlseV9uYW1lIiwgIk1cdTA wZmNsbGVyIl0
WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImZhbWlseV9uYW1lIiwgIk1cdTA wZmNsbGVyIl0
- Contents:
- コンテンツ：
["lklxF5jMYlGTPUovMNIvCA", "family_name", "M\u00fcller"]
["lklxF5jMYlGTPUovMNIvCA"、"family_name"、"M\u00fller"]
* Claim nationalities:
* 主張する国籍:
- SHA-256 Hash:
- SHA-256 ハッシュ:
hvDXhwmGcJQsBCA2OtjuLAcwAMpDsaU0nkovcKOqWNE
hvDXhwmGcJQsBCA2OtjuLAcwampDsaU0nkovcKOqWNE
- Disclosure:
- 開示：
WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIm5hdGlvbmFsaXRpZXMiLCBbIkR FIl1d
WyJuUHVvUW5rUkZxM0JJZUFTN0FuWEZBIiwgIm5hdGlvbmFsaXRpZXMiLCBbIkR Fil1d
- Contents:
- コンテンツ：
["nPuoQnkRFq3BIeAm7AnXFA", "nationalities", ["DE"]]
["nPuoQnkRFq3BIeAm7AnXFA", "国籍", ["DE"]]
* Claim birthdate:
* 主張の生年月日:
- SHA-256 Hash:
- SHA-256 ハッシュ:
WNA-UNK7F_zhsAb9syWO6IIQ1uHlTmOU8r8CvJ0cIMk
WNA-UNK7F_zhsAb9syWO6IIQ1uHlTmOU8r8CvJ0cIMk
- Disclosure:
- 開示：
WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImJpcnRoZGF0ZSIsICIxOTU2LTA xLTI4Il0
WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImJpcnRoZGF0ZSIsICIxOTU2LTA xLTI4Il0
- Contents:
- コンテンツ：
["5bPs1IquZNa0hkaFzzzZNw", "birthdate", "1956-01-28"]
["5bPs1IquZNa0hkaFzzzZNw"、"生年月日"、"1956-01-28"]
* Claim place_of_birth:
* 出生地を主張する:
- SHA-256 Hash:
- SHA-256 ハッシュ:
RiOiCn6_w5ZHaadkQMrcQJf0Jte5RwurRs54231DTlo
RiOiCn6_w5ZHaadkQMrcQJf0Jte5RwurRs54231DTlo
- Disclosure:
- 開示：
WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgInBsYWNlX29mX2JpcnRoIiwgeyJ jb3VudHJ5IjogIklTIiwgImxvY2FsaXR5IjogIlx1MDBkZXlra3ZhYlx1MDBlNm phcmtsYXVzdHVyIn1d
WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgInBsYWNlX29mX2JpcnRoIwgeyJ jb3VudHJ5IjogIklTIiwgImxvY2FsaXR5IjogIlx1MDBkZXlra3ZhYlx1MDBlNmphcmtsYXVzdHVyIn1d
- Contents:
- コンテンツ：
["5a2W0_NrlEZzfqmk_7Pq-w", "place_of_birth", {"country": "IS", "locality": "\u00deykkvab\u00e6jarklaustur"}]
["5a2W0_NrlEZzfqmk_7Pq-w", "出生地", {"国": "IS", "地域": "\u00deykkvab\u00e6jarklaustur"}]
* Claim address:
* 請求先住所:
- SHA-256 Hash:
- SHA-256 ハッシュ:
_O-wJiH3enSB4ROHntToQT8JmLtz-mhO2f1c89XoerQ
_O-wJiH3enSB4ROHntToQT8JmLtz-mhO2f1c89XoerQ
- Disclosure:
- 開示：
WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImFkZHJlc3MiLCB7ImxvY2FsaXR 5IjogIk1heHN0YWR0IiwgInBvc3RhbF9jb2RlIjogIjEyMzQ0IiwgImNvdW50cn kiOiAiREUiLCAic3RyZWV0X2FkZHJlc3MiOiAiV2VpZGVuc3RyYVx1MDBkZmUgM jIifV0
WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImFkZHJlc3MiLCB7ImxvY2FsaXR 5IjogIk1heHN0YWR0IiwgInBvc3RhbF9jb2RlIjogIjEyMzQ0IiwgImNvdW50cnkiOiAiREUILCAic3RyZWV0X2FkZHJlc3MiOiAiV2VpZGVuc3RyYVx1MDBkZmUgM jiifV0
- Contents:
- コンテンツ：
["y1sVU5wdfJahVdgwPgS7RQ", "address", {"locality": "Maxstadt", "postal_code": "12344", "country": "DE", "street_address": "Weidenstra\u00dfe 22"}]
["y1sVU5wdfJahVdgwPgS7RQ", "住所", {"地域": "マックスシュタット", "郵便番号": "12344", "国": "DE", "番地": "ヴァイデンストラ\u00dfe 22"}]
* Claim birth_middle_name:
* Birth_middle_name を主張します:
- SHA-256 Hash:
- SHA-256 ハッシュ:
otkxuT14nBiwzNJ3MPaOitOl9pVnXOaEHal_xkyNfKI
otkxuT14nBiwzNJ3MPaOitOl9pVnXOaEHal_xkyNfKI
- Disclosure:
- 開示：
WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImJpcnRoX21pZGRsZV9uYW1lIiw gIlRpbW90aGV1cyJd
WyJIYLE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImJpcnRoX21pZGRsZV9uYW1liw gilRpbW90aGV1cyJd
- Contents:
- コンテンツ：
["HbQ4X8srVW3QDxnIJdqyOA", "birth_middle_name", "Timotheus"]
["HbQ4X8srVW3QDxnIJdqyOA"、"birth_middle_name"、"ティモテウス"]
* Claim salutation:
* 主張の挨拶:
- SHA-256 Hash:
- SHA-256 ハッシュ:
-aSznId9mWM8ocuQolCllsxVggq1-vHW4OtnhUtVmWw
-aSznId9mWM8ocuQolCllsxVggq1-vHW4OtnhUtVmWw
- Disclosure:
- 開示：
WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgInNhbHV0YXRpb24iLCAiRHIuIl0
WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgInNhbHV0YXRpb24iLCAirhiuIl0
- Contents:
- コンテンツ：
["C9GSoujviJquEgYfojCb1A", "salutation", "Dr."]
["C9GSoujviJquEgYfojCb1A"、"挨拶"、"博士"]
* Claim msisdn:
* msisdn を要求します:
- SHA-256 Hash:
- SHA-256 ハッシュ:
IKbrYNn3vA7WEFrysvbdBJjDDU_EvQIr0W18vTRpUSg
IKbrYNn3vA7WEFrysvbdBJjDDU_EvQIr0W18vTRpUSg
- Disclosure:
- 開示：
WyJreDVrRjE3Vi14MEptd1V4OXZndnR3IiwgIm1zaXNkbiIsICI0OTEyMzQ1Njc 4OSJd
WyJreDVrjE3Vi14MEptd1V4OXZndnR3IiwgIm1zaXNkbiICI0OTEyMzQ1Njc 4OSJd
- Contents:
- コンテンツ：
["kx5kF17V-x0JmwUx9vgvtw", "msisdn", "49123456789"]
["kx5kF17V-x0JmwUx9vgvtw"、"msisdn"、"49123456789"]
The following is a presentation of the SD-JWT:
以下は 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~
The Verifier will have this Processed SD-JWT Payload available after validation:
検証者は、検証後にこの処理された SD-JWT ペイロードを利用できるようになります。
{
"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"
}
}
}
}
This example shows how the artifacts defined in this specification could be used in the context of SD-JWT-based Verifiable Credentials (SD-JWT VC) [SD-JWT-VC] to represent a hypothetical identity credential with the data of a fictional German citizen.
この例では、この仕様で定義されているアーティファクトを SD-JWT ベースの検証可能な資格情報 (SD-JWT VC) [SD-JWT-VC] のコンテキストでどのように使用して、架空のドイツ国民のデータを含む仮想の ID 資格情報を表すことができるかを示します。
Key Binding is applied using the Holder's public key passed in a cnf claim in the SD-JWT.
キー バインドは、SD-JWT の cnf クレームで渡されたホルダーの公開キーを使用して適用されます。
The following citizen data is the input JWT Claims Set:
次の市民データは入力 JWT クレーム セットです。
{
"vct": "urn:eudi:pid:de:1",
"iss": "https://pid-issuer.bund.de.example",
"given_name": "Erika",
"family_name": "Mustermann",
"birthdate": "1963-08-12",
"address": {
"street_address": "Heidestraße 17",
"locality": "Köln",
"postal_code": "51147",
"country": "DE"
},
"nationalities": [
"DE"
],
"sex": 2,
"birth_family_name": "Gabler",
"place_of_birth": {
"locality": "Berlin",
"country": "DE"
},
"age_equal_or_over": {
"12": true,
"14": true,
"16": true,
"18": true,
"21": true,
"65": false
},
"age_in_years": 62,
"age_birth_year": 1963,
"issuance_date": "2020-03-11",
"expiry_date": "2030-03-12",
"issuing_authority": "DE",
"issuing_country": "DE"
}
The following is the issued SD-JWT:
発行された 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
xalFXejB0TGl1Q21NZU8wS3FhekdJIl19XQ~WyJqN0FEZGIwVVZiMExpMGNpUGNQMGV3
IiwgImFnZV9pbl95ZWFycyIsIDYyXQ~WyJXcHhKckZ1WDh1U2kycDRodDA5anZ3IiwgI
mFnZV9iaXJ0aF95ZWFyIiwgMTk2M10~WyJhdFNtRkFDWU1iSlZLRDA1bzNKZ3RRIiwgI
mlzc3VhbmNlX2RhdGUiLCAiMjAyMC0wMy0xMSJd~WyI0S3lSMzJvSVp0LXprV3ZGcWJV
TEtnIiwgImV4cGlyeV9kYXRlIiwgIjIwMzAtMDMtMTIiXQ~WyJjaEJDc3loeWgtSjg2S
S1hd1FEaUNRIiwgImlzc3VpbmdfYXV0aG9yaXR5IiwgIkRFIl0~WyJmbE5QMW5jTXo5T
GctYzlxTUl6XzlnIiwgImlzc3VpbmdfY291bnRyeSIsICJERSJd~
The following payload is used for the SD-JWT:
次のペイロードが 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",
"_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 digests in the SD-JWT payload reference the following Disclosures:
SD-JWT ペイロード内のダイジェストは、次の開示情報を参照しています。
* Claim given_name:
* 指定された名前を要求します:
- SHA-256 Hash:
- SHA-256 ハッシュ:
0HZmnSIPz337kSWe7C34l--88gzJi-eBJ2Vz_HJwATg
0HZmnSIPz337kSWe7C34l--88gzJi-eBJ2Vz_HJwATg
- Disclosure:
- 開示：
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiRXJpa2E iXQ
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiRXJpa2E iXQ
- Contents:
- コンテンツ：
["2GLC42sKQveCfGfryNRN9w", "given_name", "Erika"]
["2GLC42sKQveCfGfryNRN9w"、"指定された名前"、"エリカ"]
* Claim family_name:
* family_name を主張します:
- SHA-256 Hash:
- SHA-256 ハッシュ:
I00fcFUoDXCucp5yy2ujqPssDVGaWNiUliNz_awD0gc
I00fcFUoDXCucp5yy2ujqPssDVGaWNiUliNz_awD0gc
- Disclosure:
- 開示：
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIk11c3R lcm1hbm4iXQ
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIk11c3R lcm1hbm4iXQ
- Contents:
- コンテンツ：
["eluV5Og3gSNII8EYnsxA_A", "family_name", "Mustermann"]
["eluV5Og3gSNII8EYnsxA_A"、"family_name"、"Mustermann"]
* Claim birthdate:
* 主張の生年月日:
- SHA-256 Hash:
- SHA-256 ハッシュ:
Lai6IU6d7GQagXR7AvGTrnXgSld3z8EIg_fv3fOZ1Wg
Lai6IU6d7GQagXR7AvGTrnXgSld3z8EIg_fv3fOZ1Wg
- Disclosure:
- 開示：
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImJpcnRoZGF0ZSIsICIxOTYzLTA 4LTEyIl0
WyI2SWo3dE0tyTVpVlBHYm9TNXRtdlZBIiwgImJpcnRoZGF0ZSICIxOTYzLTA 4LTEyIl0
- Contents:
- コンテンツ：
["6Ij7tM-a5iVPGboS5tmvVA", "birthdate", "1963-08-12"]
["6Ij7tM-a5iVPGboS5tmvVA"、"生年月日"、"1963-08-12"]
* Claim street_address:
* 請求番地番地:
- SHA-256 Hash:
- SHA-256 ハッシュ:
ALZERsSn5WNiEXdCksW8I5qQw3_NpAnRqpSAZDudgw8
アルザースSn5WNiEXdCksW8I5qQw3_NpAnRqpSAZDudgw8
- Disclosure:
- 開示：
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInN0cmVldF9hZGRyZXNzIiwgIkh laWRlc3RyYVx1MDBkZmUgMTciXQ
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInN0cmVldF9hZGRyZXNzIiwgIkh laWRlc3RyYVx1MDBkZmUgMTciXQ
- Contents:
- コンテンツ：
["eI8ZWm9QnKPpNPeNenHdhQ", "street_address", "Heidestra\u00dfe 17"]
["eI8ZWm9QnKPpNPeNenHdhQ"、"番地"、"ハイデストラ\u00dfe 17"]
* Claim locality:
* 主張の場所:
- SHA-256 Hash:
- SHA-256 ハッシュ:
D__W_uYcvRz3tvUnIJvBDHiTc7C__qHd0xNKwIs_w9k
D__W_uYcvRz3tvUnIJvBDHiTc7C__qHd0xNKwIs_w9k
- Disclosure:
- 開示：
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImxvY2FsaXR5IiwgIktcdTAwZjZ sbiJd
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImxvY2FsaXR5IiwgIktcdTAwZjZ sbiJd
- Contents:
- コンテンツ：
["Qg_O64zqAxe412a108iroA", "locality", "K\u00f6ln"]
["Qg_O64zqAxe412a108iroA"、"地域"、"K\u00f6ln"]
* Claim postal_code:
* 郵便番号を請求:
- SHA-256 Hash:
- SHA-256 ハッシュ:
xOPy9-gJALK6UbWKFLR85cOByUD3AbNwFg3I3YfQE_I
xOPy9-gJALK6UbWKFLR85cOByUD3AbNwFg3I3YfQE_I
- Disclosure:
- 開示：
WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInBvc3RhbF9jb2RlIiwgIjUxMTQ 3Il0
WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInBvc3RhbF9jb2RlIiwgIjUxMTQ 3Il0
- Contents:
- コンテンツ：
["AJx-095VPrpTtN4QMOqROA", "postal_code", "51147"]
["AJx-095VPrpTtN4QMOqROA"、"郵便番号"、"51147"]
* Claim country:
* 請求国:
- SHA-256 Hash:
- SHA-256 ハッシュ:
eBpCXU1J5dhH2g4t8QYNW5ExS9AxUVblUodoLYoPho0
ebpCXU1J5dhH2g4t8QYNW5ExS9AxUVblUodoLYoPho0
- Disclosure:
- 開示：
WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImNvdW50cnkiLCAiREUiXQ
WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImNvdW50cnkiLCAiREUiXQ
- Contents:
- コンテンツ：
["Pc33JM2LchcU_lHggv_ufQ", "country", "DE"]
["Pc33JM2LchcU_lHggv_ufQ"、"国"、"DE"]
* Claim address:
* 請求先住所:
- SHA-256 Hash:
- SHA-256 ハッシュ:
RTz3qTmFNHbpWrrOMZS41F474kFqRv3vIPqth6PUhlM
RTz3qTmFNHbpWrrOMZS41F474kFqRv3vIPqth6PUhlM
- Disclosure:
- 開示：
WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImFkZHJlc3MiLCB7Il9zZCI6IFs iQUxaRVJzU241V05pRVhkQ2tzVzhJNXFRdzNfTnBBblJxcFNBWkR1ZGd3OCIsIC JEX19XX3VZY3ZSejN0dlVuSUp2QkRIaVRjN0NfX3FIZDB4Tkt3SXNfdzlrIiwgI mVCcENYVTFKNWRoSDJnNHQ4UVlOVzVFeFM5QXhVVmJsVW9kb0xZb1BobzAiLCAi eE9QeTktZ0pBTEs2VWJXS0ZMUjg1Y09CeVVEM0FiTndGZzNJM1lmUUVfSSJdfV0
WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImFkZHJlc3MiLCB7Il9zZCI6IFs iQUxaRVJzU241V05pRVhkQ2tzVzhJNXFRdzNfTnBBblJcFNBWkR1ZGd3OCISICJEX19XX3VZY3ZSejN0dlVuSUp2QkRIaVRjN0NfX3FIZDB4Tkt3SXNfdzlrIiwgI mVCceNYVTFKNWRoSDJnNHQ4UVlOVzVFeFM5QXhVVmJsVW9kb0xZb1BobzAiLCAieE9QeTktZ0pBTEs2VWJXS0ZMUjg1Y09CeVVEM0FiTndGZzNJM1lmUUVfSSJdfV0
- Contents:
- コンテンツ：
["G02NSrQfjFXQ7Io09syajA", "address", {"_sd": ["ALZERsSn5WNiEXdCksW8I5qQw3_NpAnRqpSAZDudgw8", "D__W_uYcvRz3tvUnIJvBDHiTc7C__qHd0xNKwIs_w9k", "eBpCXU1J5dhH2g4t8QYNW5ExS9AxUVblUodoLYoPho0", "xOPy9-gJALK6UbWKFLR85cOByUD3AbNwFg3I3YfQE_I"]}]
["G02NSrQfjFXQ7Io09syajA", "アドレス", {"_sd": ["ALZERsSn5WNiEXdCksW8I5qQw3_NpAnRqpSAZDudgw8", "D__W_uYcvRz3tvUnIJvBDHiTc7C__qHd0xNKwIs_w9k","eBpCXU1J5dhH2g4t8QYNW5ExS9AxUVblUodoLYoPho0"、"xOPy9-gJALK6UbWKFLR85cOByUD3AbNwFg3I3YfQE_I"]}]
* Claim nationalities:
* 主張する国籍:
- SHA-256 Hash:
- SHA-256 ハッシュ:
y50czc0ISChy_bsba1dMoUuAOQ5AMmOSfGoEe81v1FU
y50czc0ISChy_bsba1dMoUuAOQ5AMmOSfGoEe81v1FU
- Disclosure:
- 開示：
WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIm5hdGlvbmFsaXRpZXMiLCBbIkR FIl1d
WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIm5hdGlvbmFsaXRpZXMiLCBbIkR Fil1d
- Contents:
- コンテンツ：
["lklxF5jMYlGTPUovMNIvCA", "nationalities", ["DE"]]
["lklxF5jMYlGTPUovMNIvCA", "国籍", ["DE"]]
* Claim sex:
* 性別を主張する:
- SHA-256 Hash:
- SHA-256 ハッシュ:
90CT8AaBPbn5X8nRXkesju1i0BqhWqZ3wqD4jF-qDGk
90CT8AaBPbn5X8nRXkesju1i0BqhWqZ3wqD4jF-qDGk
- Disclosure:
- 開示：
WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgInNleCIsIDJd
WyJuUHVvUW5rUkZxM0JJZUFTN0FuWEZBIiwgInNleCIsIDJd
- Contents:
- コンテンツ：
["nPuoQnkRFq3BIeAm7AnXFA", "sex", 2]
["nPuoQnkRFq3BIeAm7AnXFA"、"セックス"、2]
* Claim birth_family_name:
* Birth_family_name を主張します:
- SHA-256 Hash:
- SHA-256 ハッシュ:
KjAXgAA9N5WHEDtRIh4u5Mn1ZsWixhhWAiX-A4QiwgA
KjAXgAA9N5WHEDtRIh4u5Mn1ZsWixhhWAiX-A4QiwgA
- Disclosure:
- 開示：
WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImJpcnRoX2ZhbWlseV9uYW1lIiw gIkdhYmxlciJd
WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImJpcnRoX2ZhbWlseV9uYW1liiw gikdhYmxlciJd
- Contents:
- コンテンツ：
["5bPs1IquZNa0hkaFzzzZNw", "birth_family_name", "Gabler"]
["5bPs1IquZNa0hkaFzzzZNw"、"誕生家族名"、"ゲーブラー"]
* Claim locality:
* 主張の場所:
- SHA-256 Hash:
- SHA-256 ハッシュ:
KUViaaLnY5jSML90G29OOLENPbbXfhSjSPMjZaGkxAE
KUViaaLnY5jSML90G29OOLENPbbXfhSjSPMjZaGkxAE
- Disclosure:
- 開示：
WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgImxvY2FsaXR5IiwgIkJlcmxpbiJ d
WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgImxvY2FsaXR5IiwgIkJlcmxpbiJ d
- Contents:
- コンテンツ：
["5a2W0_NrlEZzfqmk_7Pq-w", "locality", "Berlin"]
["5a2W0_NrlEZzfqmk_7Pq-w"、"地域"、"ベルリン"]
* Claim country:
* 請求国:
- SHA-256 Hash:
- SHA-256 ハッシュ:
YbsT0S76VqXCVsd1jUSlwKPDgmALeB1uZclFHXf-USQ
YbsT0S76VqXCVsd1jUSlwKPDgmaLeB1uZclFHXf-USQ
- Disclosure:
- 開示：
WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImNvdW50cnkiLCAiREUiXQ
WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImNvdW50cnkiLCAiREUiXQ
- Contents:
- コンテンツ：
["y1sVU5wdfJahVdgwPgS7RQ", "country", "DE"]
["y1sVU5wdfJahVdgwPgS7RQ", "国", "DE"]
* Claim place_of_birth:
* 出生地を主張する:
- SHA-256 Hash:
- SHA-256 ハッシュ:
1Crn03WmUeRWp4zwPvvCKXl9ZaQp-cdQV_gHdaGSWow
1Crn03WmUeRWp4zwPvvCKXl9ZaQp-cdQV_gHdaGSすごい
- Disclosure:
- 開示：
WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgInBsYWNlX29mX2JpcnRoIiwgeyJ fc2QiOiBbIktVVmlhYUxuWTVqU01MOTBHMjlPT0xFTlBiYlhmaFNqU1BNalphR2 t4QUUiLCAiWWJzVDBTNzZWcVhDVnNkMWpVU2x3S1BEZ21BTGVCMXVaY2xGSFhmL VVTUSJdfV0
WyJIYLE0WDhzclZXM1FEeG5JSmRxeU9BIiwgInBsYWNlX29mX2JpcnRoIwgeyJ fc2QiOiBbIktVVmlhYUxuWTVqU01MOTBHMjlPT0xFTlBiYlhmaFNqU1BNalphR2t4QUUiLCAiWWJzVDBTNzZWcVhDVnNkMWpVU2x3S1BEZ21BTGVCMXVaY2xGSFhmL VVTUSJdfV0
- Contents:
- コンテンツ：
["HbQ4X8srVW3QDxnIJdqyOA", "place_of_birth", {"_sd": ["KUViaaLnY5jSML90G29OOLENPbbXfhSjSPMjZaGkxAE", "YbsT0S76VqXCVsd1jUSlwKPDgmALeB1uZclFHXf-USQ"]}]
["HbQ4X8srVW3QDxnIJdqyOA", "出生地", {"_sd": ["KUViaaLnY5jSML90G29OOLENPbbXfhSjSPMjZaGkxAE","YbsT0S76VqXCVsd1jUSlwKPDgmaLeB1uZclFHXf-USQ"]}]
* Claim 12:
* 請求項 12:
- SHA-256 Hash:
- SHA-256 ハッシュ:
gkvy0FuvBBvj0hs2ZNwxcqOlf8mu2-kCE7-Nb2QxuBU
gkvy0FuvBBvj0hs2ZNwxcqOlf8mu2-kCE7-Nb2QxuBU
- Disclosure:
- 開示：
WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgIjEyIiwgdHJ1ZV0
WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgIjEyIiwgdHJ1ZV0
- Contents:
- コンテンツ：
["C9GSoujviJquEgYfojCb1A", "12", true]
["C9GSoujviJquEgYfojCb1A", "12", true]
* Claim 14:
* 請求項14：
- SHA-256 Hash:
- SHA-256 ハッシュ:
y6SFrVFRyq50IbRJviTZqqjQWz0tLiuCmMeO0KqazGI
y6SFrVFRyq50IbRJviTZqqjQWz0tLiuCmMeO0KqazGI
- Disclosure:
- 開示：
WyJreDVrRjE3Vi14MEptd1V4OXZndnR3IiwgIjE0IiwgdHJ1ZV0
WyJreDVRjE3Vi14MEptd1V4OXZndnR3IiwgIjE0IiwgdHJ1ZV0
- Contents:
- コンテンツ：
["kx5kF17V-x0JmwUx9vgvtw", "14", true]
["kx5kF17V-x0JmwUx9vgvtw"、"14"、true]
* Claim 16:
* 請求項16：
- SHA-256 Hash:
- SHA-256 ハッシュ:
hrY4HnmF5b5JwC9eTzaFCUceIQAaIdhrqUXQNCWbfZI
hrY4HnmF5b5JwC9eTzaFCUceIQAaIdhrqUXQNCWbfZI
- Disclosure:
- 開示：
WyJIM28xdXN3UDc2MEZpMnllR2RWQ0VRIiwgIjE2IiwgdHJ1ZV0
WyJIM28xdXN3UDc2MEZpMnllR2RWQ0VRiwgIjE2IiwgdHJ1ZV0
- Contents:
- コンテンツ：
["H3o1uswP760Fi2yeGdVCEQ", "16", true]
["H3o1uswP760Fi2yeGdVCEQ"、"16"、true]
* Claim 18:
* 請求項18：
- SHA-256 Hash:
- SHA-256 ハッシュ:
CVKnly5P90yJs3EwtxQiOtUczaXCYNA4IczRaohrMDg
CVKnly5P90yJs3EwtxQiotUczaXCYNA4IczRaohrMDg
- Disclosure:
- 開示：
WyJPQktsVFZsdkxnLUFkd3FZR2JQOFpBIiwgIjE4IiwgdHJ1ZV0
WyJPQktsVFZsdkxnLUFkd3FZR2JQOFpBIiwgIjE4IiwgdHJ1ZV0
- Contents:
- コンテンツ：
["OBKlTVlvLg-AdwqYGbP8ZA", "18", true]
["OBKlTVlvLg-AdwqYGbP8ZA", "18", true]
* Claim 21:
* 請求項21:
- SHA-256 Hash:
- SHA-256 ハッシュ:
1tEiyzPRYOKsf7SsYGMgPZKsOT1lQZRxHXA0r5_Bwkk
1tEiyzPRYOKsf7SsYGMgPZKsOT1lQZRxHXA0r5_Bwkk
- Disclosure:
- 開示：
WyJNMEpiNTd0NDF1YnJrU3V5ckRUM3hBIiwgIjIxIiwgdHJ1ZV0
WyJNMEpiNTd0NDF1YnJrU3V5ckRUM3hBIiwgIjIxIiwgdHJ1ZV0
- Contents:
- コンテンツ：
["M0Jb57t41ubrkSuyrDT3xA", "21", true]
["M0Jb57t41ubrkSuyrDT3xA"、"21"、true]
* Claim 65:
* 請求項65:
- SHA-256 Hash:
- SHA-256 ハッシュ:
a44-g2Gr8_3AmJw2XZ8kI1y0Qz_ze9iOcW2W3RLpXGg
a44-g2Gr8_3AmJw2XZ8kI1y0Qz_ze9iOcW2W3RLpXGg
- Disclosure:
- 開示：
WyJEc210S05ncFY0ZEFIcGpyY2Fvc0F3IiwgIjY1IiwgZmFsc2Vd
WyJEc210S05ncFY0ZEFIcGpyY2Fvc0F3IiwgIjY1IiwgZmFsc2Vd
- Contents:
- コンテンツ：
["DsmtKNgpV4dAHpjrcaosAw", "65", false]
["DsmtKNgpV4dAHpjrcaosAw"、"65"、false]
* Claim age_equal_or_over:
* age_equal_or_over を主張します:
- SHA-256 Hash:
- SHA-256 ハッシュ:
2r009dzvHuVrWrRXT5kJMmHnqEHHnWe0MLVZw8PATB8
2r009dzvHuVrWrRXT5kJMmHnqEHHnWe0MLVZw8PATB8
- Disclosure:
- 開示：
WyJlSzVvNXBIZmd1cFBwbHRqMXFoQUp3IiwgImFnZV9lcXVhbF9vcl9vdmVyIiw geyJfc2QiOiBbIjF0RWl5elBSWU9Lc2Y3U3NZR01nUFpLc09UMWxRWlJ4SFhBMH I1X0J3a2siLCAiQ1ZLbmx5NVA5MHlKczNFd3R4UWlPdFVjemFYQ1lOQTRJY3pSY W9ock1EZyIsICJhNDQtZzJHcjhfM0FtSncyWFo4a0kxeTBRel96ZTlpT2NXMlcz UkxwWEdnIiwgImdrdnkwRnV2QkJ2ajBoczJaTnd4Y3FPbGY4bXUyLWtDRTctTmI yUXh1QlUiLCAiaHJZNEhubUY1YjVKd0M5ZVR6YUZDVWNlSVFBYUlkaHJxVVhRTk NXYmZaSSIsICJ5NlNGclZGUnlxNTBJYlJKdmlUWnFxalFXejB0TGl1Q21NZU8wS 3FhekdJIl19XQ
WyJlSzVvNXBIZmd1cFBwbHRqMXFoQUp3IiwgImFnZV9lcXVhbF9vcl9vdmVyIiw geyJfc2QiOiBbIjF0RWl5elBSWU9Lc2Y3U3NZR01nUFpLc09UMWxRWlJ4SFhBMHI1X0J3a2siLCAiQ1ZLbmx5NVA5MHlKczNFd3R4UWlPdFVjemFYQ1lOQTRJY3psSY W9ock1EZyISICJhNDQtZzJHcjhfM0FtSncyWFo4a0kxeTBRel96ZTlpT2NXMlczUkxwWednIiwgImdrdnkwRnV2QkJ2ajBoczJaTnd4Y3FPbGY4bXUyLWtDRTctTmI yUXh1QlUiLCaiaHJZNEhubUY1YjVKd0M5ZVR6YUZDVWNlSVFBYUlkaHJ×VVhRTkNXYmZaSSSICJ5NlNGclZGUnlxNTBJYlJKdmlUWnFxalFXejB0TGl1Q21NZU8wS 3FhekdJIl19XQ
- Contents:
- コンテンツ：
["eK5o5pHfgupPpltj1qhAJw", "age_equal_or_over", {"_sd": ["1tEiyzPRYOKsf7SsYGMgPZKsOT1lQZRxHXA0r5_Bwkk", "CVKnly5P90yJs3EwtxQiOtUczaXCYNA4IczRaohrMDg", "a44-g2Gr8_3AmJw2XZ8kI1y0Qz_ze9iOcW2W3RLpXGg", "gkvy0FuvBBvj0hs2ZNwxcqOlf8mu2-kCE7-Nb2QxuBU", "hrY4HnmF5b5JwC9eTzaFCUceIQAaIdhrqUXQNCWbfZI", "y6SFrVFRyq50IbRJviTZqqjQWz0tLiuCmMeO0KqazGI"]}]
["eK5o5pHfgupPpltj1qhAJw", "age_equal_or_over", {"_sd": ["1tEiyzPRYOKsf7SsYGMgPZKsOT1lQZRxHXA0r5_Bwkk","CVKnly5P90yJs3EwtxQiOtUczaXCYNA4IczRaohrMDg", "a44-g2Gr8_3AmJw2XZ8kI1y0Qz_ze9iOcW2W3RLpXGg","gkvy0FuvBBvj0hs2ZNwxcqOlf8mu2-kCE7-Nb2QxuBU"、"hrY4HnmF5b5JwC9eTzaFCUceIQAaIdhrqUXQNCWbfZI"、"y6SFrVFRyq50IbRJviTZqqjQWz0tLiuCmMeO0KqazGI"]}]
* Claim age_in_years:
* age_in_year の請求:
- SHA-256 Hash:
- SHA-256 ハッシュ:
WTpI7RcM3gxZruRpXzezSbkbOr93PVFvWx8woJ3j1cE
WTpi7RcM3gxZruRpXzezSbkbOr93PVFvWx8woJ3j1cE
- Disclosure:
- 開示：
WyJqN0FEZGIwVVZiMExpMGNpUGNQMGV3IiwgImFnZV9pbl95ZWFycyIsIDYyXQ
WyJqN0FEZGIwVVZiMExpMGNpUGNQMGV3IiwgImFnZV9pbl95ZWFycyISIDYyXQ
- Contents:
- コンテンツ：
["j7ADdb0UVb0Li0ciPcP0ew", "age_in_years", 62]
["j7ADdb0UVb0Li0ciPcP0ew"、"年齢"、62]
* Claim age_birth_year:
* age_birth_year を申請:
- SHA-256 Hash:
- SHA-256 ハッシュ:
LezjabRqiZOXzEYmVZf8RMi9xAkd3_M1LZ8U7E4s3u4
LezjabRqiZOXzEYmVZf8RMi9xAkd3_M1LZ8U7E4s3u4
- Disclosure:
- 開示：
WyJXcHhKckZ1WDh1U2kycDRodDA5anZ3IiwgImFnZV9iaXJ0aF95ZWFyIiwgMTk 2M10
WyJXcHhKckZ1WDh1U2kycDRodDA5anZ3IiwgImFnZV9iaXJ0aF95ZWFyIiwgMTk 2M10
- Contents:
- コンテンツ：
["WpxJrFuX8uSi2p4ht09jvw", "age_birth_year", 1963]
["WpxJrFuX8uSi2p4ht09jvw"、"誕生年"、1963年]
* Claim issuance_date:
* 請求発行日:
- SHA-256 Hash:
- SHA-256 ハッシュ:
W14XHbUffzuW4IFMjpSTb1melWxUWf4N_o2ldkkIqc8
W14XHbUffzuW4IFMjpSTb1melWxUWf4N_o2ldkkIqc8
- Disclosure:
- 開示：
WyJhdFNtRkFDWU1iSlZLRDA1bzNKZ3RRIiwgImlzc3VhbmNlX2RhdGUiLCAiMjA yMC0wMy0xMSJd
WyJhdFNtRkFDWU1isSlZLRDA1bzNKZ3RRIiwgImlzc3VhbmNlX2RhdGUILCAiMjayMC0wMy0xMSJd
- Contents:
- コンテンツ：
["atSmFACYMbJVKD05o3JgtQ", "issuance_date", "2020-03-11"]
["atSmFACYMbJVKD05o3JgtQ", "発行日", "2020-03-11"]
* Claim expiry_date:
* 請求の有効期限:
- SHA-256 Hash:
- SHA-256 ハッシュ:
78jg77-GYBeX8IQfoELPyL0DYPdmfZo0JgViV0_lKCM
78jg77-GYBeX8IQfoELPyL0DYPdmfZo0JgViV0_lKCM
- Disclosure:
- 開示：
WyI0S3lSMzJvSVp0LXprV3ZGcWJVTEtnIiwgImV4cGlyeV9kYXRlIiwgIjIwMzA tMDMtMTIiXQ
WyI0S3lSMzJvSVp0LXprV3ZGcWJVTEtnIiwgImV4cGlyeV9kYXRlIiwgIjIwMzAtMDMtMTIiXQ
- Contents:
- コンテンツ：
["4KyR32oIZt-zkWvFqbULKg", "expiry_date", "2030-03-12"]
["4KyR32oIZt-zkWvFqbULKg"、"有効期限"、"2030-03-12"]
* Claim issuing_authority:
* クレーム発行権限:
- SHA-256 Hash:
- SHA-256 ハッシュ:
6ZNISDst62ymlrOAkadjdD5ZulT5A299J78SLhM__Os
6ZNISDst62ymlrOAkadjdD5ZulT5A299J78SLhM__Os
- Disclosure:
- 開示：
WyJjaEJDc3loeWgtSjg2SS1hd1FEaUNRIiwgImlzc3VpbmdfYXV0aG9yaXR5Iiw gIkRFIl0
WyJjaEJDc3loeWgtSjg2SS1hd1FEaUNRIiwgImlzc3VpbmdfYXV0aG9yaXR5Iiw gIkRFIl0
- Contents:
- コンテンツ：
["chBCsyhyh-J86I-awQDiCQ", "issuing_authority", "DE"]
["chBCsyhyh-J86I-awQDiCQ", "発行_権限", "DE"]
* Claim issuing_country:
* 請求発行国:
- SHA-256 Hash:
- SHA-256 ハッシュ:
_ohJVIQIBsU4updNS4_w4Kb1MHqJ0L9qLGshWq6JXQs
_ohJVIQIBsU4updNS4_w4Kb1MHqJ0L9qLGshWq6JXQs
- Disclosure:
- 開示：
WyJmbE5QMW5jTXo5TGctYzlxTUl6XzlnIiwgImlzc3VpbmdfY291bnRyeSIsICJ ERSJd
WyJmbE5QMW5jTXo5TGctYzlxTUl6XzlnIiwgImlzc3VpbmdfY291bnRyeSISICJ ERSJd
- Contents:
- コンテンツ：
["flNP1ncMz9Lg-c9qMIz_9g", "issuing_country", "DE"]
["flNP1ncMz9Lg-c9qMIz_9g", "発行国", "DE"]
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:
以下は、国籍とその人物が 18 歳以上であるという事実のみを開示する SD-JWT+KB の例です。
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:
これは、対応するキー バインディング 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:
検証後、検証者は次の処理済み SD-JWT ペイロードをさらに処理できるようになります。
{
"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"
]
}
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].
この非規範的な例は、この仕様で定義されているアーティファクトを使用して、W3C Verifiable Credentials Data Model v2.0 ペイロード [VC_DATA_v2.0] を表現する方法を示しています。
Key Binding is applied using the Holder's public key passed in a cnf claim in the SD-JWT.
キー バインドは、SD-JWT の cnf クレームで渡されたホルダーの公開キーを使用して適用されます。
The following is the input JWT Claims Set:
以下は入力 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": {
"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:
発行された 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:
次のペイロードが 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:
SD-JWT ペイロード内のダイジェストは、次の開示情報を参照しています。
* Claim atcCode:
* ATCコードを請求:
- SHA-256 Hash:
- SHA-256 ハッシュ:
1cF5hLwkhMNIaqfWJrXI7NMWedL-9f6Y2PA52yPjSZI
1cF5hLwkhMNIaqfWJrXI7NMWedL-9f6Y2PA52yPjSZI
- Disclosure:
- 開示：
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImF0Y0NvZGUiLCAiSjA3QlgwMyJ d
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImF0Y0NvZGUILCAiSja3QlgwMyJ d
- Contents:
- コンテンツ：
["2GLC42sKQveCfGfryNRN9w", "atcCode", "J07BX03"]
["2GLC42sKQveCfGfryNRN9w"、"atcコード"、"J07BX03"]
* Claim medicinalProductName:
* 医薬品の製品名を主張:
- SHA-256 Hash:
- SHA-256 ハッシュ:
Hiy6WWueLD5bn16298tPv7GXhmldMDOTnBi-CZbphNo
Hiy6WWueLD5bn16298tPv7GXhmldMDOTnBi-CZbphNo
- Disclosure:
- 開示：
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgIm1lZGljaW5hbFByb2R1Y3ROYW1 lIiwgIkNPVklELTE5IFZhY2NpbmUgTW9kZXJuYSJd
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgIm1lZGljaW5hbFByb2R1Y3ROYW1 liwgIkNPVklELTE5IFZhY2NpbmUgTW9kZXJuYSJd
- Contents:
- コンテンツ：
["eluV5Og3gSNII8EYnsxA_A", "medicinalProductName", "COVID-19 Vaccine Moderna"]
["eluV5Og3gSNII8EYnsxA_A"、"医薬品製品名"、"新型コロナウイルス感染症ワクチンモデルナ"]
* Claim marketingAuthorizationHolder:
* クレームマーケティングの承認所有者:
- SHA-256 Hash:
- SHA-256 ハッシュ:
Lb027q691jXXl-jC73vi8ebOj9smx3C-_og7gA4TBQE
Lb027q691jXXl-jC73vi8ebOj9smx3C-_og7gA4TBQE
- Disclosure:
- 開示：
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgIm1hcmtldGluZ0F1dGhvcml6YXR pb25Ib2xkZXIiLCAiTW9kZXJuYSBCaW90ZWNoIl0
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgIm1hcmtldGluZ0F1dGhvcml6YXR pb25Ib2xkZXIiLCAiTW9kZXJuYSBCaW90ZWNoIl0
- Contents:
- コンテンツ：
["6Ij7tM-a5iVPGboS5tmvVA", "marketingAuthorizationHolder", "Moderna Biotech"]
["6Ij7tM-a5iVPGboS5tmvVA"、"marketingAuthorizationHolder"、"Moderna Biotech"]
* Claim nextVaccinationDate:
* 次の予防接種日を申請してください:
- SHA-256 Hash:
- SHA-256 ハッシュ:
R2fGbfA07Z_YlkqmNZyma1xyyx1XstIiS6B1Ybl2JZ4
R2fGbfA07Z_YlkqmNZyma1xyyx1XstIiS6B1Ybl2JZ4
- Disclosure:
- 開示：
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm5leHRWYWNjaW5hdGlvbkRhdGU iLCAiMjAyMS0wOC0xNlQxMzo0MDoxMloiXQ
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm5leHRWYWNjaW5hdGlvbkRhdGU iLCAiMjayMS0wOC0xNlQxMzo0MDoxMloiXQ
- Contents:
- コンテンツ：
["eI8ZWm9QnKPpNPeNenHdhQ", "nextVaccinationDate", "2021-08-16T13:40:12Z"]
["eI8ZWm9QnKPpNPeNenHdhQ"、"次のワクチン接種日"、"2021-08-16T13:40:12Z"]
* Claim countryOfVaccination:
* ワクチン接種を請求する国:
- SHA-256 Hash:
- SHA-256 ハッシュ:
JzjLgtP29dP-B3td12P674gFmK2zy81HMtBgf6CJNWg
JzjLgtP29dP-B3td12P674gFmK2zy81HMtBgf6CJNWg
- Disclosure:
- 開示：
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImNvdW50cnlPZlZhY2NpbmF0aW9 uIiwgIkdFIl0
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImNvdW50cnlPZlZhY2NpbmF0aW9 uIwgIkdFIl0
- Contents:
- コンテンツ：
["Qg_O64zqAxe412a108iroA", "countryOfVaccination", "GE"]
["Qg_O64zqAxe412a108iroA"、"ワクチン接種の国"、"GE"]
* Claim dateOfVaccination:
* ワクチン接種の請求日:
- SHA-256 Hash:
- SHA-256 ハッシュ:
zJK_eSMXjwM8dXmMZLnI8FGM08zJ3_ubGeEMJ-5TBy0
zJK_eSMXjwM8dXmMZLnI8FGM08zJ3_ubGeEMJ-5TBy0
- Disclosure:
- 開示：
WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRhdGVPZlZhY2NpbmF0aW9uIiw gIjIwMjEtMDYtMjNUMTM6NDA6MTJaIl0
WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRhdGVPZlZhY2NpbmF0aW9uIiw gIjIwMjEtMDYtMjNUMTM6NDA6MTJaIl0
- Contents:
- コンテンツ：
["AJx-095VPrpTtN4QMOqROA", "dateOfVaccination", "2021-06-23T13:40:12Z"]
["AJx-095VPrpTtN4QMOqROA"、"ワクチン接種日"、"2021-06-23T13:40:12Z"]
* Claim order:
* 請求の順序:
- SHA-256 Hash:
- SHA-256 ハッシュ:
b0eUsvGP-ODDdFoY4NlzlXc3tDslWJtCJF75Nw8Oj_g
b0eUsvGP-ODDdFoY4NlzlXc3tDslWJtCJF75Nw8Oj_g
- Disclosure:
- 開示：
WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgIm9yZGVyIiwgIjMvMyJd
WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgIm9yZGVyIiwgIjMvMyJd
- Contents:
- コンテンツ：
["Pc33JM2LchcU_lHggv_ufQ", "order", "3/3"]
["Pc33JM2LchcU_lHggv_ufQ"、"注文"、"3/3"]
* Claim gender:
* 性別を主張:
- SHA-256 Hash:
- SHA-256 ハッシュ:
3nzLq81M2oN06wdv1shHvOEJVxZ5KLmdDkHEDJABWEI
3nzLq81M2oN06wdv1shHvOEJVxZ5KLmdDkHEDJABWEI
- Disclosure:
- 開示：
WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdlbmRlciIsICJGZW1hbGUiXQ
WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdlbmRlciISICJGZW1hbGUIXQ
- Contents:
- コンテンツ：
["G02NSrQfjFXQ7Io09syajA", "gender", "Female"]
["G02NSrQfjFXQ7Io09syajA"、"性別"、"女性"]
* Claim birthDate:
* 生年月日の請求:
- SHA-256 Hash:
- SHA-256 ハッシュ:
Pn1sWi06G4LJrnn-_RT0RbM_HTdxnPJQuX2fzWv_JOU
Pn1sWi06G4LJrnn-_RT0RbM_HTdxnPJQuX2fzWv_JOU
- Disclosure:
- 開示：
WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImJpcnRoRGF0ZSIsICIxOTYxLTA 4LTE3Il0
WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImJpcnRoRGF0ZSIsICIxOTYxLTA 4LTE3Il0
- Contents:
- コンテンツ：
["lklxF5jMYlGTPUovMNIvCA", "birthDate", "1961-08-17"]
["lklxF5jMYlGTPUovMNIvCA", "生年月日", "1961-08-17"]
* Claim givenName:
* 指定された名前を要求します:
- SHA-256 Hash:
- SHA-256 ハッシュ:
lF9uzdsw7HplGLc714Tr4WO7MGJza7tt7QFleCX4Itw
lF9uzdsw7HplGLc714Tr4WO7MGJza7tt7QFleCX4Itw
- Disclosure:
- 開示：
WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgImdpdmVuTmFtZSIsICJNYXJpb24 iXQ
WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgImdpdmVuTmFtZSIsICJNYXJpb24 iXQ
- Contents:
- コンテンツ：
["nPuoQnkRFq3BIeAm7AnXFA", "givenName", "Marion"]
["nPuoQnkRFq3BIeAm7AnXFA"、"与えられた名前"、"マリオン"]
* Claim familyName:
* 家族名を主張:
- SHA-256 Hash:
- SHA-256 ハッシュ:
1lSQBNY24q0Th6OGzthq-7-4l6cAaxrYXOGZpeW_lnA
1lSQBNY24q0Th6OGzthq-7-4l6cAaxrYXOGZpeW_lnA
- Disclosure:
- 開示：
WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImZhbWlseU5hbWUiLCAiTXVzdGV ybWFubiJd
WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImZhbWlseU5hbWUiLCAiTXVzdGV ybWFubiJd
- Contents:
- コンテンツ：
["5bPs1IquZNa0hkaFzzzZNw", "familyName", "Mustermann"]
["5bPs1IquZNa0hkaFzzzZNw"、"家族名"、"マスターマン"]
* Claim administeringCentre:
* 請求管理センター:
- SHA-256 Hash:
- SHA-256 ハッシュ:
TCmzrl7K2gev_du7pcMIyzRLHp-Yeg-Fl_cxtrUvPxg
TCmzrl7K2gev_du7pcMIyzRLHp-Yeg-Fl_cxtrUvPxg
- Disclosure:
- 開示：
WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgImFkbWluaXN0ZXJpbmdDZW50cmU iLCAiUHJheGlzIFNvbW1lcmdhcnRlbiJd
WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgImFkbWluaXN0ZXJpbmdDZW50cmU iLCAiUHJheGlzIFNvbW1lcmdhcnRlbiJd
- Contents:
- コンテンツ：
["5a2W0_NrlEZzfqmk_7Pq-w", "administeringCentre", "Praxis Sommergarten"]
["5a2W0_NrlEZzfqmk_7Pq-w"、"管理センター"、"サマーガーデン実践"]
* Claim batchNumber:
* クレームバッチ番号:
- SHA-256 Hash:
- SHA-256 ハッシュ:
V7kJBLK78TmVDOmrfJ7ZuUPHuK_2cc7yZRa4qV1txwM
V7kJBLK78TmVDOmrfJ7ZuUPHuK_2cc7yZRa4qV1txwM
- Disclosure:
- 開示：
WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImJhdGNoTnVtYmVyIiwgIjE2MjY zODI3MzYiXQ
WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImJhdGNoTnVtYmVyIiwgIjE2MjY zODI3MzYiXQ
- Contents:
- コンテンツ：
["y1sVU5wdfJahVdgwPgS7RQ", "batchNumber", "1626382736"]
["y1sVU5wdfJahVdgwPgS7RQ"、"バッチ番号"、"1626382736"]
* Claim healthProfessional:
* 医療専門家に請求する:
- SHA-256 Hash:
- SHA-256 ハッシュ:
1V_K-8lDQ8iFXBFXbZY9ehqR4HabWCi5T0ybIzZPeww
1V_K-8lDQ8iFXBFXbZY9ehqR4HabWCi5T0ybIzZPeww
- Disclosure:
- 開示：
WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImhlYWx0aFByb2Zlc3Npb25hbCI sICI4ODMxMTAwMDAwMTUzNzYiXQ
WyJIYLE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImhlYWx0aFByb2Zlc3Npb25hbCI SICI4ODMxMTAwMDAwMTUzNzYiXQ
- Contents:
- コンテンツ：
["HbQ4X8srVW3QDxnIJdqyOA", "healthProfessional", "883110000015376"]
["HbQ4X8srVW3QDxnIJdqyOA"、"ヘルスプロフェッショナル"、"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:
これは、ワクチンの種類、医薬品製品名、atcCode、レシピエントの種類、タイプ、注文、およびワクチン接種の日付のみを開示する SD-JWT+KB の例です。
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:
検証後、検証者は次の処理された 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": {
"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"
}
}
}
The following Elliptic Curve public key, represented in JWK format, can be used to validate the Issuer signatures in the above examples:
JWK 形式で表される次の楕円曲線公開キーを使用して、上記の例の発行者の署名を検証できます。
{
"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.
キー バインディング JWT の検証に使用される公開キーは、cnf クレームの内容として例に示されています。
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.
セクション 4.2 で説明されているように、開示構造はソルトとクレームの平文コンテンツを含む JSON であり、base64url でエンコードされています。エンコードされた値は、それぞれのクレームのダイジェストを計算するために使用される入力です。署名された JWT にダイジェスト値を含めることで、クレーム値の整合性が保証されます。エンコードされたコンテンツを整合性メカニズムへの入力として使用することは、概念的には JWS のアプローチに似ており、JSON のようにコンテンツが異なる表現を持つことができるが、意味的には同等であるため、正規化が回避される場合に特に便利です。この設計上の決定に関する考慮事項については、さらに詳しく説明します。
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.
SD-JWT を受信する場合、検証者は、開示されたクレーム値のダイジェストを再計算でき、同じ入力値が与えられた場合、発行者によって署名されたのと同じダイジェスト値を取得できなければなりません。
Usually, JSON-based formats transport claim values as simple properties of a JSON object such as this:
通常、JSON ベースの形式は、次のような JSON オブジェクトの単純なプロパティとしてクレーム値を転送します。
...
"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
ただし、JSON はデータの一意のエンコードを規定していませんが、エンコードされた文字列のバリエーションは許容されています。たとえば、上記のデータは次のようにエンコードできます。
...
"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.
family_name の値の 2 つの表現はバイト レベルで大きく異なりますが、同等のオブジェクトを生成します。同じことがアドレスの表現にも当てはまり、オブジェクト内の空白と要素の順序が異なります。
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.
空白スペース、オブジェクトプロパティの順序付け、および Unicode 文字のエンコーディングのバリエーションはすべて、[RFC8785] で説明されている浮動小数点数に関するさらなるバリエーションを含め、JSON 仕様で許可されています。JSON データがシリアル化または逆シリアル化されるたびに変動が発生する可能性があり、これに対処しないと、異なるダイジェストが生成され、署名を検証できなくなります。
There are generally two approaches to deal with this problem:
この問題に対処するには、通常、次の 2 つのアプローチがあります。
1. Canonicalization: The data is transferred in JSON format, potentially introducing variations in its representation, but is transformed into a canonical form before computing a digest. Both the Issuer and the Verifier must use the same canonicalization algorithm to arrive at the same byte string for computing a digest.
1. 正規化: データは JSON 形式で転送されるため、表現にバリエーションが生じる可能性がありますが、ダイジェストを計算する前に正規形式に変換されます。発行者と検証者の両方は、ダイジェストを計算するために同じバイト文字列に到達するために、同じ正規化アルゴリズムを使用する必要があります。
2. Source string hardening: Instead of transferring data in a format that may introduce variations, a representation of the data is serialized. This representation is then used as the hashing input at the Verifier, but also transferred to the Verifier and used for the same digest calculation there. This means that the Verifier can easily compute and check the digest of the byte string before finally deserializing and accessing the data.
2. ソース文字列の強化: 変動を引き起こす可能性のある形式でデータを転送する代わりに、データの表現がシリアル化されます。この表現は検証者でハッシュ入力として使用されますが、検証者にも転送され、そこで同じダイジェスト計算に使用されます。これは、Verifier が最終的にデータを逆シリアル化してアクセスする前に、バイト文字列のダイジェストを簡単に計算してチェックできることを意味します。
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.
混合アプローチ、つまり、元の JSON データとダイジェストの計算に適した文字列の両方を転送することが考えられますが、そのようなアプローチでは、検出されない不一致が容易に発生し、その結果、チェック時、使用時タイプのセキュリティ脆弱性が発生する可能性があります。
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.
この仕様では、正規化ライブラリを必要とせずにシンプルで信頼性の高い相互運用性を可能にするソース文字列強化アプローチが使用されます。ソース文字列を強化するには、理論上、protobuf、msgpack、pickle など、必要なデータ型をサポートする任意のシリアル化形式を使用できます。この仕様では、JSON が使用され、各開示の平文コンテンツは、転送用に Base64url エンコードを使用してエンコードされます。このアプローチは、広く利用可能な JWT、JSON、および Base64 エンコードおよびデコード ライブラリに純粋に基づいて SD-JWT を実装できることを意味します。
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.
検証者は、元の JSON データを抽出する前に、ソース文字列のダイジェストを簡単にチェックできます。ダイジェストは JSON オブジェクトではなく事前定義されたバイト文字列に基づいて計算されるため、ソース文字列のエンコーディングの変動は検証者によって暗黙的に許容されます。
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.
開示内容は、検証者による検証後に開示されたクレーム値にアクセスする必要があるアプリケーションによる直接使用を意図したものでも、適切なものでもないことに注意することが重要です。開示情報は、検証者がソース文字列のダイジェストをチェックし、元の JSON データを抽出するために使用することのみを目的としています。元の JSON データはアプリケーションによって使用されます。詳細については、セクション 7.3 を参照してください。
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.
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 Prouß Mattsson、Joseph Heenan、Justin に感謝します。リッチャー、クシャール・ダス、マーティン・トムソン、マシュー・ミラー、マイケル・フレイザー、マイケル・B・ジョーンズ、マイク・プロロック、ナット・サキムラ、ニール・マッデン、オリバー・テルブ、オリー・スティール、ポール・バスティアン、ピーター・アルトマン、ピーター・カッセルマン、リチャード・バーンズ、ローハン・メイ、ローマン・ダニリュー、安部良輔、サミ・ローゼンダール、ショーン・バターフィールド、ショーン・エメリー、サイモン・シュルツ、貴彦Kawasaki 氏、Tobias Looker 氏、Torsten Lodderstedt 氏、Vittorio Bertocci 氏、Watson Ladd 氏、Yaron Sheffer 氏には、このドキュメントと初期の実装セットに対する貢献 (その一部は多大な貢献) に感謝します。
The work on this document was started at the OAuth Security Workshop 2022 in Trondheim, Norway.
このドキュメントの作業は、ノルウェーのトロンヘイムで開催された OAuth セキュリティ ワークショップ 2022 で開始されました。
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