RFC 9901 · 英日対訳
Selective Disclosure for JSON Web Tokens
英語本文は RFC Editor が公開した RFC そのもので、著作権は IETF Trust と文書の著者にあり、IETF Trust Legal Provisions に基づいて転載している。日本語は非公式の機械翻訳で、正文は英語のみ。例・図・参考文献は英語のまま表示する。
76% の段落を翻訳済み · 機械翻訳: Claude Fable 5.1 · 2026-11-13
目次
- 概要
- 1 はじめに
- 1.1 機能の概要
- 1.2 表記規約と用語
- 2 フロー図
- 3 概念
- 3.1 SD-JWT とディスクロージャ
- 3.2 検証者への開示
- 3.3 任意の鍵バインディング
- 3.4 検証
- 4 SD-JWT および SD-JWT+KB のデータフォーマット
- 4.1 発行者署名付き JWT
- 4.1.1 ハッシュ関数クレーム
- 4.1.2 鍵バインディング
- 4.2 ディスクロージャ
- 4.2.1 オブジェクトプロパティのディスクロージャ
- 4.2.2 配列要素のディスクロージャ
- 4.2.3 ディスクロージャのハッシュ化
- 4.2.4 SD-JWT へのディスクロージャダイジェストの埋め込み
- 4.2.4.1 オブジェクトプロパティ
- 4.2.4.2 配列要素
- 4.2.5 デコイダイジェスト
- 4.2.6 再帰的ディスクロージャ
- 4.3 鍵バインディング JWT
- 4.3.1 SD-JWT へのバインディング
- 4.3.2 鍵バインディング JWT の検証
- 5 SD-JWT の例
- 5.1 発行
- 5.2 提示
- 6 SD-JWT におけるネストしたデータに関する考慮事項
- 6.1 例: フラットな SD-JWT
- 6.2 例: 構造化された SD-JWT
- 6.3 例: 再帰的な Disclosure を持つ SD-JWT
- 7 検証と処理
- 7.1 SD-JWT の検証
- 7.2 保持者による処理
- 7.3 検証者による検証
- 8 JWS JSON シリアライゼーション
- 8.1 新しい非保護ヘッダーパラメータ
- 8.2 Flattened JSON シリアライゼーション
- 8.3 General JSON シリアライゼーション
- 8.4 JWS JSON シリアライズされた SD-JWT の検証
- 9 セキュリティに関する考慮事項
- 9.1 発行者署名付き JWT の署名の必須化
- 9.2 Disclosure の改ざん
- 9.3 ソルトのエントロピー
- 9.4 ハッシュアルゴリズムの選択
- 9.5 Key Binding
- 9.6 クレーム名の秘匿
- 9.7 選択的に開示可能な有効性クレーム
- 9.8 発行者の署名検証鍵の配布とローテーション
- 9.9 クレデンシャルの転送
- 9.10 SD-JWT と SD-JWT+KB の完全性
- 9.11 明示的な型付け
- 9.12 鍵ペアの生成とライフサイクル管理
- 10 プライバシーに関する考慮事項
- 10.1 非連結性
- 10.2 ユーザーデータの保存
- 10.3 転送中の機密性
- 10.4 デコイダイジェスト
- 10.5 発行者識別子
- 11 IANA に関する考慮事項
- 11.1 JSON Web Token クレームの登録
- 11.2 メディアタイプの登録
- 11.2.1 SD-JWT コンテンツ
- 11.2.2 JWS JSON シリアライズされた SD-JWT コンテンツ
- 11.2.3 Key Binding JWT コンテンツ
- 11.3 構造化構文サフィックスの登録
- 12 参考資料
- 12.1 引用規格
- 12.2 参考文献
- A 追加の例
- A.1 単純な構造化 SD-JWT
- A.2 複雑な構造化 SD-JWT
- A.3 SD-JWT ベースの Verifiable Credentials (SD-JWT VC)
- A.4 W3C Verifiable Credentials Data Model v2.0
- A.5 例で使用した楕円曲線鍵
- B Disclosure の形式に関する考慮事項
- 謝辞
Abstract
概要
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 Signature (JWS) のペイロードとして用いられる JSON データ構造の個々の要素を選択的に開示するための仕組みを定義する。主たるユースケースは JSON Web Token (JWT) のクレームの選択的開示である。
1.Introduction
1.はじめに
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 Signature (JWS) [RFC7515] を用いて改変から保護されることが多い。JWS の普及した応用の一つが 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 をさまざまな検証当事者 (検証者) に提示できるが、各検証者は JWT 内のクレームの部分集合しか必要としないかもしれない。例えば、JWT が住所と生年月日の両方を表すクレームを含むとする。ホルダーは、ある検証者には住所のみを、別の検証者には生年月日のみを開示することを選べる。
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.
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」と呼ぶ。
1.1.Feature Summary
1.1.機能の概要
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.
* A mechanism for associating an SD-JWT with a key pair.
* 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 フォーマットを拡張したフォーマット。
1.2.Conventions and Terminology
1.2.表記規約と用語
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: Denotes the URL-safe base64 encoding without padding defined in Section 2 of [RFC7515].
Base64url: [RFC7515] の 2 節で定義される、パディングなしの URL セーフな base64 エンコーディングを指す。
Claim: In this document, refers generally to object properties (name/ value pairs) as well as array elements.
クレーム (Claim): 本書では、オブジェクトプロパティ (名前/値ペア) および配列要素の総称として用いる。
Selective Disclosure: Process of a Holder disclosing to a Verifier a subset of claims contained in a JWT issued by an Issuer.
選択的開示 (Selective Disclosure): 発行者が発行した JWT に含まれるクレームの部分集合を、ホルダーが検証者に開示するプロセス。
Selectively Disclosable 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.
Selectively Disclosable JWT (SD-JWT): 発行者署名付き 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.
ディスクロージャ (Disclosure): ソルト、クレーム名 (クレームが名前/値ペアの場合に存在し、配列要素の場合は存在しない)、およびクレーム値を含む 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).
鍵バインディング (Key Binding): 提示の際に秘密鍵の管理を証明することで、ホルダーが SD-JWT の所有を証明できること。鍵バインディングを利用する場合、SD-JWT はホルダーが管理する秘密鍵に対応する公開鍵 (またはその公開鍵への参照) を含む。
Key Binding 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 (KB-JWT): 鍵バインディング JWT は、そのペイロードが SD-JWT ペイロードに含まれる鍵で署名され、かつ KB-JWT がその sd_hash クレームに SD-JWT のハッシュを含むとき、その特定の SD-JWT に「結び付けられている (tied to)」という。そのフォーマットは 4.3 節で定義する。
Selectively Disclosable JWT with Key Binding (SD-JWT+KB): A composite structure, comprising an SD-JWT and a Key Binding JWT tied to that SD-JWT.
鍵バインディング付き Selectively Disclosable JWT (SD-JWT+KB): SD-JWT と、その SD-JWT に結び付けられた鍵バインディング JWT からなる複合構造。
Processed SD-JWT Payload: 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 ペイロード (Processed SD-JWT Payload): 発行者署名付き SD-JWT の検証と処理の結果として得られる JSON オブジェクトで、ダイジェストのプレースホルダがディスクロージャから得た対応する値に置き換えられたもの。
Issuer: An entity that creates SD-JWTs.
発行者 (Issuer): 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.
ホルダー (Holder): 発行者から SD-JWT を受け取り、それを管理するエンティティ。本書の文脈では、この用語は実際のユーザー、ユーザーが所持する支援ハードウェアおよびソフトウェア、またはその両方を指すことがある。
Verifier: An entity that requests, checks, and extracts the claims from an SD-JWT with its respective Disclosures.
検証者 (Verifier): SD-JWT とそれに対応するディスクロージャを要求し、確認し、そこからクレームを抽出するエンティティ。
2.Flow Diagram
2.フロー図
+------------+
| |
| 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
3.Concepts
3.概念
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 とそれに対応するディスクロージャおよび鍵バインディングを概念レベルで説明する。
3.1.SD-JWT and Disclosures
3.1.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)。
3.2.Disclosing to a Verifier
3.2.検証者への開示
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 の一部として検証者に送る。
3.3.Optional Key Binding
3.3.任意の鍵バインディング
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.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 節で記述する。
3.4.Verification
3.4.検証
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 節で記述する。
4.SD-JWT and SD-JWT+KB Data Formats
4.SD-JWT および SD-JWT+KB のデータフォーマット
An SD-JWT is composed of
SD-JWT は以下から構成される
* an Issuer-signed JWT, and
* 発行者署名付き JWT、および
* zero or more Disclosures.
* 0 個以上のディスクロージャ。
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>~
<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 でなければならない (MUST)。鍵バインディング JWT がない場合、最後の要素は空文字列でなければならず (MUST)、最後の区切りチルダ文字を省略してはならない (MUST NOT)。
The serialized format for an SD-JWT+KB extends the SD-JWT format by concatenating a Key Binding JWT.
SD-JWT+KB のシリアライズ形式は、SD-JWT の形式に鍵バインディング JWT を連結して拡張したものである。
<Issuer-signed JWT>~<D.1>~<D.2>~...~<D.N>~<KB-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 に含まれるダイジェスト値を通じて、その 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.
ホルダーはディスクロージャの任意の部分集合、すなわち、ゼロ個、一部、またはすべてのディスクロージャを検証者に送ってよい (MAY)。ホルダーが検証者に明かしたくないデータについては、ホルダーはディスクロージャを送ったり、その他いかなる方法でもソルト値を明かしたりしてはならない (MUST NOT)。ホルダーは、発行された SD-JWT に含まれていなかったディスクロージャを送ったり、同じディスクロージャを複数回送ったりしてはならない (MUST NOT)。
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>~
<Issuer-signed JWT>~
An SD-JWT with Disclosures:
ディスクロージャのある SD-JWT:
<Issuer-signed JWT>~<Disclosure 1>~<Disclosure N>~
<Issuer-signed JWT>~<Disclosure 1>~<Disclosure N>~
An SD-JWT+KB without Disclosures:
ディスクロージャのない SD-JWT+KB:
<Issuer-signed JWT>~<KB-JWT>
<Issuer-signed JWT>~<KB-JWT>
An SD-JWT+KB with Disclosures:
ディスクロージャのある SD-JWT+KB:
<Issuer-signed JWT>~<Disclosure 1>~<Disclosure N>~<KB-JWT>
<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
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z DIGIT = %x30-39 ; 0-9 BASE64URL = 1*(ALPHA / DIGIT / "-" / "_") JWT = BASE64URL "." BASE64URL "." BASE64URL DISCLOSURE = BASE64URL SD-JWT = JWT "~" *(DISCLOSURE "~") KB-JWT = JWT SD-JWT-KB = SD-JWT KB-JWT
4.1.Issuer-Signed JWT
4.1.発行者署名付き 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 は、発行者の秘密鍵で署名されなければならない (MUST) JWT 構成要素を持つ。none アルゴリズムを用いてはならない (MUST NOT)。
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 つ以上の常時開示されるクレームを含んでよい (MAY)。
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 節で説明するように、ホルダーの公開鍵またはその参照を 1 つ以上含んでよい (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 に含められる。
4.1.1.Hash Function Claim
4.1.1.ハッシュ関数クレーム
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 ペイロードのトップレベルに現れなければならない (MUST)。ペイロード内にネストされたいかなるオブジェクトの中でも用いてはならない (MUST NOT)。_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.
このクレーム値は、ハッシュアルゴリズム識別子を持つ大文字小文字を区別する文字列である。ハッシュアルゴリズム識別子は、「Named Information Hash Algorithm Registry」[Hash.Algs] の「Hash Name String」列にあるハッシュアルゴリズム値、または本仕様の他の仕様および/またはプロファイルで定義された値でなければならない (MUST)。
To promote interoperability, implementations MUST support the sha-256 hash algorithm.
相互運用性を促進するため、実装は sha-256 ハッシュアルゴリズムをサポートしなければならない (MUST)。
See Section 9 for requirements regarding entropy of the salt, minimum length of the salt, and choice of a hash algorithm.
ソルトのエントロピー、ソルトの最小長、およびハッシュアルゴリズムの選択に関する要件については 9 節を参照。
4.1.2.Key Binding
4.1.2.鍵バインディング
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.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.
ホルダーの鍵ペアがどのように確立されるかを記述することは本書の範囲外である。例えば、ホルダーが鍵ペアを作成して公開鍵を発行者に提供してもよく (MAY)、発行者がホルダーのために鍵ペアを作成してもよく (MAY)、あるいはホルダーと発行者が事前に確立された鍵素材を用いてもよい (MAY)。
| 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.4.2.Disclosures
4.2.ディスクロージャ
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 節に記述するとおりにディスクロージャを作成する。
4.2.1.Disclosures for Object Properties
4.2.1.オブジェクトプロパティのディスクロージャ
For each claim that is an object property and that is to be made selectively disclosable, the Issuer MUST create a Disclosure as follows:
オブジェクトプロパティであり、選択的に開示可能にするクレームのそれぞれについて、発行者は以下のようにディスクロージャを作成しなければならない (MUST):
* 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. ソルト値。文字列でなければならない (MUST)。セキュリティに関する考慮事項は 9.3 節を参照。推奨されるソルトのエントロピーを達成するために、発行者は暗号学的に安全な 128 ビットのランダムデータを base64url エンコードして文字列を生成できる。ソルト値は、選択的に開示されるクレームごとに一意でなければならない (MUST)。発行者はホルダー以外のいかなる当事者にもソルト値を明かしてはならない (MUST NOT)。
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 ペイロードで用いられるのと同じクレーム名 (キー)。文字列でなければならず (MUST)、_sd、...、またはそのオブジェクト内に常時開示されるクレームとして存在するクレーム名であってはならない (MUST NOT)。
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.The following example illustrates the steps described above.
以下の例は、上述の手順を示す。
The array is created as follows:
配列は以下のように作成される:
["_26bc4LT-ac6q2KI6cBW5es", "family_name", "Möbius"]
["_26bc4LT-ac6q2KI6cBW5es", "family_name", "Möbius"]
The resultant Disclosure is:
結果として得られるディスクロージャは以下である:
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* No white space:
* 空白なし:
WyJfMjZiYzRMVC1hYzZxMktJNmNCVzVlcyIsImZhbWlseV9uYW1lIiwiTcO2Yml1cy
Jd* Newline characters between elements:
* 要素間に改行文字を入れたもの:
WwoiXzI2YmM0TFQtYWM2cTJLSTZjQlc1ZXMiLAoiZmFtaWx5X25hbWUiLAoiTcO2Ym
l1cyIKXQHowever, 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 を参照。
4.2.2.Disclosures for Array Elements
4.2.2.配列要素のディスクロージャ
For each claim that is an array element and that is to be made selectively disclosable, the Issuer MUST create a Disclosure as follows:
配列要素であり、選択的に開示可能にするクレームのそれぞれについて、発行者は以下のようにディスクロージャを作成しなければならない (MUST):
* The array MUST contain two elements in this order:
* 配列は以下の順序で 2 つの要素を含まなければならない (MUST):
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 クレームセットの nationalities 配列の 2 番目の要素に対するディスクロージャは:
{
"nationalities": ["DE", "FR", "US"]
}could be created by first creating the following array:
まず以下の配列を作成することで作成できる:
["lklxF5jMYlGTPUovMNIvCA", "FR"]
["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.3.Hashing Disclosures
4.2.3.ディスクロージャのハッシュ化
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 エンコードされたディスクロージャでなければならず (MUST)、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 エンコードされなければならず (MUST)、ダイジェストのバイト列の (ときに用いられる) 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.4.Embedding Disclosure Digests in SD-JWTs
4.2.4.SD-JWT へのディスクロージャダイジェストの埋め込み
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 節に記述するとおりにディスクロージャダイジェストを作成する。
4.2.4.1.Object Properties
4.2.4.1.オブジェクトプロパティ
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 キーは、トップレベル、6 節に記述するようにより深くネストされた位置、あるいは 4.2.6 節に記述する再帰的ディスクロージャの中など、JSON オブジェクト階層の任意のレベルに存在できる。
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 キーを省略することが推奨される (RECOMMENDED)。
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.
発行者は配列内のクレームの元の順序を隠さなければならない (MUST)。これを保証するため、4.2.5 節に記述するデコイダイジェストを追加する可能性があるならその後に、例えば英数字順またはランダムに並べ替えるなどして、ハッシュの配列をシャッフルすることが推奨される (RECOMMENDED)。要素の元の順序に依存しない限り、正確な方法は問わない。
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 節のディスクロージャのダイジェストを用いて、発行者は family_name を選択的に開示可能にするために以下の SD-JWT ペイロードを作成できる:
{
"given_name": "Alice",
"_sd": ["X9yH0Ajrdm1Oij4tWso9UzzKJvPoDxwmuEcO3XAdRC0"]
}4.2.4.2.Array Elements
4.2.4.2.配列要素
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 つのドット) でなければならない (MUST)。値は 4.2.3 節に記述したとおりに作成されたディスクロージャのダイジェストでなければならない (MUST)。そのオブジェクトに他のキーがあってはならない (MUST NOT)。文字列 ... が選ばれたのは、通常 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 節で作成した配列要素のディスクロージャのダイジェストを用いて、発行者は nationalities 配列の 2 番目の要素を選択的に開示可能にするために以下の SD-JWT ペイロードを作成できる:
{
"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"] となる。
4.2.5.Decoy Digests
4.2.5.デコイダイジェスト
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.
デコイダイジェストは、暗号学的に安全な乱数をハッシュ化して作成することが推奨される (RECOMMENDED)。その後、ダイジェストのバイト列は上記と同様に base64url エンコードされなければならない (MUST)。ディスクロージャに用いるものと同じダイジェスト関数を用いなければならない (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 を参照。
4.2.6.Recursive Disclosures
4.2.6.再帰的ディスクロージャ
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:
上記のアルゴリズムは「再帰的ディスクロージャ」と互換性がある。これは、選択的に開示されたあるフィールドが、さらに選択的に開示可能なフィールドの存在を明らかにするものである。例えば、以下の 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.
ホルダーが複数の国籍を持つ場合、発行者は国籍に関するいかなる記述の存在も隠しつつ、ホルダーがそれらの国籍を個別に明かせるようにしたいかもしれない。これは、まず "nationalities" 配列内の各エントリを選択的に開示可能にし、次に "nationalities" フィールド全体を選択的に開示可能にすることで実現できる。
The following shows each of the entries within the "nationalities" array being made selectively disclosable:
以下は、"nationalities" 配列内の各エントリが選択的に開示可能にされた様子を示す:
{
"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"]
PmnlrRj... = ["16_mAd0GiwaZokU26_0i0h","DE"] r823HFN... = ["fn9fN0rD-fFs2n303ZI-0c","FR"] nP5GYjw... = ["YIKesqOkXXNzMQtsX_-_lw","UK"]
Followed by making the whole "nationalities" array selectively disclosable:
続いて "nationalities" 配列全体を選択的に開示可能にする:
{
"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.
このディスクロージャの集合により、ホルダーは "DE" の国籍だけを開示するためにハッシュ PmnlrRj... のディスクロージャを含めることも、"DE" と "FR" の両方の国籍を開示しつつ "UK" の国籍を隠すために PmnlrRj... と r823HFN... の両方を含めることもできる。いずれの場合も、ホルダーは対応する要素を含む nationalities フィールドを開示するために、ハッシュ 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 内のディスクロージャオブジェクト間に依存関係が生じることに注意されたい。r823HFN... のディスクロージャは 5G1srw3... のディスクロージャなしには使えない。検証者は、r823HFN... のディスクロージャの内容をどこに挿入すべきかを示す対応するハッシュを持たないからである。あるディスクロージャオブジェクトが SD-JWT に含まれる場合、その SD-JWT は、最初のディスクロージャオブジェクトを処理するために必要な他のすべてのディスクロージャオブジェクトを含まなければならない (MUST)。言い換えれば、SD-JWT 内のいかなるディスクロージャオブジェクトも、場合によっては中間のディスクロージャオブジェクトを介して、発行者署名付き JWT 内のクレームに「接続」していなければならない。上の例では、5G1srw3... のディスクロージャオブジェクトを含めずに PmnlrRj...、r823HFN...、nP5GYjw... のディスクロージャオブジェクトのいずれかを含めることは不正となる。
4.3.Key Binding JWT
4.3.鍵バインディング JWT
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 でなければならず (MUST)、以下の要素を含まなければならない (MUST):
* 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].
- typ: REQUIRED。kb+jwt でなければならず (MUST)、これは [RFC8725] の 3.11 節で推奨されているとおり、鍵バインディング 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: REQUIRED。IANA の「JSON Web Signature and Encryption Algorithms」レジストリにあるようなデジタル署名アルゴリズム識別子。"none" であってはならない (MUST NOT)。
* 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: REQUIRED。このクレームの値は、[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: REQUIRED。値は、鍵バインディング JWT の意図された受信者を識別する単一の文字列でなければならない (MUST)。値をどのように表現するかは用いるプロトコルに委ねられ、本仕様の範囲外である。
- "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.
- "nonce": REQUIRED。署名の新鮮性、または当該トランザクションへの署名の結び付きを保証する。このクレームの値の型は文字列でなければならない (MUST)。この値をどのように取得するかは用いるプロトコルに委ねられ、本仕様の範囲外である。
- sd_hash: REQUIRED. The base64url-encoded hash value over the Issuer-signed JWT and the selected Disclosures as defined below.
- sd_hash: REQUIRED。以下で定義する、発行者署名付き 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 に加えることができる。しかし、やむを得ない理由がない限り、相互運用性を損ない概念的な整合性に負担をかける可能性があるため、これは避けるべきである (SHOULD)。
4.3.1.Binding to an SD-JWT
4.3.1.SD-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 バイト列に対して計算されなければならない (MUST):
<Issuer-signed JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclosure N>~
<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).
ディスクロージャに用いるものと同じハッシュアルゴリズムを用いなければならない (MUST) (発行者署名付き JWT の _sd_alg 要素で定義されるか、4.1.1 節で定義されるデフォルト値)。
4.3.2.Validating the Key Binding JWT
4.3.2.鍵バインディング JWT の検証
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 にホルダーの公開鍵として指定された鍵であることを確実にしなければならない (MUST)。例えば、SD-JWT が jwk メンバーを持つ cnf 値を含む場合、検証者は提供された JWK を解析し、それを用いて鍵バインディング JWT を検証することになる。
Details of the validation process are defined in Section 7.3.
検証プロセスの詳細は 7.3 節で定義する。
5.Example SD-JWT
5.SD-JWT の例
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.5.1.Issuance
5.1.発行
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.
* nationalities 配列は常に可視であるが、その内容は選択的に開示可能である。
* The sub element as well as essential verification data (iss, exp, cnf, etc.) are always visible.
* sub 要素、および必須の検証データ (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.
* address については、発行者はフラットな構造を用いている。すなわち、address クレーム内のすべてのクレームは全体としてのみ開示できる。その他の選択肢は 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:".
発行者が作成した対応する Disclosure を以下に列挙する。以下の文中およびこの仕様の他の箇所では、ラベル "SHA-256 Hash:" を、ラベル "Base64url-Encoded SHA-256 Hash:" の省略形として用いる。
* Claim given_name:
* クレーム given_name:
- SHA-256 Hash:
- SHA-256 ハッシュ:
jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4
- Disclosure:
- Disclosure:
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9obiJ
d- Contents:
- 内容:
["2GLC42sKQveCfGfryNRN9w", "given_name", "John"]
* Claim family_name:
* クレーム family_name:
- SHA-256 Hash:
- SHA-256 ハッシュ:
TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo
- Disclosure:
- Disclosure:
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIkRvZSJ
d- Contents:
- 内容:
["eluV5Og3gSNII8EYnsxA_A", "family_name", "Doe"]
* Claim email:
* クレーム email:
- SHA-256 Hash:
- SHA-256 ハッシュ:
JzYjH4svliH0R3PyEMfeZu6Jt69u5qehZo7F7EPYlSE
- Disclosure:
- Disclosure:
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImVtYWlsIiwgImpvaG5kb2VAZXh
hbXBsZS5jb20iXQ- Contents:
- 内容:
["6Ij7tM-a5iVPGboS5tmvVA", "email", "johndoe@example.com"]
* Claim phone_number:
* クレーム phone_number:
- SHA-256 Hash:
- SHA-256 ハッシュ:
PorFbpKuVu6xymJagvkFsFXAbRoc2JGlAUA2BA4o7cI
- Disclosure:
- Disclosure:
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInBob25lX251bWJlciIsICIrMS0
yMDItNTU1LTAxMDEiXQ- Contents:
- 内容:
["eI8ZWm9QnKPpNPeNenHdhQ", "phone_number", "+1-202-555-0101"]
* Claim phone_number_verified:
* クレーム phone_number_verified:
- SHA-256 Hash:
- SHA-256 ハッシュ:
XQ_3kPKt1XyX7KANkqVR6yZ2Va5NrPIvPYbyMvRKBMM
- Disclosure:
- Disclosure:
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJlcl92ZXJpZml
lZCIsIHRydWVd- Contents:
- 内容:
["Qg_O64zqAxe412a108iroA", "phone_number_verified", true]
* Claim address:
* クレーム address:
- SHA-256 Hash:
- SHA-256 ハッシュ:
XzFrzwscM6Gn6CJDc6vVK8BkMnfG8vOSKfpPIZdAfdE
- Disclosure:
- Disclosure:
WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImFkZHJlc3MiLCB7InN0cmVldF9
hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRvd24iLC
AicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0- Contents:
- 内容:
["AJx-095VPrpTtN4QMOqROA", "address", {"street_address": "123
Main St", "locality": "Anytown", "region": "Anystate",
"country": "US"}]* Claim birthdate:
* クレーム birthdate:
- SHA-256 Hash:
- SHA-256 ハッシュ:
gbOsI4Edq2x2Kw-w5wPEzakob9hV1cRD0ATN3oQL9JM
- Disclosure:
- Disclosure:
WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImJpcnRoZGF0ZSIsICIxOTQwLTA
xLTAxIl0- Contents:
- 内容:
["Pc33JM2LchcU_lHggv_ufQ", "birthdate", "1940-01-01"]
* Claim updated_at:
* クレーム updated_at:
- SHA-256 Hash:
- SHA-256 ハッシュ:
CrQe7S5kqBAHt-nMYXgc6bdt2SH5aTY1sU_M-PgkjPI
- Disclosure:
- Disclosure:
WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInVwZGF0ZWRfYXQiLCAxNTcwMDA
wMDAwXQ- Contents:
- 内容:
["G02NSrQfjFXQ7Io09syajA", "updated_at", 1570000000]
* Array Entry:
* 配列要素:
- SHA-256 Hash:
- SHA-256 ハッシュ:
pFndjkZ_VCzmyTa6UjlZo3dh-ko8aIKQc9DlGzhaVYo
- Disclosure:
- Disclosure:
WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIlVTIl0
- Contents:
- 内容:
["lklxF5jMYlGTPUovMNIvCA", "US"]
* Array Entry:
* 配列要素:
- SHA-256 Hash:
- SHA-256 ハッシュ:
7Cf6JkPudry3lcbwHgeZ8khAv1U1OSlerP0VkBJrWZ0
- Disclosure:
- Disclosure:
WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIkRFIl0
- Contents:
- 内容:
["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:
Disclosure を追加すると、次の SD-JWT が得られる:
eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb IkNyUWU3UzVrcUJBSHQtbk1ZWGdjNmJkdDJTSDVhVFkxc1VfTS1QZ2tqUEkiLCAiSnpZ akg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQWWxTRSIsICJQb3JGYnBL dVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1 SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAiWFFfM2tQS3QxWHlYN0tB TmtxVlI2eVoyVmE1TnJQSXZQWWJ5TXZSS0JNTSIsICJYekZyendzY002R242Q0pEYzZ2 Vks4QmtNbmZHOHZPU0tmcFBJWmRBZmRFIiwgImdiT3NJNEVkcTJ4Mkt3LXc1d1BFemFr b2I5aFYxY1JEMEFUTjNvUUw5Sk0iLCAianN1OXlWdWx3UVFsaEZsTV8zSmx6TWFTRnpn bGhRRzBEcGZheVF3TFVLNCJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAic3ViIjog InVzZXJfNDIiLCAibmF0aW9uYWxpdGllcyI6IFt7Ii4uLiI6ICJwRm5kamtaX1ZDem15 VGE2VWpsWm8zZGgta284YUlLUWM5RGxHemhhVllvIn0sIHsiLi4uIjogIjdDZjZKa1B1 ZHJ5M2xjYndIZ2VaOGtoQXYxVTFPU2xlclAwVmtCSnJXWjAifV0sICJfc2RfYWxnIjog InNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0y NTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VH ZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlG MkhaUSJ9fX0.MczwjBFGtzf-6WMT-hIvYbkb11NrV1WMO-jTijpMPNbswNzZ87wY2uHz -CXo6R04b7jYrpj9mNRAvVssXou1iw~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgI mdpdmVuX25hbWUiLCAiSm9obiJd~WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZh bWlseV9uYW1lIiwgIkRvZSJd~WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImVtYWl sIiwgImpvaG5kb2VAZXhhbXBsZS5jb20iXQ~WyJlSThaV205UW5LUHBOUGVOZW5IZGhR IiwgInBob25lX251bWJlciIsICIrMS0yMDItNTU1LTAxMDEiXQ~WyJRZ19PNjR6cUF4Z TQxMmExMDhpcm9BIiwgInBob25lX251bWJlcl92ZXJpZmllZCIsIHRydWVd~WyJBSngt MDk1VlBycFR0TjRRTU9xUk9BIiwgImFkZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjog IjEyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRvd24iLCAicmVnaW9uIjogIkFu eXN0YXRlIiwgImNvdW50cnkiOiAiVVMifV0~WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZR IiwgImJpcnRoZGF0ZSIsICIxOTQwLTAxLTAxIl0~WyJHMDJOU3JRZmpGWFE3SW8wOXN5 YWpBIiwgInVwZGF0ZWRfYXQiLCAxNTcwMDAwMDAwXQ~WyJsa2x4RjVqTVlsR1RQVW92T U5JdkNBIiwgIlVTIl0~WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIkRFIl0~
5.2.Presentation
5.2.提示
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 つの Disclosure (クレーム given_name、family_name、address、および nationalities のうちの 1 つ)、末尾の要素として Key Binding JWT が置かれていることに注意されたい。
eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb IkNyUWU3UzVrcUJBSHQtbk1ZWGdjNmJkdDJTSDVhVFkxc1VfTS1QZ2tqUEkiLCAiSnpZ akg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQWWxTRSIsICJQb3JGYnBL dVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJIiwgIlRHZjRvTGJnd2Q1 SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAiWFFfM2tQS3QxWHlYN0tB TmtxVlI2eVoyVmE1TnJQSXZQWWJ5TXZSS0JNTSIsICJYekZyendzY002R242Q0pEYzZ2 Vks4QmtNbmZHOHZPU0tmcFBJWmRBZmRFIiwgImdiT3NJNEVkcTJ4Mkt3LXc1d1BFemFr b2I5aFYxY1JEMEFUTjNvUUw5Sk0iLCAianN1OXlWdWx3UVFsaEZsTV8zSmx6TWFTRnpn bGhRRzBEcGZheVF3TFVLNCJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAic3ViIjog InVzZXJfNDIiLCAibmF0aW9uYWxpdGllcyI6IFt7Ii4uLiI6ICJwRm5kamtaX1ZDem15 VGE2VWpsWm8zZGgta284YUlLUWM5RGxHemhhVllvIn0sIHsiLi4uIjogIjdDZjZKa1B1 ZHJ5M2xjYndIZ2VaOGtoQXYxVTFPU2xlclAwVmtCSnJXWjAifV0sICJfc2RfYWxnIjog InNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0y NTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VH ZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlG MkhaUSJ9fX0.MczwjBFGtzf-6WMT-hIvYbkb11NrV1WMO-jTijpMPNbswNzZ87wY2uHz -CXo6R04b7jYrpj9mNRAvVssXou1iw~WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgI mZhbWlseV9uYW1lIiwgIkRvZSJd~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImFk ZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjogIjEyMyBNYWluIFN0IiwgImxvY2FsaXR5 IjogIkFueXRvd24iLCAicmVnaW9uIjogIkFueXN0YXRlIiwgImNvdW50cnkiOiAiVVMi fV0~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9obiJd ~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIlVTIl0~eyJhbGciOiAiRVMyNTYiLCA idHlwIjogImtiK2p3dCJ9.eyJub25jZSI6ICIxMjM0NTY3ODkwIiwgImF1ZCI6ICJodH RwczovL3ZlcmlmaWVyLmV4YW1wbGUub3JnIiwgImlhdCI6IDE3NDg1MzcyNDQsICJzZF 9oYXNoIjogIjBfQWYtMkItRWhMV1g1eWRoX3cyeHp3bU82aU02NkJfMlFDRWFuSTRmVV kifQ.T3SIus2OidNl41nmVkTZVCKKhOAX97aOldMyHFiYjHm261eLiJ1YiuONFiMN8Ql CmYzDlBLAdPvrXh52KaLgUQ
The following Key Binding JWT payload was created and signed for this presentation by the Holder:
この提示のために、保持者は次の Key Binding 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.
検証者が Key Binding を要求していなければ、保持者は SD-JWT+KB に包むことなく、選択した Disclosure を付けた 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"
}6.Considerations on Nested Data in SD-JWTs
6.SD-JWT におけるネストしたデータに関する考慮事項
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 ペイロード内のオブジェクトは、値が別のオブジェクトである名前/値ペアを含んでもよく (MAY)、またオブジェクトが配列の要素であってもよい (MAY)。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 内に複数回現れてもよく (MAY)、同様に、階層内にそれぞれ選択的に開示可能な要素を持つ配列が複数存在してもよい (MAY)。選択的に開示可能なクレームのダイジェストは、他の Disclosure の中に現れることさえある (MAY)。
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.6.1.Example: Flat SD-JWT
6.1.例: フラットな 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.
発行者は、address クレームを、全体を開示するか全く開示しないかのいずれかしかできないブロックとして扱うことを決定できる。以下の例は、この場合に address クレーム全体が Disclosure 内で 1 つのオブジェクトとして扱われることを示す。
{
"_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 つのハッシュから参照される次の Disclosure を作成することになる:
* Claim address:
* クレーム address:
- SHA-256 Hash:
- SHA-256 ハッシュ:
fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do
- Disclosure:
- Disclosure:
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImFkZHJlc3MiLCB7InN0cmVldF9
hZGRyZXNzIjogIlNjaHVsc3RyLiAxMiIsICJsb2NhbGl0eSI6ICJTY2h1bHBmb3
J0YSIsICJyZWdpb24iOiAiU2FjaHNlbi1BbmhhbHQiLCAiY291bnRyeSI6ICJER
SJ9XQ- Contents:
- 内容:
["2GLC42sKQveCfGfryNRN9w", "address", {"street_address": "Schulstr. 12", "locality": "Schulpforta", "region": "Sachsen- Anhalt", "country": "DE"}]
["2GLC42sKQveCfGfryNRN9w", "address", {"street_address": "Schulstr. 12", "locality": "Schulpforta", "region": "Sachsen- Anhalt", "country": "DE"}]
6.2.Example: Structured SD-JWT
6.2.例: 構造化された SD-JWT
The Issuer may instead decide to make the address claim contents selectively disclosable individually:
発行者は代わりに、address クレームの内容を個別に選択的に開示可能にすることを決定してもよい:
{
"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:
この場合、発行者は address の下位クレームの Disclosure に次のデータを用いることになる:
* Claim street_address:
* クレーム street_address:
- SHA-256 Hash:
- SHA-256 ハッシュ:
9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM
- Disclosure:
- Disclosure:
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN0cmVldF9hZGRyZXNzIiwgIlN
jaHVsc3RyLiAxMiJd- Contents:
- 内容:
["2GLC42sKQveCfGfryNRN9w", "street_address", "Schulstr. 12"]
* Claim locality:
* クレーム locality:
- SHA-256 Hash:
- SHA-256 ハッシュ:
6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0
- Disclosure:
- Disclosure:
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImxvY2FsaXR5IiwgIlNjaHVscGZ
vcnRhIl0- Contents:
- 内容:
["eluV5Og3gSNII8EYnsxA_A", "locality", "Schulpforta"]
* Claim region:
* クレーム region:
- SHA-256 Hash:
- SHA-256 ハッシュ:
KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88
- Disclosure:
- Disclosure:
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInJlZ2lvbiIsICJTYWNoc2VuLUF
uaGFsdCJd- Contents:
- 内容:
["6Ij7tM-a5iVPGboS5tmvVA", "region", "Sachsen-Anhalt"]
* Claim country:
* クレーム country:
- SHA-256 Hash:
- SHA-256 ハッシュ:
WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM
- Disclosure:
- Disclosure:
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImNvdW50cnkiLCAiREUiXQ
- Contents:
- 内容:
["eI8ZWm9QnKPpNPeNenHdhQ", "country", "DE"]
The Issuer may also make one sub-claim of address permanently disclosed and hide only the other sub-claims:
発行者はまた、address の下位クレームのうち 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.
この場合、country は平文で提供されるため、country に対する Disclosure は存在しない。
6.3.Example: SD-JWT with Recursive Disclosures
6.3.例: 再帰的な Disclosure を持つ SD-JWT
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:
発行者はまた、address クレームの内容を再帰的に選択的に開示可能にすることを決定してもよい。すなわち、address クレーム自体とその下位クレームの両方を選択的に開示可能にする:
{
"_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:
発行者はまず下位クレームの Disclosure を作成し、次にそれらのダイジェストを address クレームの Disclosure に含める:
* Claim street_address:
* クレーム street_address:
- SHA-256 Hash:
- SHA-256 ハッシュ:
9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM
- Disclosure:
- Disclosure:
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN0cmVldF9hZGRyZXNzIiwgIlN
jaHVsc3RyLiAxMiJd- Contents:
- 内容:
["2GLC42sKQveCfGfryNRN9w", "street_address", "Schulstr. 12"]
* Claim locality:
* クレーム locality:
- SHA-256 Hash:
- SHA-256 ハッシュ:
6vh9bq-zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0
- Disclosure:
- Disclosure:
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImxvY2FsaXR5IiwgIlNjaHVscGZ
vcnRhIl0- Contents:
- 内容:
["eluV5Og3gSNII8EYnsxA_A", "locality", "Schulpforta"]
* Claim region:
* クレーム region:
- SHA-256 Hash:
- SHA-256 ハッシュ:
KURDPh4ZC19-3tiz-Df39V8eidy1oV3a3H1Da2N0g88
- Disclosure:
- Disclosure:
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInJlZ2lvbiIsICJTYWNoc2VuLUF
uaGFsdCJd- Contents:
- 内容:
["6Ij7tM-a5iVPGboS5tmvVA", "region", "Sachsen-Anhalt"]
* Claim country:
* クレーム country:
- SHA-256 Hash:
- SHA-256 ハッシュ:
WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM
- Disclosure:
- Disclosure:
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImNvdW50cnkiLCAiREUiXQ
- Contents:
- 内容:
["eI8ZWm9QnKPpNPeNenHdhQ", "country", "DE"]
* Claim address:
* クレーム address:
- SHA-256 Hash:
- SHA-256 ハッシュ:
HvrKX6fPV0v9K_yCVFBiLFHsMaxcD_114Em6VT8x1lg
- Disclosure:
- Disclosure:
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImFkZHJlc3MiLCB7Il9zZCI6IFs
iNnZoOWJxLXpTNEdLTV83R3BnZ1ZiWXp6dTZvT0dYcm1OVkdQSFA3NVVkMCIsIC
I5Z2pWdVh0ZEZST0NnUnJ0TmNHVVhtRjY1cmRlemlfNkVyX2o3NmttWXlNIiwgI
ktVUkRQaDRaQzE5LTN0aXotRGYzOVY4ZWlkeTFvVjNhM0gxRGEyTjBnODgiLCAi
V045cjlkQ0JKOEhUQ3NTMmpLQVN4VGpFeVc1bTV4NjVfWl8ycm8yamZYTSJdfV0- Contents:
- 内容:
["Qg_O64zqAxe412a108iroA", "address", {"_sd": ["6vh9bq-
zS4GKM_7GpggVbYzzu6oOGXrmNVGPHP75Ud0",
"9gjVuXtdFROCgRrtNcGUXmF65rdezi_6Er_j76kmYyM", "KURDPh4ZC19-
3tiz-Df39V8eidy1oV3a3H1Da2N0g88",
"WN9r9dCBJ8HTCsS2jKASxTjEyW5m5x65_Z_2ro2jfXM"]}]7.Verification and Processing
7.検証と処理
7.1.Verification of the SD-JWT
7.1.SD-JWT の検証
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).
* すべての Disclosure が有効であり、それぞれ発行者署名付き JWT 内の対応するダイジェスト値 (ペイロード内に直接、または他の Disclosure の内容に再帰的に含まれるもの) に対応していること。
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 を検証しペイロードを取り出すために、次の確認を行わなければならない (MUST):
1. Separate the SD-JWT into the Issuer-signed JWT and the Disclosures (if any).
1. SD-JWT を発行者署名付き JWT と Disclosure (あれば) に分離する。
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 節を参照のこと。"none" アルゴリズムは受け入れてはならない (MUST NOT)。
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 内の Disclosure と埋め込まれたダイジェストを次のように処理する:
a. For each Disclosure provided:
a. 提供された各 Disclosure について:
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. その値を先に計算したダイジェストと比較し、一致する Disclosure を見つける。そのような Disclosure が見つからない場合、そのダイジェストは無視されなければならない (MUST)。
ii. If the digest was found in an object's _sd key:
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. 対応する Disclosure の内容が 3 要素 (ソルト、クレーム名、クレーム値) の JSON 配列でない場合、その SD-JWT は拒否されなければならない (MUST)。
2. If the claim name is _sd or ..., the SD-JWT MUST be rejected.
2. クレーム名が _sd または ... である場合、その SD-JWT は拒否されなければならない (MUST)。
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 鍵と同じ階層に、Disclosure のクレーム名とクレーム値を用いて新しいクレームを挿入する。
5. Recursively process the value using the steps described in (*) and (**).
5. (*) および (**) に記載のステップを用いて、その値を再帰的に処理する。
iii. If the digest was found in an array element:
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 要素 (ソルト、値) の JSON 配列でない場合、その SD-JWT は拒否されなければならない (MUST)。
2. Replace the array element with the value from the Disclosure.
2. その配列要素を Disclosure の値で置き換える。
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. 発行者署名付き JWT のペイロードから、すべての _sd 鍵とその内容を削除する。その結果プロパティを持たないオブジェクトになった場合、それは空のオブジェクト {} として表現されるべきである。
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 のペイロード内で (直接、または他の Disclosure を介して再帰的に) 同じダイジェスト値に複数回遭遇した場合、その 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 内で (直接、または他の Disclosure を介して再帰的に) ダイジェスト値により参照されていない Disclosure があった場合、その 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 は有効ではなく、処理は中断されなければならない (MUST)。そうでなければ、上記の処理および検証ステップの結果として得られる 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.7.2.Processing by the Holder
7.2.保持者による処理
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 を提供するのであって、SD-JWT+KB を提供するのではない。保持者が SD-JWT+KB を受け取った場合、それは拒否されなければならない (MUST)。
When receiving an SD-JWT, the Holder MUST do the following:
SD-JWT を受け取った際、保持者は次のことを行わなければならない (MUST):
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 節に記載の確認に加えて) 次の (または同等の) ステップを実行しなければならない (MUST):
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. 検証者に開示する Disclosure を決定し、必要であれば同意を得る (同意を得るかどうか、またどのように得るかは本書の範囲外であることに注意)。
2. Verify that each selected Disclosure satisfies one of the two following conditions:
2. 選択した各 Disclosure が次の 2 つの条件のいずれかを満たすことを検証する:
a. The hash of the Disclosure is contained in the Issuer-signed JWT claims.
a. その Disclosure のハッシュが発行者署名付き JWT のクレームに含まれている。
b. The hash of the Disclosure is contained in the claim value of another selected Disclosure.
b. その Disclosure のハッシュが、選択した別の Disclosure のクレーム値に含まれている。
3. Assemble the SD-JWT, including the Issuer-signed JWT and the selected Disclosures (see Section 4 for the format).
3. 発行者署名付き JWT と選択した Disclosure を含む SD-JWT を組み立てる (フォーマットは 4 節を参照)。
4. If Key Binding is not required:
4. Key Binding が要求されていない場合:
a. Send the SD-JWT to the Verifier.
a. SD-JWT を検証者に送る。
5. If Key Binding is required:
5. Key Binding が要求されている場合:
a. Create a Key Binding JWT tied to the SD-JWT.
a. SD-JWT に結び付けられた Key Binding JWT を作成する。
b. Assemble the SD-JWT+KB by concatenating the SD-JWT and the Key Binding JWT.
b. SD-JWT と Key Binding JWT を連結して SD-JWT+KB を組み立てる。
c. Send the SD-JWT+KB to the Verifier.
c. SD-JWT+KB を検証者に送る。
7.3.Verification by the Verifier
7.3.検証者による検証
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
* Key Binding が要求されている場合、保持者が SD-JWT+KB を提供していること、および
* the Key Binding JWT is signed by the Holder and valid.
* Key Binding JWT が保持者により署名されており、有効であること。
To this end, Verifiers MUST follow the following steps (or equivalent):
このため、検証者は次の (または同等の) ステップに従わなければならない (MUST):
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. 当該の利用ケースに対する検証者のポリシーに従って、Key Binding を確認すべきかどうかを決定する。この決定は、保持者が Key Binding 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. Key Binding が要求されており、保持者が (Key Binding のない) 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 と Key Binding 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. Key Binding が要求されている場合:
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 節を参照のこと。"none" アルゴリズムは受け入れてはならない (MUST NOT)。
c. Validate the signature over the Key Binding JWT per Section 5.2 of [RFC7515].
c. [RFC7515] の 5.2 節に従って、Key Binding JWT の署名を検証する。
d. Check that the typ of the Key Binding JWT is kb+jwt (see Section 4.3).
d. Key Binding JWT の typ が 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 クレームにより決まる Key Binding 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 クレームを検証することで、Key Binding JWT が現在のトランザクションに結び付けられており、この検証者のために作成されたものであること (リプレイ検出) を確認する。
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 と Disclosure に対するダイジェストを計算し、それが Key Binding JWT 内の sd_hash クレームの値と一致することを検証する。
h. Check that the Key Binding JWT is a valid JWT in all other respects, per [RFC7519] and [RFC8725].
h. Key Binding JWT が、[RFC7519] および [RFC8725] に従い、その他すべての点で有効な JWT であることを確認する。
If any step fails, the presentation is not valid and processing MUST be aborted.
いずれかのステップが失敗した場合、その提示は有効ではなく、処理は中断されなければならない (MUST)。
Otherwise, the Processed SD-JWT Payload can be passed to the application to be used for the intended purpose.
そうでなければ、処理済み SD-JWT ペイロードを、意図した目的で使用するためにアプリケーションへ渡すことができる。
8.JWS JSON Serialization
8.JWS JSON シリアライゼーション
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 の代替フォーマットを記述する。このフォーマットのサポートは任意である (OPTIONAL)。
8.1.New Unprotected Header Parameters
8.1.新しい非保護ヘッダーパラメータ
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:
General および Flattened のいずれの 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.
disclosures: 各要素が 4.2 節に記載の個々の Disclosure である、文字列の配列。
kb_jwt: Present only in an SD-JWT+KB, the Key Binding JWT as described in Section 4.3.
kb_jwt: SD-JWT+KB にのみ存在し、4.3 節に記載の Key Binding 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 が存在しなければならず (MUST)、sd_hash クレームのダイジェストは 4.3.1 節に記載のとおり SD-JWT に対して計算されなければならない (MUST)。これは、JWS JSON シリアライゼーションを用いる場合でも、ダイジェストを計算するために通常の SD-JWT コンパクトシリアライゼーションとしての表現を一時的に作成しなければならない (MUST) ことを意味する。詳細には、SD-JWT コンパクトシリアライゼーション部分は、JWS JSON シリアライズされた SD-JWT の保護ヘッダー、ペイロード、署名を . 文字を区切りとして連結し、非保護ヘッダーの disclosures メンバーにある Disclosure を用いることで構築される。
Unprotected headers other than disclosures are not covered by the digest, and therefore, as usual, are not protected against tampering.
disclosures 以外の非保護ヘッダーはダイジェストの対象ではなく、したがって通常どおり改ざんから保護されない。
8.2.Flattened JSON Serialization
8.2.Flattened JSON シリアライゼーション
In the case of Flattened JSON Serialization, there is only one unprotected header.
Flattened JSON シリアライゼーションの場合、非保護ヘッダーは 1 つだけである。
The following is a non-normative example of a JWS JSON serialized SD- JWT as issued using the Flattened JSON Serialization:
以下は、Flattened 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 つの Disclosure を持つ 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"
}8.3.General JSON Serialization
8.3.General JSON シリアライゼーション
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.
General JSON シリアライゼーションの場合、非保護ヘッダーは複数 (署名ごとに 1 つ) 存在する。disclosures と kb_jwt が存在する場合、それらは最初の非保護ヘッダーに含められなければならず (MUST)、後続のいずれの非保護ヘッダーにも存在してはならない (MUST NOT)。
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:
以下は、General JSON シリアライゼーションを用いた、Key Binding 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"
}
]
}8.4.Verification of the JWS JSON Serialized SD-JWT
8.4.JWS JSON シリアライズされた SD-JWT の検証
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 を構成要素に分割する必要はなく、Disclosure は非保護ヘッダーの disclosures メンバーで見つけることができる。
* 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 の Key Binding JWT 内の sd_hash のダイジェストを検証するために、検証者は 8.1 節に記載のとおりハッシュ対象の文字列を組み立てなければならない (MUST)。
9.Security Considerations
9.セキュリティに関する考慮事項
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 節に記載のとおり、Key Binding の適用により、SD-JWT クレデンシャルの提示者がそのクレデンシャルの保持者であることを保証できる。
9.1.Mandatory Signing of the Issuer-Signed JWT
9.1.発行者署名付き 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 は発行者により署名されなければならない (MUST)。この JWT が署名されていなければ、攻撃者はクレームを改変または追加できる (たとえば、被害者のアカウントを乗っ取るために "email" 属性を変更したり、偽の学歴を示す属性を追加したりできる)。
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.Algs] から適切な JWS アルゴリズムを選択することは、準備が整った時点でのポストクォンタムアルゴリズムを含め、アプリケーション固有の決定である。
9.2.Manipulation of Disclosures
9.2.Disclosure の改ざん
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.
保持者は、検証者に送る前にクレームの値を変更することで Disclosure を改ざんできる。検証者は、クレームの値が正しいこと、すなわち Disclosure のダイジェストが署名された SD-JWT 内に実際に存在することを確認するため、Disclosure を確認しなければならない (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.
(ハッシュを確認せずに) Disclosure からすべてのクレーム値を取り出して SD-JWT ペイロードに挿入する素朴な検証者は、この攻撃に対して脆弱である。しかし、構造化された SD-JWT では、Disclosure のダイジェストを比較しなければ、そのような実装はネストしたオブジェクト内でクレームを挿入すべき正しい位置を特定できない。したがって、素朴な実装は安全でないだけでなく、正しくもない。
The steps described in Section 7.3 ensure that the Verifier checks the Disclosures correctly.
7.3 節に記載のステップは、検証者が Disclosure を正しく確認することを保証する。
9.3.Entropy of the Salt
9.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.
平文のクレームを秘匿するセキュリティモデルは、ハッシュ関数への追加入力としてのソルトの高エントロピーな乱数データに依拠している。このランダム性により、同じ平文のクレーム値が同じダイジェスト値を生成しないことが保証される。また、あるクレームの取りうる値の空間を列挙してハッシュ関数に入力し、一致するダイジェスト値を探索することでダイジェストの原像を推測する (それによって平文のクレーム値を知る) ことを実行不可能にする。したがって、たとえ他のソルトが明らかになっていても、未公開のソルトを知ったり推測したりできないことが極めて重要である。そのため、各ソルトは、暗号学的にランダムで、十分に長く、推測が実行不可能となるのに十分高いエントロピーを持つように作成されなければならない (MUST)。新しいソルトは、クレームごとに他のソルトとは独立に選ばれなければならない (MUST)。乱数値の生成に関する考慮事項については「Randomness Requirements for Security」[RFC4086] を参照のこと。
The RECOMMENDED minimum length of the randomly generated portion of the salt is 128 bits.
ソルトのランダムに生成される部分の最小長として 128 ビットが推奨される (RECOMMENDED)。
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 という名前のクレームが複数現れるが、それぞれ異なるソルトを持っている。
9.4.Choice of a Hash Algorithm
9.4.ハッシュアルゴリズムの選択
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)。これは、ハッシュ関数が原像計算困難でなければならず (MUST)、また観測者が未開示の内容に関する部分的な情報を推測することも許すべきでないことを意味する。暗号学的コミットメントスキームの用語では、ハッシュ関数は計算量的に秘匿性 (computationally hiding) を持つ必要がある。
To ensure the integrity of selectively disclosable claims, the hash function MUST be second-preimage resistant. That is, for any combination of salt, claim name, and claim value, it is infeasible to find a different combination of salt, claim name, and claim value that results in the same digest.
選択的に開示可能なクレームの完全性を確保するため、ハッシュ関数は第二原像計算困難でなければならない (MUST)。すなわち、ソルト、クレーム名、クレーム値のいかなる組み合わせに対しても、同じダイジェストをもたらす別のソルト、クレーム名、クレーム値の組み合わせを見つけることが実行不可能である。
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 の想定される用途には必須ではないものの、衝突困難性がなければ、発行者が同じハッシュ値を持つ複数の Disclosure を見つけられる可能性がある。その場合、SD-JWT に対する署名は、発行者を JWT の内容にコミットさせるものとはならない。ダイジェストの生成に用いるハッシュ関数の衝突困難性は、署名スキームが用いるハッシュ関数の衝突困難性に見合うべきである (SHOULD)。たとえば、ES512 署名アルゴリズムを用いる場合、SHA-512 のように少なくとも 256 ビットの衝突困難性を持つ Disclosure ハッシュ関数が必要となる。
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 のような大幅に切り詰められたダイジェストがいくつか含まれており、それらはセキュリティ用途には不適である)。
9.5.Key Binding
9.5.Key Binding
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.
Key Binding は、SD-JWT クレデンシャルの提示者が実際にそのクレデンシャルの保持者であることを保証することを目的とする。Key Binding に対応した SD-JWT は、保持者が所持する秘密鍵に対応する公開鍵、または公開鍵への参照を含む。検証者は、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.
Key Binding がなければ、検証者はクレデンシャルが特定の発行者によって発行されたという証明しか得られず、クレデンシャル自体はそれにアクセスできる誰にでもリプレイされうる。これはたとえば、クレデンシャルが攻撃者に漏洩した後、攻撃者はバインディングを要求しないあらゆる検証者にそのクレデンシャルを提示できることを意味する。また、保持者がクレデンシャルを提示した先の悪意ある検証者は、別の検証者が 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.
検証者は、クレデンシャルを検証する前に、特定の利用ケースにおいて Key Binding が必要かどうかを決定しなければならない (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.
検証者が、攻撃者の影響を受けうるデータに基づいてセキュリティポリシーの決定を行わないことが重要である。このため、Key Binding が必要かどうかを決定する際に、検証者は保持者が 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.
さらに、検証者は、Key Binding 情報が自身の認識できないフォーマットで SD-JWT に付加されている可能性があり、その結果、その SD-JWT が Key Binding をサポートしているかどうかを判別できない場合があることを認識しておくべきである。
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.
検証者が特定の利用ケースにおいて Key Binding が必要であると判断し、保持者が素の SD-JWT、または無効な Key Binding JWT を伴う SD-JWT+KB のいずれかを提示した場合、検証者は 7.3 節に記載の検証ステップに従うことでその提示を拒否することになる。
9.6.Concealing Claim Names
9.6.クレーム名の秘匿
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 の構造を作成する際にこの制約を考慮に入れる必要がある。
9.7.Selectively Disclosable Validity Claims
9.7.選択的に開示可能な有効性クレーム
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)。以下は、セキュリティ上重要とみなされるべき (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)。
9.8.Distribution and Rotation of Issuer Signature Verification Key
9.8.発行者の署名検証鍵の配布とローテーション
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] を用いて事前に定義された場所に鍵を公開するなど、効率的かつ安全な鍵のローテーションと失効を可能にする方法で鍵を公開することが推奨される (RECOMMENDED)。検証者は、当該の鍵配布方式に対して合理的かつ適切な手段を用いて、署名検証に期限切れや失効済みの鍵を使用していないことを保証する必要がある。
9.9.Forwarding Credentials
9.9.クレデンシャルの転送
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 を含む) を所持するいかなる主体も、Key Binding を強制しない任意の第三者にそれを転送できる。その際、その主体は Disclosure を取り除くことで、受け手が元の 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.
シナリオによっては、この挙動は望ましいものでありうる。望ましくない場合には、発行者は Key Binding をサポートし、検証者はそれを強制する必要がある。
9.10.Integrity of SD-JWTs and SD-JWT+KBs
9.10.SD-JWT と SD-JWT+KB の完全性
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 は発行者の署名により完全性が保護され、Disclosure の値はそこに含まれるダイジェストにより完全性が保護される。しかし、Disclosure の特定の集合は完全性が保護されない。SD-JWT は Disclosure の追加や削除によって改変されても、なお有効でありうる。
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 では、選択された Disclosure の集合は完全性が保護される。Key Binding JWT の署名は、特定の発行者署名付き JWT と特定の Disclosure の集合を持つ特定の SD-JWT を対象とする。したがって、Key Binding JWT の署名は、Key Binding を証明することに加えて、保持者が開示した Disclosure の集合の真正性と完全性も保証する。SD-JWT+KB 内の Disclosure の集合は保持者が送ることを意図した集合であり、いかなる中間者も Disclosure のリストを追加、削除、改変していない。
9.11.Explicit Typing
9.11.明示的な型付け
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 節に記載) を防ぐ一つの仕組みとして、明示的な型付けの使用を記述している。SD-JWT もまたそのような混同攻撃を受ける可能性があるため、他の手法がない場合には、SD-JWT のアプリケーションプロファイルが、SD-JWT の発行時に typ ヘッダーパラメータを含めることで明示的な型を規定し、検証者がこの値を確認することが推奨される (RECOMMENDED)。
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.
SD-JWT に typ ヘッダーを用いた明示的な型付けを採用する場合、"application/example+sd-jwt" の形式のメディアタイプ名を用いることが推奨される (RECOMMENDED)。ここで "example" は、その特定の種類の SD-JWT の識別子に置き換える。[RFC7515] の 4.1.9 節における typ の定義は "application/" プレフィックスを省略することを推奨しているため、typ ヘッダーパラメータの値は "example+sd-jwt" となる。
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 クレームセットを区別するために利用できる。
9.12.Key Pair Generation and Lifecycle Management
9.12.鍵ペアの生成とライフサイクル管理
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 の不正な開示や偽造につながりうるため、適切な鍵管理が不可欠である。
10.Privacy Considerations
10.プライバシーに関する考慮事項
10.1.Unlinkability
10.1.非連結性
Unlinkability is a property whereby adversaries are prevented from correlating credential presentations of the same user beyond the user's consent. Without unlinkability, an adversary might be able to learn more about the user than the user intended to disclose, for example:
非連結性 (unlinkability) とは、同一ユーザーのクレデンシャル提示を、ユーザーの同意の範囲を超えて攻撃者が相関付けることを防ぐ性質である。非連結性がなければ、攻撃者はユーザーが開示するつもりだった以上のことをユーザーについて知り得る。例えば次のような場合である。
* 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.
いずれの場合も、非連結性は、開示されたクレームにユーザーを直接的または間接的に識別する情報が含まれていない場合に限られる。例えば、開示されたクレームに納税者番号が含まれていれば、発行者と検証者はユーザーの取引を容易に結び付けられる。しかし、ユーザーがある検証者には生年月日だけを、別の検証者には郵便番号だけを開示した場合、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).
検証者/検証者間の非連結性と提示の非連結性は、バッチ発行を用いることで達成できる。すなわち、単一のクレデンシャルではなく、同じクレームに基づくクレデンシャルのバッチを保持者に発行する。保持者はその後、検証者ごとに、あるいは検証者とのセッションごとにさえ、異なるクレデンシャルを使用できる。検証者がこれらの値を用いてクレデンシャルを結び付けられないようにするため、バッチ内の各クレデンシャルには新しい Key Binding 鍵とソルトを使用しなければならない (MUST)。同様に、iat、exp、nbf のような時刻情報を持つクレームは、適切と考えられる期間内でランダム化する (例えば、iat を過去 24 時間以内でランダム化し、それに応じて exp を計算する) か、丸める (例えば、その日の始まりに切り捨てる) かのいずれかを行わなければならない (MUST)。
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] を含む、すべてのソルト付きハッシュベースの方式に当てはまる。
10.2.Storage of User Data
10.2.ユーザーデータの保存
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 は、Key Binding が強制され、かつ攻撃者が保持者の暗号鍵にアクセスできない場合を除き、攻撃者が保持者になりすますことを可能にするかもしれない。
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 を実装するシステムは、保存されるデータ量を最小化するように設計されるべきである (SHOULD)。関係するすべての当事者は、ログファイルも含めて、厳密に必要な期間を超えて SD-JWT を保存すべきではない (SHOULD NOT)。
After Issuance, Issuers SHOULD NOT store the Issuer-signed JWT or the respective Disclosures.
発行の後、発行者は発行者署名付き JWT やそれに対応する Disclosure を保存すべきではない (SHOULD NOT)。
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)、可能な限り、特に Key Binding の秘密鍵についてはハードウェアに裏付けられた暗号化を使用すべきである。ユーザーのクレデンシャルについては、集中型の保存よりも、例えばユーザーのデバイス上などの分散型のデータ保存が優先されるべきである (SHOULD)。期限切れの SD-JWT はできるだけ早く削除されるべきである (SHOULD)。
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 やそれに対応する Disclosure を保存すべきではない (SHOULD NOT)。検証結果と、アプリケーションに必要なユーザーデータを保存すれば十分かもしれない。
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.
上記の規則の例外は、そうすべき強い要件 (例えば、機能要件や法的な監査要件) があり、安全な保存が確保でき、かつプライバシーへの影響が評価されている場合に設けることができる。
10.3.Confidentiality During Transport
10.3.転送中の機密性
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)。
10.4.Decoy Digests
10.4.デコイダイジェスト
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.
クレームの数 (または特定のクレームの存在) が、開示されていないクレームに関する情報を明らかにするサイドチャネルになり得る場合、デコイダイジェストの使用が推奨される (RECOMMENDED)。特に、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 のサイズとユーザーデータのプライバシーとのトレードオフである。
10.5.Issuer Identifier
10.5.発行者識別子
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.
この問題を緩和するために、発行者のグループが共通の発行者識別子を使用することを選んでもよい。個別の署名の代わりに、本仕様の範囲外であるグループ署名方式を使用することもできる。
11.IANA Considerations
11.IANA に関する考慮事項
11.1.JSON Web Token Claims Registration
11.1.JSON Web Token クレームの登録
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 Claim Description: Digests of Disclosures for object properties Change Controller: IETF Specification Document(s): Section 4.2.4.1 of RFC 9901
クレーム名: _sd クレームの説明: オブジェクトプロパティに対する Disclosure のダイジェスト 変更管理者: IETF 仕様文書: RFC 9901 の 4.2.4.1 節
Claim Name: ... Claim Description: Digest of the Disclosure for an array element Change Controller: IETF Specification Document(s): Section 4.2.4.2 of RFC 9901
クレーム名: ... クレームの説明: 配列要素に対する Disclosure のダイジェスト 変更管理者: IETF 仕様文書: RFC 9901 の 4.2.4.2 節
Claim Name: _sd_alg Claim Description: Hash algorithm used to generate Disclosure digests and digest over presentation Change Controller: IETF Specification Document(s): Section 4.1.1 of RFC 9901
クレーム名: _sd_alg クレームの説明: Disclosure のダイジェストおよび提示に対するダイジェストの生成に用いるハッシュアルゴリズム 変更管理者: IETF 仕様文書: RFC 9901 の 4.1.1 節
Claim Name: sd_hash Claim Description: Digest of the SD-JWT to which the KB-JWT is tied Change Controller: IETF Specification Document(s): Section 4.3 of RFC 9901
クレーム名: sd_hash クレームの説明: KB-JWT が紐付けられる SD-JWT のダイジェスト 変更管理者: IETF 仕様文書: RFC 9901 の 4.3 節
11.2.Media Type Registrations
11.2.メディアタイプの登録
IANA has registered the following media types [RFC2046] in the "Media Types" registry [MediaTypes] in the manner described in [RFC6838].
IANA は、[RFC6838] に記述された方法で、"Media Types" レジストリ [MediaTypes] に以下のメディアタイプ [RFC2046] を登録した。
| Note: For the media type value used in the typ header in the
| Issuer-signed JWT itself, see Section 9.11.11.2.1.SD-JWT Content
11.2.1.SD-JWT コンテンツ
To indicate that the content is an SD-JWT:
コンテンツが SD-JWT であることを示すには:
Type name: application
タイプ名: application
Subtype name: sd-jwt
サブタイプ名: sd-jwt
Required parameters: n/a
必須パラメータ: n/a
Optional parameters: n/a
任意パラメータ: 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.
エンコーディングに関する考慮事項: binary。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
相互運用性に関する考慮事項: 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
フラグメント識別子に関する考慮事項: n/a
Additional information:
追加情報:
Magic number(s): n/a
File extension(s): n/a
Macintosh file type code(s): n/aPerson & email address to contact for further information: Daniel Fett, mail@danielfett.de
詳細情報の連絡先となる人物とメールアドレス: Daniel Fett, mail@danielfett.de
Intended usage: COMMON
想定される用途: COMMON
Restrictions on usage: none
使用上の制限: なし
Author: Daniel Fett, mail@danielfett.de
著者: Daniel Fett, mail@danielfett.de
Change Controller: IETF
変更管理者: IETF
11.2.2.JWS JSON Serialized SD-JWT Content
11.2.2.JWS JSON シリアライズされた SD-JWT コンテンツ
To indicate that the content is a JWS JSON serialized SD-JWT:
コンテンツが JWS JSON シリアライズされた SD-JWT であることを示すには:
Type name: application
タイプ名: application
Subtype name: sd-jwt+json
サブタイプ名: sd-jwt+json
Required parameters: n/a
必須パラメータ: n/a
Optional parameters: n/a
任意パラメータ: n/a
Encoding considerations: binary; application/sd-jwt+json values are represented as a JSON Object.
エンコーディングに関する考慮事項: binary。application/sd-jwt+json の値は JSON オブジェクトとして表現される。
Security considerations: See the Security Considerations sections of RFC 9901 and [RFC7515].
セキュリティに関する考慮事項: RFC 9901 および [RFC7515] のセキュリティに関する考慮事項の節を参照。
Interoperability considerations: n/a
相互運用性に関する考慮事項: 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
フラグメント識別子に関する考慮事項: n/a
Additional information:
追加情報:
Magic number(s): n/a
File extension(s): n/a
Macintosh file type code(s): n/aPerson & email address to contact for further information: Daniel Fett, mail@danielfett.de
詳細情報の連絡先となる人物とメールアドレス: Daniel Fett, mail@danielfett.de
Intended usage: COMMON
想定される用途: COMMON
Restrictions on usage: none
使用上の制限: なし
Author: Daniel Fett, mail@danielfett.de
著者: Daniel Fett, mail@danielfett.de
Change Controller: IETF
変更管理者: IETF
11.2.3.Key Binding JWT Content
11.2.3.Key Binding JWT コンテンツ
To indicate that the content is a Key Binding JWT:
コンテンツが Key Binding JWT であることを示すには:
Type name: application
タイプ名: application
Subtype name: kb+jwt
サブタイプ名: kb+jwt
Required parameters: n/a
必須パラメータ: n/a
Optional parameters: n/a
任意パラメータ: 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.
エンコーディングに関する考慮事項: binary。Key Binding 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
相互運用性に関する考慮事項: 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
フラグメント識別子に関する考慮事項: n/a
Additional information:
追加情報:
Magic number(s): n/a
File extension(s): n/a
Macintosh file type code(s): n/aPerson & email address to contact for further information: Daniel Fett, mail@danielfett.de
詳細情報の連絡先となる人物とメールアドレス: Daniel Fett, mail@danielfett.de
Intended usage: COMMON
想定される用途: COMMON
Restrictions on usage: none
使用上の制限: なし
Author: Daniel Fett, mail@danielfett.de
著者: Daniel Fett, mail@danielfett.de
Change Controller: IETF
変更管理者: IETF
11.3.Structured Syntax Suffixes Registration
11.3.構造化構文サフィックスの登録
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] に記述された方法で、"Structured Syntax Suffixes" レジストリ [StructuredSuffix] に "+sd-jwt" を登録した。これは、メディアタイプが SD-JWT としてエンコードされていることを示すために使用できる。
Name: SD-JWT
名前: SD-JWT
+suffix: +sd-jwt
+suffix: +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.
エンコーディングに関する考慮事項: binary。SD-JWT の値は、ピリオド ('.') またはチルダ ('~') 文字で区切られた一連の base64url エンコード値 (その一部は空文字列であってもよい) である。
Interoperability considerations: n/a
相互運用性に関する考慮事項: n/a
Fragment identifier considerations: n/a
フラグメント識別子に関する考慮事項: 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
連絡先: Daniel Fett, mail@danielfett.de
Author/Change controller: IETF
著者/変更管理者: IETF
12.References
12.参考資料
12.1.Normative References
12.1.引用規格
[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>.12.2.Informative References
12.2.参考文献
[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/>.A.Additional Examples
A.追加の例
The following examples are not normative and are provided for illustrative purposes only. In particular, neither the structure of the claims nor the selection of selectively disclosable claims is normative.
以下の例は規範的なものではなく、説明のためだけに提供されている。特に、クレームの構造も、選択的に開示可能なクレームの選び方も規範的ではない。
Line breaks have been added for readability.
読みやすさのために改行を追加している。
A.1.Simple Structured SD-JWT
A.1.単純な構造化 SD-JWT
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 節とは対照的に、発行者は address クレームに対して構造化されたオブジェクトを作成することにし、そのクレームの個々のメンバーを別々に開示できるようにしている。
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 ペイロード内のダイジェストは、次の Disclosure を参照している。
* Claim sub:
* クレーム sub:
- SHA-256 Hash:
- SHA-256 Hash:
X6ZAYOII2vPN40V7xExZwVwz7yRmLNcVwt5DL8RLv4g
- Disclosure:
- Disclosure:
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInN1YiIsICI2YzVjMGE0OS1iNTg
5LTQzMWQtYmFlNy0yMTkxMjJhOWVjMmMiXQ- Contents:
- Contents:
["2GLC42sKQveCfGfryNRN9w", "sub", "6c5c0a49-b589-431d- bae7-219122a9ec2c"]
["2GLC42sKQveCfGfryNRN9w", "sub", "6c5c0a49-b589-431d- bae7-219122a9ec2c"]
* Claim given_name:
* クレーム given_name:
- SHA-256 Hash:
- SHA-256 Hash:
ommFAicVT8LGHCB0uywx7fYuo3MHYKO15cz-RZEYM5Q
- Disclosure:
- Disclosure:
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiXHU1OTJ
hXHU5MGNlIl0- Contents:
- Contents:
["eluV5Og3gSNII8EYnsxA_A", "given_name", "\u592a\u90ce"]
* Claim family_name:
* クレーム family_name:
- SHA-256 Hash:
- SHA-256 Hash:
C9inp6YoRaEXR427zYJP7Qrk1WH_8bdwOA_YUrUnGQU
- Disclosure:
- Disclosure:
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIlx1NWM
3MVx1NzUzMCJd- Contents:
- Contents:
["6Ij7tM-a5iVPGboS5tmvVA", "family_name", "\u5c71\u7530"]
* Claim email:
* クレーム email:
- SHA-256 Hash:
- SHA-256 Hash:
Kuet1yAa0HIQvYnOVd59hcViO9Ug6J2kSfqYRBeowvE
- Disclosure:
- Disclosure:
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImVtYWlsIiwgIlwidW51c3VhbCB
lbWFpbCBhZGRyZXNzXCJAZXhhbXBsZS5qcCJd- Contents:
- Contents:
["eI8ZWm9QnKPpNPeNenHdhQ", "email", "\"unusual email address\"@example.jp"]
["eI8ZWm9QnKPpNPeNenHdhQ", "email", "\"unusual email address\"@example.jp"]
* Claim phone_number:
* クレーム phone_number:
- SHA-256 Hash:
- SHA-256 Hash:
s0BKYsLWxQQeU8tVlltM7MKsIRTrEIa1PkJmqxBBf5U
- Disclosure:
- Disclosure:
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBob25lX251bWJlciIsICIrODE
tODAtMTIzNC01Njc4Il0- Contents:
- Contents:
["Qg_O64zqAxe412a108iroA", "phone_number", "+81-80-1234-5678"]
* Claim street_address:
* クレーム street_address:
- SHA-256 Hash:
- SHA-256 Hash:
6aUhzYhZ7SJ1kVmagQAO3u2ETN2CC1aHheZpKnaF0_E
- Disclosure:
- Disclosure:
WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInN0cmVldF9hZGRyZXNzIiwgIlx
1Njc3MVx1NGVhY1x1OTBmZFx1NmUyZlx1NTMzYVx1ODI5ZFx1NTE2Y1x1NTcxMl
x1ZmYxNFx1NGUwMVx1NzZlZVx1ZmYxMlx1MjIxMlx1ZmYxOCJd- Contents:
- Contents:
["AJx-095VPrpTtN4QMOqROA", "street_address", "\u6771\u4eac\u90f d\u6e2f\u533a\u829d\u516c\u5712\uff14\u4e01\u76ee\uff12\u2212\u ff18"]
["AJx-095VPrpTtN4QMOqROA", "street_address", "\u6771\u4eac\u90f d\u6e2f\u533a\u829d\u516c\u5712\uff14\u4e01\u76ee\uff12\u2212\u ff18"]
* Claim locality:
* クレーム locality:
- SHA-256 Hash:
- SHA-256 Hash:
rvJd6iq6T5ejmsBMoGwuNXh9qAAFATAci40oidEeVsA
- Disclosure:
- Disclosure:
WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImxvY2FsaXR5IiwgIlx1Njc3MVx
1NGVhY1x1OTBmZCJd- Contents:
- Contents:
["Pc33JM2LchcU_lHggv_ufQ", "locality", "\u6771\u4eac\u90fd"]
* Claim region:
* クレーム region:
- SHA-256 Hash:
- SHA-256 Hash:
PzzcVu0qbMuBGSjulfewzkesD9zutOExn5EWNwkrQ-k
- Disclosure:
- Disclosure:
WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInJlZ2lvbiIsICJcdTZlMmZcdTU
zM2EiXQ- Contents:
- Contents:
["G02NSrQfjFXQ7Io09syajA", "region", "\u6e2f\u533a"]
* Claim country:
* クレーム country:
- SHA-256 Hash:
- SHA-256 Hash:
uNHoWYhXsZhVJCNE2Dqy-zqt7t69gJKy5QaFv7GrMX4
- Disclosure:
- Disclosure:
WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImNvdW50cnkiLCAiSlAiXQ
- Contents:
- Contents:
["lklxF5jMYlGTPUovMNIvCA", "country", "JP"]
* Claim birthdate:
* クレーム birthdate:
- SHA-256 Hash:
- SHA-256 ハッシュ:
MMldOFFzB2d0umlmpTIaGerhWdU_PpYfLvKhh_f_9aY
- Disclosure:
- Disclosure:
WyJ5eXRWYmRBUEdjZ2wyckk0QzlHU29nIiwgImJpcnRoZGF0ZSIsICIxOTQwLTA
xLTAxIl0- Contents:
- 内容:
["yytVbdAPGcgl2rI4C9GSog", "birthdate", "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:
以下は、address プロパティのうち region と country のみを開示する SD-JWT の提示である。
eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.eyJfc2QiOiBb IkM5aW5wNllvUmFFWFI0Mjd6WUpQN1FyazFXSF84YmR3T0FfWVVyVW5HUVUiLCAiS3Vl dDF5QWEwSElRdlluT1ZkNTloY1ZpTzlVZzZKMmtTZnFZUkJlb3d2RSIsICJNTWxkT0ZG ekIyZDB1bWxtcFRJYUdlcmhXZFVfUHBZZkx2S2hoX2ZfOWFZIiwgIlg2WkFZT0lJMnZQ TjQwVjd4RXhad1Z3ejd5Um1MTmNWd3Q1REw4Ukx2NGciLCAiWTM0em1JbzBRTExPdGRN cFhHd2pCZ0x2cjE3eUVoaFlUMEZHb2ZSLWFJRSIsICJmeUdwMFdUd3dQdjJKRFFsbjFs U2lhZW9iWnNNV0ExMGJRNTk4OS05RFRzIiwgIm9tbUZBaWNWVDhMR0hDQjB1eXd4N2ZZ dW8zTUhZS08xNWN6LVJaRVlNNVEiLCAiczBCS1lzTFd4UVFlVTh0VmxsdE03TUtzSVJU ckVJYTFQa0ptcXhCQmY1VSJdLCAiaXNzIjogImh0dHBzOi8vaXNzdWVyLmV4YW1wbGUu Y29tIiwgImlhdCI6IDE2ODMwMDAwMDAsICJleHAiOiAxODgzMDAwMDAwLCAiYWRkcmVz cyI6IHsiX3NkIjogWyI2YVVoelloWjdTSjFrVm1hZ1FBTzN1MkVUTjJDQzFhSGhlWnBL bmFGMF9FIiwgIkF6TGxGb2JrSjJ4aWF1cFJFUHlvSnotOS1OU2xkQjZDZ2pyN2ZVeW9I emciLCAiUHp6Y1Z1MHFiTXVCR1NqdWxmZXd6a2VzRDl6dXRPRXhuNUVXTndrclEtayIs ICJiMkRrdzBqY0lGOXJHZzhfUEY4WmN2bmNXN3p3Wmo1cnlCV3ZYZnJwemVrIiwgImNQ WUpISVo4VnUtZjlDQ3lWdWIyVWZnRWs4anZ2WGV6d0sxcF9KbmVlWFEiLCAiZ2xUM2hy U1U3ZlNXZ3dGNVVEWm1Xd0JUdzMyZ25VbGRJaGk4aEdWQ2FWNCIsICJydkpkNmlxNlQ1 ZWptc0JNb0d3dU5YaDlxQUFGQVRBY2k0MG9pZEVlVnNBIiwgInVOSG9XWWhYc1poVkpD TkUyRHF5LXpxdDd0NjlnSkt5NVFhRnY3R3JNWDQiXX0sICJfc2RfYWxnIjogInNoYS0y NTYifQ.EOZa2YqK8j4i7cqBDkfPcTMaFsgPwcx3aYJkFoMfvV46LxL-PPqrWsIyNukB4 x8Y2LT31eIHDc4Wg4XNzaqu4w~WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgInJlZ2 lvbiIsICJcdTZlMmZcdTUzM2EiXQ~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImN vdW50cnkiLCAiSlAiXQ~
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"
}
}A.2.Complex Structured SD-JWT
A.2.複雑な構造化 SD-JWT
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 ペイロード内のダイジェストは、次の Disclosure を参照している。
* Claim time:
* Claim time:
- SHA-256 Hash:
- SHA-256 Hash:
vTwe3raHIFYgFA3xaUD2aMxFz5oDo8iBu05qKlOg9Lw
- Disclosure:
- Disclosure:
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgInRpbWUiLCAiMjAxMi0wNC0yM1Q
xODoyNVoiXQ- Contents:
- Contents:
["2GLC42sKQveCfGfryNRN9w", "time", "2012-04-23T18:25Z"]
* Claim verification_process:
* クレーム verification_process:
- SHA-256 Hash:
- SHA-256 Hash:
7h4UE9qScvDKodXVCuoKfKBJpVBfXMF_TmAGVaZe3Sc
- Disclosure:
- Disclosure:
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgInZlcmlmaWNhdGlvbl9wcm9jZXN
zIiwgImYyNGM2Zi02ZDNmLTRlYzUtOTczZS1iMGQ4NTA2ZjNiYzciXQ- Contents:
- Contents:
["eluV5Og3gSNII8EYnsxA_A", "verification_process", "f24c6f- 6d3f-4ec5-973e-b0d8506f3bc7"]
["eluV5Og3gSNII8EYnsxA_A", "verification_process", "f24c6f- 6d3f-4ec5-973e-b0d8506f3bc7"]
* Claim type:
* クレーム type:
- SHA-256 Hash:
- SHA-256 Hash:
G5EnhOAOoU9X_6QMNvzFXjpEA_Rc-AEtm1bG_wcaKIk
- Disclosure:
- Disclosure:
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgInR5cGUiLCAiZG9jdW1lbnQiXQ
- Contents:
- Contents:
["6Ij7tM-a5iVPGboS5tmvVA", "type", "document"]
* Claim method:
* クレーム method:
- SHA-256 Hash:
- SHA-256 Hash:
WpxQ4HSoEtcTmCCKOeDslB_emucYLz2oO8oHNr1bEVQ
- Disclosure:
- Disclosure:
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm1ldGhvZCIsICJwaXBwIl0
- Contents:
- Contents:
["eI8ZWm9QnKPpNPeNenHdhQ", "method", "pipp"]
* Claim time:
* クレーム time:
- SHA-256 Hash:
- SHA-256 Hash:
9wpjVPWuD7PK0nsQDL8B06lmdgV3LVybhHydQpTNyLI
- Disclosure:
- Disclosure:
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInRpbWUiLCAiMjAxMi0wNC0yMlQ
xMTozMFoiXQ- Contents:
- Contents:
["Qg_O64zqAxe412a108iroA", "time", "2012-04-22T11:30Z"]
* Claim document:
* クレーム document:
- SHA-256 Hash:
- SHA-256 Hash:
IhwFrWUB63RcZq9yvgZ0XPc7Gowh3O2kqXeBIswg1B4
- Disclosure:
- Disclosure:
WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRvY3VtZW50IiwgeyJ0eXBlIjo
gImlkY2FyZCIsICJpc3N1ZXIiOiB7Im5hbWUiOiAiU3RhZHQgQXVnc2J1cmciLC
AiY291bnRyeSI6ICJERSJ9LCAibnVtYmVyIjogIjUzNTU0NTU0IiwgImRhdGVfb
2ZfaXNzdWFuY2UiOiAiMjAxMC0wMy0yMyIsICJkYXRlX29mX2V4cGlyeSI6ICIy
MDIwLTAzLTIyIn1d- Contents:
- Contents:
["AJx-095VPrpTtN4QMOqROA", "document", {"type": "idcard",
"issuer": {"name": "Stadt Augsburg", "country": "DE"},
"number": "53554554", "date_of_issuance": "2010-03-23",
"date_of_expiry": "2020-03-22"}]* Array Entry:
* 配列要素:
- SHA-256 Hash:
- SHA-256 Hash:
tYJ0TDucyZZCRMbROG4qRO5vkPSFRxFhUELc18CSl3k
- Disclosure:
- Disclosure:
WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgeyJfc2QiOiBbIjl3cGpWUFd1RDd
QSzBuc1FETDhCMDZsbWRnVjNMVnliaEh5ZFFwVE55TEkiLCAiRzVFbmhPQU9vVT
lYXzZRTU52ekZYanBFQV9SYy1BRXRtMWJHX3djYUtJayIsICJJaHdGcldVQjYzU
mNacTl5dmdaMFhQYzdHb3doM08ya3FYZUJJc3dnMUI0IiwgIldweFE0SFNvRXRj
VG1DQ0tPZURzbEJfZW11Y1lMejJvTzhvSE5yMWJFVlEiXX1d- Contents:
- 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:
* クレーム given_name:
- SHA-256 Hash:
- SHA-256 Hash:
S_498bbpKzB6Eanftss0xc7cOaoneRr3pKr7NdRmsMo
- Disclosure:
- Disclosure:
WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdpdmVuX25hbWUiLCAiTWF4Il0
- Contents:
- Contents:
["G02NSrQfjFXQ7Io09syajA", "given_name", "Max"]
* Claim family_name:
* クレーム family_name:
- SHA-256 Hash:
- SHA-256 Hash:
Wxh_sV3iRH9bgrTBJi-aYHNCLt-vjhX1sd-igOf_9lk
- Disclosure:
- Disclosure:
WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImZhbWlseV9uYW1lIiwgIk1cdTA
wZmNsbGVyIl0- Contents:
- Contents:
["lklxF5jMYlGTPUovMNIvCA", "family_name", "M\u00fcller"]
* Claim nationalities:
* クレーム nationalities:
- SHA-256 Hash:
- SHA-256 Hash:
hvDXhwmGcJQsBCA2OtjuLAcwAMpDsaU0nkovcKOqWNE
- Disclosure:
- Disclosure:
WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgIm5hdGlvbmFsaXRpZXMiLCBbIkR
FIl1d- Contents:
- Contents:
["nPuoQnkRFq3BIeAm7AnXFA", "nationalities", ["DE"]]
* Claim birthdate:
* クレーム birthdate:
- SHA-256 Hash:
- SHA-256 Hash:
WNA-UNK7F_zhsAb9syWO6IIQ1uHlTmOU8r8CvJ0cIMk
- Disclosure:
- Disclosure:
WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImJpcnRoZGF0ZSIsICIxOTU2LTA
xLTI4Il0- Contents:
- Contents:
["5bPs1IquZNa0hkaFzzzZNw", "birthdate", "1956-01-28"]
* Claim place_of_birth:
* クレーム place_of_birth:
- SHA-256 Hash:
- SHA-256 Hash:
RiOiCn6_w5ZHaadkQMrcQJf0Jte5RwurRs54231DTlo
- Disclosure:
- Disclosure:
WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgInBsYWNlX29mX2JpcnRoIiwgeyJ
jb3VudHJ5IjogIklTIiwgImxvY2FsaXR5IjogIlx1MDBkZXlra3ZhYlx1MDBlNm
phcmtsYXVzdHVyIn1d- Contents:
- Contents:
["5a2W0_NrlEZzfqmk_7Pq-w", "place_of_birth", {"country": "IS",
"locality": "\u00deykkvab\u00e6jarklaustur"}]* Claim address:
* クレーム address:
- SHA-256 Hash:
- SHA-256 Hash:
_O-wJiH3enSB4ROHntToQT8JmLtz-mhO2f1c89XoerQ
- Disclosure:
- Disclosure:
WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImFkZHJlc3MiLCB7ImxvY2FsaXR
5IjogIk1heHN0YWR0IiwgInBvc3RhbF9jb2RlIjogIjEyMzQ0IiwgImNvdW50cn
kiOiAiREUiLCAic3RyZWV0X2FkZHJlc3MiOiAiV2VpZGVuc3RyYVx1MDBkZmUgM
jIifV0- Contents:
- Contents:
["y1sVU5wdfJahVdgwPgS7RQ", "address", {"locality": "Maxstadt",
"postal_code": "12344", "country": "DE", "street_address":
"Weidenstra\u00dfe 22"}]* Claim birth_middle_name:
* クレーム birth_middle_name:
- SHA-256 Hash:
- SHA-256 Hash:
otkxuT14nBiwzNJ3MPaOitOl9pVnXOaEHal_xkyNfKI
- Disclosure:
- Disclosure:
WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImJpcnRoX21pZGRsZV9uYW1lIiw
gIlRpbW90aGV1cyJd- Contents:
- Contents:
["HbQ4X8srVW3QDxnIJdqyOA", "birth_middle_name", "Timotheus"]
* Claim salutation:
* クレーム salutation:
- SHA-256 Hash:
- SHA-256 Hash:
-aSznId9mWM8ocuQolCllsxVggq1-vHW4OtnhUtVmWw
- Disclosure:
- Disclosure:
WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgInNhbHV0YXRpb24iLCAiRHIuIl0
- Contents:
- Contents:
["C9GSoujviJquEgYfojCb1A", "salutation", "Dr."]
* Claim msisdn:
* クレーム msisdn:
- SHA-256 Hash:
- SHA-256 ハッシュ:
IKbrYNn3vA7WEFrysvbdBJjDDU_EvQIr0W18vTRpUSg
- Disclosure:
- Disclosure:
WyJreDVrRjE3Vi14MEptd1V4OXZndnR3IiwgIm1zaXNkbiIsICI0OTEyMzQ1Njc
4OSJd- Contents:
- 内容:
["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"
}
}
}
}A.3.SD-JWT-Based Verifiable Credentials (SD-JWT VC)
A.3.SD-JWT ベースの Verifiable Credentials (SD-JWT VC)
This example shows how the artifacts defined in this specification could be used in the context of SD-JWT-based Verifiable Credentials (SD-JWT VC) [SD-JWT-VC] to represent a hypothetical identity credential with the data of a fictional German citizen.
この例は、本仕様で定義された成果物を、SD-JWT ベースの Verifiable Credentials (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.
Key Binding は、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 ペイロード内のダイジェストは、次の Disclosure を参照している。
* Claim given_name:
* クレーム given_name:
- SHA-256 Hash:
- SHA-256 Hash:
0HZmnSIPz337kSWe7C34l--88gzJi-eBJ2Vz_HJwATg
- Disclosure:
- Disclosure:
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiRXJpa2E
iXQ- Contents:
- Contents:
["2GLC42sKQveCfGfryNRN9w", "given_name", "Erika"]
* Claim family_name:
* クレーム family_name:
- SHA-256 Hash:
- SHA-256 Hash:
I00fcFUoDXCucp5yy2ujqPssDVGaWNiUliNz_awD0gc
- Disclosure:
- Disclosure:
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIk11c3R
lcm1hbm4iXQ- Contents:
- Contents:
["eluV5Og3gSNII8EYnsxA_A", "family_name", "Mustermann"]
* Claim birthdate:
* クレーム birthdate:
- SHA-256 Hash:
- SHA-256 Hash:
Lai6IU6d7GQagXR7AvGTrnXgSld3z8EIg_fv3fOZ1Wg
- Disclosure:
- Disclosure:
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImJpcnRoZGF0ZSIsICIxOTYzLTA
4LTEyIl0- Contents:
- Contents:
["6Ij7tM-a5iVPGboS5tmvVA", "birthdate", "1963-08-12"]
* Claim street_address:
* クレーム street_address:
- SHA-256 Hash:
- SHA-256 Hash:
ALZERsSn5WNiEXdCksW8I5qQw3_NpAnRqpSAZDudgw8
- Disclosure:
- Disclosure:
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgInN0cmVldF9hZGRyZXNzIiwgIkh
laWRlc3RyYVx1MDBkZmUgMTciXQ- Contents:
- Contents:
["eI8ZWm9QnKPpNPeNenHdhQ", "street_address", "Heidestra\u00dfe 17"]
["eI8ZWm9QnKPpNPeNenHdhQ", "street_address", "Heidestra\u00dfe 17"]
* Claim locality:
* Claim locality:
- SHA-256 Hash:
- SHA-256 Hash:
D__W_uYcvRz3tvUnIJvBDHiTc7C__qHd0xNKwIs_w9k
- Disclosure:
- Disclosure:
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImxvY2FsaXR5IiwgIktcdTAwZjZ
sbiJd- Contents:
- Contents:
["Qg_O64zqAxe412a108iroA", "locality", "K\u00f6ln"]
* Claim postal_code:
* クレーム postal_code:
- SHA-256 Hash:
- SHA-256 Hash:
xOPy9-gJALK6UbWKFLR85cOByUD3AbNwFg3I3YfQE_I
- Disclosure:
- Disclosure:
WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInBvc3RhbF9jb2RlIiwgIjUxMTQ
3Il0- Contents:
- Contents:
["AJx-095VPrpTtN4QMOqROA", "postal_code", "51147"]
* Claim country:
* Claim country:
- SHA-256 Hash:
- SHA-256 Hash:
eBpCXU1J5dhH2g4t8QYNW5ExS9AxUVblUodoLYoPho0
- Disclosure:
- Disclosure:
WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgImNvdW50cnkiLCAiREUiXQ
- Contents:
- Contents:
["Pc33JM2LchcU_lHggv_ufQ", "country", "DE"]
* Claim address:
* クレーム address:
- SHA-256 Hash:
- SHA-256 Hash:
RTz3qTmFNHbpWrrOMZS41F474kFqRv3vIPqth6PUhlM
- Disclosure:
- Disclosure:
WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImFkZHJlc3MiLCB7Il9zZCI6IFs
iQUxaRVJzU241V05pRVhkQ2tzVzhJNXFRdzNfTnBBblJxcFNBWkR1ZGd3OCIsIC
JEX19XX3VZY3ZSejN0dlVuSUp2QkRIaVRjN0NfX3FIZDB4Tkt3SXNfdzlrIiwgI
mVCcENYVTFKNWRoSDJnNHQ4UVlOVzVFeFM5QXhVVmJsVW9kb0xZb1BobzAiLCAi
eE9QeTktZ0pBTEs2VWJXS0ZMUjg1Y09CeVVEM0FiTndGZzNJM1lmUUVfSSJdfV0- Contents:
- Contents:
["G02NSrQfjFXQ7Io09syajA", "address", {"_sd": ["ALZERsSn5WNiEXdCksW8I5qQw3_NpAnRqpSAZDudgw8", "D__W_uYcvRz3tvUnIJvBDHiTc7C__qHd0xNKwIs_w9k", "eBpCXU1J5dhH2g4t8QYNW5ExS9AxUVblUodoLYoPho0", "xOPy9-gJALK6UbWKFLR85cOByUD3AbNwFg3I3YfQE_I"]}]
["G02NSrQfjFXQ7Io09syajA", "address", {"_sd": ["ALZERsSn5WNiEXdCksW8I5qQw3_NpAnRqpSAZDudgw8", "D__W_uYcvRz3tvUnIJvBDHiTc7C__qHd0xNKwIs_w9k", "eBpCXU1J5dhH2g4t8QYNW5ExS9AxUVblUodoLYoPho0", "xOPy9-gJALK6UbWKFLR85cOByUD3AbNwFg3I3YfQE_I"]}]
* Claim nationalities:
* クレーム nationalities:
- SHA-256 Hash:
- SHA-256 Hash:
y50czc0ISChy_bsba1dMoUuAOQ5AMmOSfGoEe81v1FU
- Disclosure:
- Disclosure:
WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgIm5hdGlvbmFsaXRpZXMiLCBbIkR
FIl1d- Contents:
- Contents:
["lklxF5jMYlGTPUovMNIvCA", "nationalities", ["DE"]]
* Claim sex:
* クレーム sex:
- SHA-256 Hash:
- SHA-256 Hash:
90CT8AaBPbn5X8nRXkesju1i0BqhWqZ3wqD4jF-qDGk
- Disclosure:
- Disclosure:
WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgInNleCIsIDJd
- Contents:
- Contents:
["nPuoQnkRFq3BIeAm7AnXFA", "sex", 2]
* Claim birth_family_name:
* クレーム birth_family_name:
- SHA-256 Hash:
- SHA-256 Hash:
KjAXgAA9N5WHEDtRIh4u5Mn1ZsWixhhWAiX-A4QiwgA
- Disclosure:
- Disclosure:
WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImJpcnRoX2ZhbWlseV9uYW1lIiw
gIkdhYmxlciJd- Contents:
- Contents:
["5bPs1IquZNa0hkaFzzzZNw", "birth_family_name", "Gabler"]
* Claim locality:
* クレーム locality:
- SHA-256 Hash:
- SHA-256 Hash:
KUViaaLnY5jSML90G29OOLENPbbXfhSjSPMjZaGkxAE
- Disclosure:
- Disclosure:
WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgImxvY2FsaXR5IiwgIkJlcmxpbiJ
d- Contents:
- Contents:
["5a2W0_NrlEZzfqmk_7Pq-w", "locality", "Berlin"]
* Claim country:
* クレーム country:
- SHA-256 Hash:
- SHA-256 Hash:
YbsT0S76VqXCVsd1jUSlwKPDgmALeB1uZclFHXf-USQ
- Disclosure:
- Disclosure:
WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImNvdW50cnkiLCAiREUiXQ
- Contents:
- Contents:
["y1sVU5wdfJahVdgwPgS7RQ", "country", "DE"]
* Claim place_of_birth:
* クレーム place_of_birth:
- SHA-256 Hash:
- SHA-256 Hash:
1Crn03WmUeRWp4zwPvvCKXl9ZaQp-cdQV_gHdaGSWow
- Disclosure:
- Disclosure:
WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgInBsYWNlX29mX2JpcnRoIiwgeyJ
fc2QiOiBbIktVVmlhYUxuWTVqU01MOTBHMjlPT0xFTlBiYlhmaFNqU1BNalphR2
t4QUUiLCAiWWJzVDBTNzZWcVhDVnNkMWpVU2x3S1BEZ21BTGVCMXVaY2xGSFhmL
VVTUSJdfV0- Contents:
- Contents:
["HbQ4X8srVW3QDxnIJdqyOA", "place_of_birth", {"_sd": ["KUViaaLnY5jSML90G29OOLENPbbXfhSjSPMjZaGkxAE", "YbsT0S76VqXCVsd1jUSlwKPDgmALeB1uZclFHXf-USQ"]}]
["HbQ4X8srVW3QDxnIJdqyOA", "place_of_birth", {"_sd": ["KUViaaLnY5jSML90G29OOLENPbbXfhSjSPMjZaGkxAE", "YbsT0S76VqXCVsd1jUSlwKPDgmALeB1uZclFHXf-USQ"]}]
* Claim 12:
* クレーム 12:
- SHA-256 Hash:
- SHA-256 Hash:
gkvy0FuvBBvj0hs2ZNwxcqOlf8mu2-kCE7-Nb2QxuBU
- Disclosure:
- Disclosure:
WyJDOUdTb3VqdmlKcXVFZ1lmb2pDYjFBIiwgIjEyIiwgdHJ1ZV0
- Contents:
- Contents:
["C9GSoujviJquEgYfojCb1A", "12", true]
* Claim 14:
* クレーム 14:
- SHA-256 Hash:
- SHA-256 Hash:
y6SFrVFRyq50IbRJviTZqqjQWz0tLiuCmMeO0KqazGI
- Disclosure:
- Disclosure:
WyJreDVrRjE3Vi14MEptd1V4OXZndnR3IiwgIjE0IiwgdHJ1ZV0
- Contents:
- Contents:
["kx5kF17V-x0JmwUx9vgvtw", "14", true]
* Claim 16:
* クレーム 16:
- SHA-256 Hash:
- SHA-256 Hash:
hrY4HnmF5b5JwC9eTzaFCUceIQAaIdhrqUXQNCWbfZI
- Disclosure:
- Disclosure:
WyJIM28xdXN3UDc2MEZpMnllR2RWQ0VRIiwgIjE2IiwgdHJ1ZV0
- Contents:
- Contents:
["H3o1uswP760Fi2yeGdVCEQ", "16", true]
* Claim 18:
* クレーム 18:
- SHA-256 Hash:
- SHA-256 Hash:
CVKnly5P90yJs3EwtxQiOtUczaXCYNA4IczRaohrMDg
- Disclosure:
- Disclosure:
WyJPQktsVFZsdkxnLUFkd3FZR2JQOFpBIiwgIjE4IiwgdHJ1ZV0
- Contents:
- Contents:
["OBKlTVlvLg-AdwqYGbP8ZA", "18", true]
* Claim 21:
* クレーム 21:
- SHA-256 Hash:
- SHA-256 Hash:
1tEiyzPRYOKsf7SsYGMgPZKsOT1lQZRxHXA0r5_Bwkk
- Disclosure:
- Disclosure:
WyJNMEpiNTd0NDF1YnJrU3V5ckRUM3hBIiwgIjIxIiwgdHJ1ZV0
- Contents:
- Contents:
["M0Jb57t41ubrkSuyrDT3xA", "21", true]
* Claim 65:
* クレーム 65:
- SHA-256 Hash:
- SHA-256 Hash:
a44-g2Gr8_3AmJw2XZ8kI1y0Qz_ze9iOcW2W3RLpXGg
- Disclosure:
- Disclosure:
WyJEc210S05ncFY0ZEFIcGpyY2Fvc0F3IiwgIjY1IiwgZmFsc2Vd
- Contents:
- Contents:
["DsmtKNgpV4dAHpjrcaosAw", "65", false]
* Claim age_equal_or_over:
* クレーム age_equal_or_over:
- SHA-256 Hash:
- SHA-256 Hash:
2r009dzvHuVrWrRXT5kJMmHnqEHHnWe0MLVZw8PATB8
- Disclosure:
- Disclosure:
WyJlSzVvNXBIZmd1cFBwbHRqMXFoQUp3IiwgImFnZV9lcXVhbF9vcl9vdmVyIiw
geyJfc2QiOiBbIjF0RWl5elBSWU9Lc2Y3U3NZR01nUFpLc09UMWxRWlJ4SFhBMH
I1X0J3a2siLCAiQ1ZLbmx5NVA5MHlKczNFd3R4UWlPdFVjemFYQ1lOQTRJY3pSY
W9ock1EZyIsICJhNDQtZzJHcjhfM0FtSncyWFo4a0kxeTBRel96ZTlpT2NXMlcz
UkxwWEdnIiwgImdrdnkwRnV2QkJ2ajBoczJaTnd4Y3FPbGY4bXUyLWtDRTctTmI
yUXh1QlUiLCAiaHJZNEhubUY1YjVKd0M5ZVR6YUZDVWNlSVFBYUlkaHJxVVhRTk
NXYmZaSSIsICJ5NlNGclZGUnlxNTBJYlJKdmlUWnFxalFXejB0TGl1Q21NZU8wS
3FhekdJIl19XQ- Contents:
- 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_years:
- SHA-256 Hash:
- SHA-256 Hash:
WTpI7RcM3gxZruRpXzezSbkbOr93PVFvWx8woJ3j1cE
- Disclosure:
- Disclosure:
WyJqN0FEZGIwVVZiMExpMGNpUGNQMGV3IiwgImFnZV9pbl95ZWFycyIsIDYyXQ
- Contents:
- Contents:
["j7ADdb0UVb0Li0ciPcP0ew", "age_in_years", 62]
* Claim age_birth_year:
* クレーム age_birth_year:
- SHA-256 Hash:
- SHA-256 Hash:
LezjabRqiZOXzEYmVZf8RMi9xAkd3_M1LZ8U7E4s3u4
- Disclosure:
- Disclosure:
WyJXcHhKckZ1WDh1U2kycDRodDA5anZ3IiwgImFnZV9iaXJ0aF95ZWFyIiwgMTk
2M10- Contents:
- Contents:
["WpxJrFuX8uSi2p4ht09jvw", "age_birth_year", 1963]
* Claim issuance_date:
* クレーム issuance_date:
- SHA-256 Hash:
- SHA-256 Hash:
W14XHbUffzuW4IFMjpSTb1melWxUWf4N_o2ldkkIqc8
- Disclosure:
- Disclosure:
WyJhdFNtRkFDWU1iSlZLRDA1bzNKZ3RRIiwgImlzc3VhbmNlX2RhdGUiLCAiMjA
yMC0wMy0xMSJd- Contents:
- Contents:
["atSmFACYMbJVKD05o3JgtQ", "issuance_date", "2020-03-11"]
* Claim expiry_date:
* クレーム expiry_date:
- SHA-256 Hash:
- SHA-256 Hash:
78jg77-GYBeX8IQfoELPyL0DYPdmfZo0JgViV0_lKCM
- Disclosure:
- Disclosure:
WyI0S3lSMzJvSVp0LXprV3ZGcWJVTEtnIiwgImV4cGlyeV9kYXRlIiwgIjIwMzA
tMDMtMTIiXQ- Contents:
- Contents:
["4KyR32oIZt-zkWvFqbULKg", "expiry_date", "2030-03-12"]
* Claim issuing_authority:
* クレーム issuing_authority:
- SHA-256 Hash:
- SHA-256 Hash:
6ZNISDst62ymlrOAkadjdD5ZulT5A299J78SLhM__Os
- Disclosure:
- Disclosure:
WyJjaEJDc3loeWgtSjg2SS1hd1FEaUNRIiwgImlzc3VpbmdfYXV0aG9yaXR5Iiw
gIkRFIl0- Contents:
- Contents:
["chBCsyhyh-J86I-awQDiCQ", "issuing_authority", "DE"]
* Claim issuing_country:
* クレーム issuing_country:
- SHA-256 Hash:
- SHA-256 ハッシュ:
_ohJVIQIBsU4updNS4_w4Kb1MHqJ0L9qLGshWq6JXQs
- Disclosure:
- Disclosure:
WyJmbE5QMW5jTXo5TGctYzlxTUl6XzlnIiwgImlzc3VpbmdfY291bnRyeSIsICJ
ERSJd- Contents:
- 内容:
["flNP1ncMz9Lg-c9qMIz_9g", "issuing_country", "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:
これは対応する Key Binding JWT のペイロードである。
{
"nonce": "1234567890",
"aud": "https://verifier.example.org",
"iat": 1748537244,
"sd_hash": "PjMYfM07VbJdMxLIluvRNb88JFljSX4n-G43Uc_BSRM"
}After validation, the Verifier will have the following Processed SD- JWT Payload available for further handling:
検証の後、検証者は以降の処理のために次の処理済み 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"
]
}A.4.W3C Verifiable Credentials Data Model v2.0
A.4.W3C Verifiable Credentials Data Model v2.0
This non-normative example illustrates how the artifacts defined in this specification could be used to express a W3C Verifiable Credentials Data Model v2.0 payload [VC_DATA_v2.0].
この非規範的な例は、本仕様で定義された成果物を、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.
Key Binding は、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 ペイロード内のダイジェストは、次の Disclosure を参照している。
* Claim atcCode:
* クレーム atcCode:
- SHA-256 Hash:
- SHA-256 Hash:
1cF5hLwkhMNIaqfWJrXI7NMWedL-9f6Y2PA52yPjSZI
- Disclosure:
- Disclosure:
WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImF0Y0NvZGUiLCAiSjA3QlgwMyJ
d- Contents:
- Contents:
["2GLC42sKQveCfGfryNRN9w", "atcCode", "J07BX03"]
* Claim medicinalProductName:
* クレーム medicinalProductName:
- SHA-256 Hash:
- SHA-256 Hash:
Hiy6WWueLD5bn16298tPv7GXhmldMDOTnBi-CZbphNo
- Disclosure:
- Disclosure:
WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgIm1lZGljaW5hbFByb2R1Y3ROYW1
lIiwgIkNPVklELTE5IFZhY2NpbmUgTW9kZXJuYSJd- Contents:
- Contents:
["eluV5Og3gSNII8EYnsxA_A", "medicinalProductName", "COVID-19 Vaccine Moderna"]
["eluV5Og3gSNII8EYnsxA_A", "medicinalProductName", "COVID-19 Vaccine Moderna"]
* Claim marketingAuthorizationHolder:
* クレーム marketingAuthorizationHolder:
- SHA-256 Hash:
- SHA-256 Hash:
Lb027q691jXXl-jC73vi8ebOj9smx3C-_og7gA4TBQE
- Disclosure:
- Disclosure:
WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgIm1hcmtldGluZ0F1dGhvcml6YXR
pb25Ib2xkZXIiLCAiTW9kZXJuYSBCaW90ZWNoIl0- Contents:
- Contents:
["6Ij7tM-a5iVPGboS5tmvVA", "marketingAuthorizationHolder", "Moderna Biotech"]
["6Ij7tM-a5iVPGboS5tmvVA", "marketingAuthorizationHolder", "Moderna Biotech"]
* Claim nextVaccinationDate:
* クレーム nextVaccinationDate:
- SHA-256 Hash:
- SHA-256 Hash:
R2fGbfA07Z_YlkqmNZyma1xyyx1XstIiS6B1Ybl2JZ4
- Disclosure:
- Disclosure:
WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgIm5leHRWYWNjaW5hdGlvbkRhdGU
iLCAiMjAyMS0wOC0xNlQxMzo0MDoxMloiXQ- Contents:
- Contents:
["eI8ZWm9QnKPpNPeNenHdhQ", "nextVaccinationDate", "2021-08-16T13:40:12Z"]
["eI8ZWm9QnKPpNPeNenHdhQ", "nextVaccinationDate", "2021-08-16T13:40:12Z"]
* Claim countryOfVaccination:
* クレーム countryOfVaccination:
- SHA-256 Hash:
- SHA-256 Hash:
JzjLgtP29dP-B3td12P674gFmK2zy81HMtBgf6CJNWg
- Disclosure:
- Disclosure:
WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImNvdW50cnlPZlZhY2NpbmF0aW9
uIiwgIkdFIl0- Contents:
- Contents:
["Qg_O64zqAxe412a108iroA", "countryOfVaccination", "GE"]
* Claim dateOfVaccination:
* クレーム dateOfVaccination:
- SHA-256 Hash:
- SHA-256 Hash:
zJK_eSMXjwM8dXmMZLnI8FGM08zJ3_ubGeEMJ-5TBy0
- Disclosure:
- Disclosure:
WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgImRhdGVPZlZhY2NpbmF0aW9uIiw
gIjIwMjEtMDYtMjNUMTM6NDA6MTJaIl0- Contents:
- Contents:
["AJx-095VPrpTtN4QMOqROA", "dateOfVaccination", "2021-06-23T13:40:12Z"]
["AJx-095VPrpTtN4QMOqROA", "dateOfVaccination", "2021-06-23T13:40:12Z"]
* Claim order:
* クレーム order:
- SHA-256 Hash:
- SHA-256 Hash:
b0eUsvGP-ODDdFoY4NlzlXc3tDslWJtCJF75Nw8Oj_g
- Disclosure:
- Disclosure:
WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgIm9yZGVyIiwgIjMvMyJd
- Contents:
- Contents:
["Pc33JM2LchcU_lHggv_ufQ", "order", "3/3"]
* Claim gender:
* クレーム gender:
- SHA-256 Hash:
- SHA-256 Hash:
3nzLq81M2oN06wdv1shHvOEJVxZ5KLmdDkHEDJABWEI
- Disclosure:
- Disclosure:
WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiwgImdlbmRlciIsICJGZW1hbGUiXQ
- Contents:
- Contents:
["G02NSrQfjFXQ7Io09syajA", "gender", "Female"]
* Claim birthDate:
* クレーム birthDate:
- SHA-256 Hash:
- SHA-256 Hash:
Pn1sWi06G4LJrnn-_RT0RbM_HTdxnPJQuX2fzWv_JOU
- Disclosure:
- Disclosure:
WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImJpcnRoRGF0ZSIsICIxOTYxLTA
4LTE3Il0- Contents:
- Contents:
["lklxF5jMYlGTPUovMNIvCA", "birthDate", "1961-08-17"]
* Claim givenName:
* クレーム givenName:
- SHA-256 Hash:
- SHA-256 Hash:
lF9uzdsw7HplGLc714Tr4WO7MGJza7tt7QFleCX4Itw
- Disclosure:
- Disclosure:
WyJuUHVvUW5rUkZxM0JJZUFtN0FuWEZBIiwgImdpdmVuTmFtZSIsICJNYXJpb24
iXQ- Contents:
- Contents:
["nPuoQnkRFq3BIeAm7AnXFA", "givenName", "Marion"]
* Claim familyName:
* クレーム familyName:
- SHA-256 Hash:
- SHA-256 Hash:
1lSQBNY24q0Th6OGzthq-7-4l6cAaxrYXOGZpeW_lnA
- Disclosure:
- Disclosure:
WyI1YlBzMUlxdVpOYTBoa2FGenp6Wk53IiwgImZhbWlseU5hbWUiLCAiTXVzdGV
ybWFubiJd- Contents:
- Contents:
["5bPs1IquZNa0hkaFzzzZNw", "familyName", "Mustermann"]
* Claim administeringCentre:
* クレーム administeringCentre:
- SHA-256 Hash:
- SHA-256 Hash:
TCmzrl7K2gev_du7pcMIyzRLHp-Yeg-Fl_cxtrUvPxg
- Disclosure:
- Disclosure:
WyI1YTJXMF9OcmxFWnpmcW1rXzdQcS13IiwgImFkbWluaXN0ZXJpbmdDZW50cmU
iLCAiUHJheGlzIFNvbW1lcmdhcnRlbiJd- Contents:
- Contents:
["5a2W0_NrlEZzfqmk_7Pq-w", "administeringCentre", "Praxis Sommergarten"]
["5a2W0_NrlEZzfqmk_7Pq-w", "administeringCentre", "Praxis Sommergarten"]
* Claim batchNumber:
* クレーム batchNumber:
- SHA-256 Hash:
- SHA-256 Hash:
V7kJBLK78TmVDOmrfJ7ZuUPHuK_2cc7yZRa4qV1txwM
- Disclosure:
- Disclosure:
WyJ5MXNWVTV3ZGZKYWhWZGd3UGdTN1JRIiwgImJhdGNoTnVtYmVyIiwgIjE2MjY
zODI3MzYiXQ- Contents:
- Contents:
["y1sVU5wdfJahVdgwPgS7RQ", "batchNumber", "1626382736"]
* Claim healthProfessional:
* クレーム healthProfessional:
- SHA-256 Hash:
- SHA-256 ハッシュ:
1V_K-8lDQ8iFXBFXbZY9ehqR4HabWCi5T0ybIzZPeww
- Disclosure:
- Disclosure:
WyJIYlE0WDhzclZXM1FEeG5JSmRxeU9BIiwgImhlYWx0aFByb2Zlc3Npb25hbCI
sICI4ODMxMTAwMDAwMTUzNzYiXQ- Contents:
- 内容:
["HbQ4X8srVW3QDxnIJdqyOA", "healthProfessional", "883110000015376"]
["HbQ4X8srVW3QDxnIJdqyOA", "healthProfessional", "883110000015376"]
This is an example of an SD-JWT+KB that discloses only type, medicinalProductName, atcCode of the vaccine, type of the recipient, type, order, and dateOfVaccination:
これは、vaccine の type、medicinalProductName、atcCode、recipient の type、および type、order、dateOfVaccination のみを開示する 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"
}
}
}A.5.Elliptic Curve Key Used in the Examples
A.5.例で使用した楕円曲線鍵
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.
Key Binding JWT の検証に用いる公開鍵は、例の中の cnf クレームの内容として見つけることができる。
B.Disclosure Format Considerations
B.Disclosure の形式に関する考慮事項
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 節で述べたように、Disclosure の構造はソルトとクレームの平文の内容を含む 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 つの表現はバイトレベルでは大きく異なるが、等価なオブジェクトを生み出す。address の表現についても同じことが言え、こちらは空白とオブジェクト内の要素の順序が異なっている。
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 文字のエンコーディングのばらつきはいずれも JSON 仕様によって許容されており、[RFC8785] に記述されているように、例えば浮動小数点数に関するものなど、さらなるばらつきも含まれる。ばらつきは 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. ソース文字列の固定化: ばらつきを生じ得る形式でデータを転送する代わりに、データの表現をシリアライズする。この表現は検証者側でハッシュの入力として使われるだけでなく、検証者に転送され、検証者側でも同じダイジェスト計算に使われる。つまり検証者は、最終的にデータをデシリアライズしてアクセスする前に、バイト列のダイジェストを容易に計算して確認できる。
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 データとダイジェスト計算に適した文字列の両方を転送することも考えられるが、そのようなアプローチは検出されない不整合を容易に引き起こし、time-of-check-time-of-use 型のセキュリティ脆弱性につながる。
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 を使用し、各 Disclosure の平文の内容は転送のために base64url エンコーディングを用いてエンコードされる。このアプローチにより、SD-JWT は広く利用可能な JWT、JSON、および Base64 のエンコード/デコードライブラリだけで実装できる。
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.
Disclosure は、検証者による検証の後に開示されたクレーム値にアクセスする必要のあるアプリケーションが直接消費することを意図したものでも、それに適したものでもないことに留意することが重要である。Disclosure は、検証者がソース文字列に対するダイジェストを確認し、元の JSON データを取り出すために使用することだけを意図している。その後、元の JSON データがアプリケーションによって使用される。詳細は 7.3 節を参照。
Acknowledgements
謝辞
We would like to thank Alen Horvat, Alex Hodder, Anders Rundgren, Arjan Geluk, Chad Parry, Christian Bormann, Christian Paquin, Dale Bowie, Dan Moore, David Bakker, David Waite, Deb Cooley, Fabian Hauck, Filip Skokan, Giuseppe De Marco, Jacob Ward, Jeffrey Yasskin, John Preuß Mattsson, Joseph Heenan, Justin Richer, Kushal Das, Martin Thomson, Matthew Miller, Michael Fraser, Michael B. Jones, Mike Prorock, Nat Sakimura, Neil Madden, Oliver Terbu, Orie Steele, Paul Bastian, Peter Altmann, Pieter Kasselman, Richard Barnes, Rohan Mahy, Roman Danyliw, Ryosuke Abe, Sami Rosendahl, Shawn Butterfield, Shawn Emery, Simon Schulz, Takahiko Kawasaki, Tobias Looker, Torsten Lodderstedt, Vittorio Bertocci, Watson Ladd, and Yaron Sheffer for their contributions (some of which were substantial) to this document and to the initial set of implementations.
本文書および初期の実装群への貢献 (その一部は多大なものであった) について、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、および Yaron Sheffer の各氏に感謝する。
The work on this document was started at the OAuth Security Workshop 2022 in Trondheim, Norway.
本文書の作業は、ノルウェーのトロンハイムで開催された OAuth Security Workshop 2022 で始まった。