こんにちは、富士榮です。
ようやく折り返しましたが引き続きW3C Verifiable Credentials Overviewを読んでいきます。
- Introduction
- Ecosystem Overview
- Verifiable Credentials Data Model
- Securing Credentials
- Bitstring Status List
- Additional Publications
今回も引き続き4番目のSecuring Credentialsを見ていきます。
前回はEnvelop proof（JWS）だったので、今回はEmbedded Proof（VC Data Integrity）を見ていきます。
2. Embedded Proofs
2.1. Generic Data Integrity Structure
The operation of Data Integrity is conceptually simple. To create a cryptographic proof, the following steps are performed: 1) Transformation, 2) Hashing, and 3) Proof Generation.
データ完全性の操作は概念的には単純です。暗号証明を作成するには、次のステップを実行します。1) 変換、2) ハッシュ化、3) 証明生成。
 |
| 図7. Generic view of the proof generation steps. |
Data Integrity Proofの作成は変換、ハッシュを行った上でProofを作成する、という流れということです。続いて各ステップについて解説がされています。
- Transformation is a process described by a transformation algorithm that takes input data and prepares it for the hashing process. In the case of data serialized in JSON this transformation includes the removal of all the artifacts that do not influence the semantics of the data like spaces, new lines, the order of JSON names, etc. (a step often referred to as canonicalization). In some cases the transformation may be more involved.
- Hashing is a process described by a hashing algorithm that calculates an identifier for the transformed data using a cryptographic hash function. Typically, the size of the resulting hash is smaller than the data, which makes it more suitable for complex cryptographic functions like digital signatures.
- Proof Generation is a process described by a proof method that calculates a value that protects the integrity of the input data from modification or otherwise proves a certain desired threshold of trust. A typical example is the application of a cryptographic signature using asymmetric keys, yielding the signature of the data.
- 変換とは、入力データを受け取り、ハッシュ化処理の準備をする変換アルゴリズムによって記述されるプロセスです。JSONでシリアライズされたデータの場合、変換には、スペース、改行、JSON名の順序など、データの意味に影響を与えないアーティファクトの除去が含まれます（正規化と呼ばれるステップ）。場合によっては、変換はより複雑になることがあります。
- ハッシュ化は、暗号ハッシュ関数を使用して変換されたデータの識別子を計算するハッシュアルゴリズムによって記述されるプロセスです。通常、生成されたハッシュのサイズはデータよりも小さいため、デジタル署名のような複雑な暗号機能に適しています。
- 証明生成とは、証明方法によって記述されるプロセスであり、入力データの整合性を改ざんから保護する値、または特定の信頼性基準を満たすことを証明する値を計算します。典型的な例として、非対称鍵を使用した暗号署名アプリケーションがあり、これによりデータの署名が生成されます。
このTransformにおける正規化（Canonicalization）がしばしば問題視されるところですね。
以前SAMLの脆弱性についてこのブログでも取り上げましたが、実際にシリアライズを正しく安全に行う、というのは難しいところです。OpenID Connectの設計思想としてIdentiverseでも取り上げられていたのはまさに「No canonicalization」でした。SAMLでの苦い思い出から正規化をせずにクレデンシャルを表現できる方式としてJWSを採用したわけです。
Verification of a proof involves repeating the same steps on the verifier's side and, depending on the proof method, validating the newly calculated proof value with the one associated with the data. In the case of a digital signature, this test usually means comparing the calculated signature value with the one which is embedded in the data.
証明の検証には、検証者側で同じ手順を繰り返す必要があり、証明方法によっては、新たに計算された証明値をデータに関連付けられた値で検証します。デジタル署名の場合、このテストは通常、計算された署名値とデータに埋め込まれた署名値を比較することを意味します。
2.2. VC Data Integrity
The Verifiable Credential Data Integrity 1.0 [VC-DATA-INTEGRITY] specification relies on the general structure and defines a set of standard properties describing the details of the proof generation process. The specific details (canonicalization algorithm, hash and/or proof method algorithms, etc.) are defined by separate cryptosuites. The Working Group has defined a number of such cryptosuites as separate specifications, see 4.2.3 Cryptosuites below.
The core property, in the general structure, is proof. This property embeds a claim in the Credential, referring to a separate collection of claims (referred to as a Proof Graph) detailing all the claims about the proof itself:
検証可能な資格情報データ完全性 1.0 [VC-DATA-INTEGRITY] 仕様は、一般的な構造に依存し、証明生成プロセスの詳細を説明する一連の標準プロパティを定義します。具体的な詳細（正規化アルゴリズム、ハッシュおよび/または証明方法アルゴリズムなど）は、別の暗号スイートによって定義されます。ワーキンググループは、このような暗号スイートを別個の仕様として多数定義しています。詳細は、以下の4.2.3 暗号スイートを参照してください。
一般的な構造におけるコアとなる特性は「証明」です。この特性は、クレデンシャルにクレームを埋め込み、証明自体に関するすべてのクレームを詳細に説明する別個のクレーム集合（証明グラフと呼ばれる）を参照します。
VC Data Integrityの使用は別途策定されていますが、まだW3C勧告とはなっておらずCR（Candidate Recommendation）の状態です。
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://www.example.org/vocabs/alumni"
],
"id": "https://university.example/Credential123",
"type": ["VerifiableCredential", "ExampleAlumniCredential"],
"issuer": "did:example:2g55q912ec3476eba2l9812ecbfe",
"validFrom": "2010-01-01T00:00:00Z",
"credentialSubject": {
"id": "https://www.example.org/persons/pat",
"name": "Pat",
"alumniOf": {
"id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
"name": "Example University"
}
},
"credentialSchema": {
"id": "https://university.example/Credential123-schema-credential",
"type": "JsonSchemaCredential"
},
"proof": {
"type": "DataIntegrityProof",
…
// All the details about the proof
…
"proofValue": "zQeVb…Wx"
}
}Note the proofValue property, whose object is the result of the proof generation process.
proofValue プロパティに注目してください。このプロパティのオブジェクトは、証明生成プロセスの結果です。
The proof value is for illustrative purposes only, and does not reflect the result of real cryptographic calculations.
実際のサンプルが示されています。proofのtypeに"DataIntegrityProof”、そしてvalueのところに計算された値が入ることになります。
The definition of proof introduces a number of additional properties. Some of these are metadata properties on the proof itself, like created, expires, or domain. Others provide the necessary details on the proof generation process itself, like cryptosuite, nonce (if needed), or verificationMethod that usually refers to cryptographic keys. The exact format of the public keys, when used for Credentials, is defined in the [CONTROLLER-DOCUMENT] specification, and is based on either the JWK [RFC7517] format or a Multibase [MULTIBASE] encoding of the keys, called Multikey. Details of the key values are defined by other communities (IETF, cryptography groups, etc.) and are dependent on the specific cryptographic functions they operate with.
It is possible to embed several proofs for the same Credential. These may be a set of independent proofs (based, for example, on different cryptosuites, to accommodate to the specificities of different verifiers), but may also be a "chain" of proofs that must be evaluated in a given order.
A proof may also specify its "purpose" via the proofPurpose property: different proofs may be provided for authentication, for assertion, or for key agreement protocols. These possible purposes are defined in the [CONTROLLER-DOCUMENT] specification. The verifier is supposed to choose the right proof depending on the purpose of its own operations, which is yet another possible reasons why the holder or the issuer may provide several proofs for the same Credential.
証明の定義には、いくつかの追加プロパティが含まれます。その中には、証明自体のメタデータプロパティ（作成日、有効期限、ドメインなど）もあります。また、証明生成プロセス自体の詳細を提供するプロパティもあります（cryptosuite、nonce（必要な場合）、通常、暗号鍵を指す verificationMethod など）。クレデンシャルに使用される公開鍵の正確なフォーマットは、[CONTROLLER-DOCUMENT] 仕様で定義されており、JWK [RFC7517] フォーマットまたは Multikey と呼ばれる公開鍵の Multibase [MULTIBASE] エンコーディングのいずれかに基づいています。鍵値の詳細は、他のコミュニティ（IETF、暗号グループなど）によって定義されており、使用する特定の暗号機能に依存します。
同じクレデンシャルに対して複数の証明を埋め込むことが可能です。これらは独立した証明のセット（例えば、異なる検証者の特殊性に対応するために異なる暗号スイートに基づく）の場合もありますが、所定の順序で評価しなければならない証明の「チェーン」の場合もあります。
証明は、proofPurposeプロパティを通じてその「目的」を指定することもできます。異なる証明は、認証、アサーション、または鍵合意プロトコル用に提供されます。これらの可能な目的は、[CONTROLLER-DOCUMENT]仕様で定義されています。検証者は、自身の操作の目的に応じて適切な証明を選択することが想定されています。これが、同じクレデンシャルに対して複数の証明を提供する理由の1つです。
Data Integrityの特徴で便利だと思うのは複数のProofを埋め込むことができる点、そして目的を指定することができる点です。例えば、学修歴など複数の教員によって証明されることがあるクレデンシャルについてはこの機能は有用なのかもしれません。
長くなってきたので、続きのCryptosuiteからは次回に送りたいと思います。
投稿
