W3C Verifiable Credentials Overviewを読む（９）

こんにちは、富士榮です。

引き続きW3C Verifiable Credentials Overviewを読んでいきます。

1. Introduction
2. Ecosystem Overview
3. Verifiable Credentials Data Model
4. Securing Credentials
5. Bitstring Status List
6. Additional Publications

今回も引き続き4番目のSecuring Credentialsを見ていきます。

続きなのでCryptosuitesのところからですね。

2.3. Cryptosuites

The Working Group publishes three cryptosuite documents: Data Integrity ECDSA Cryptosuites v1.0 [VC-DI-ECDSA], Data Integrity EdDSA Cryptosuites v1.0 [VC-DI-EDDSA], and Data Integrity BBS Cryptosuites v1.0 [VC-DI-BBS]. As their name suggests, the documents rely on existing cryptographic signature schemes: the Elliptic Curve Digital Signature Algorithm (ECDSA) specification [FIPS-186-5], the Edwards-Curve Digital Signature Algorithm (EdDSA) specification [RFC8032], and the BBS Signature Scheme [CFRG-BBS-SIGNATURE], respectively.

Figure 8 provides an overall view of the six cryptosuites defined by the three recommendations. They all implement the general structure of proofs as described in 4.2.1 Generic Data Integrity Structure. As shown on the figure, one axes of differentiation is the data transformation function, i.e., the canonicalization of the JSON serialization: two cryptosuites use JSON Canonicalization (JCS) [RFC8785], the others use RDF Dataset Canonicalization (RDFC-1.0) [RDF-CANON]. The other axis is whether the cryptosuite provides selective disclosure, which is the case for two of the six cryptosuites.

ワーキンググループは、3つの暗号スイート文書を公開しています。データ完全性ECDSA暗号スイートv1.0 [VC-DI-ECDSA]、データ完全性EdDSA暗号スイートv1.0 [VC-DI-EDDSA]、データ完全性BBS暗号スイートv1.0 [VC-DI-BBS]です。これらの文書はその名称が示すように、それぞれ、楕円曲線デジタル署名アルゴリズム（ECDSA）仕様書 [FIPS-186-5]、エドワーズ曲線デジタル署名アルゴリズム（EdDSA）仕様書 [RFC8032]、BBS 署名方式 [CFRG-BBS-SIGNATURE] といった既存の暗号署名方式に基づいています。

図 8 は、3 つの勧告で定義された 6 つの暗号スイートの全体像を示しています。これらはすべて、4.2.1 汎用データ完全性構造で説明されている証明の一般的な構造を実装しています。図に示されているように、差別化要因の1つはデータ変換機能、すなわちJSONシリアライズの正規化です。2つのcryptosuiteはJSON Canonicalization (JCS) [RFC8785]を使用しており、他のcryptosuiteはRDF Dataset Canonicalization (RDFC-1.0) [RDF-CANON]を使用しています。もう一つの軸は、暗号スイートが選択的開示機能を備えているかどうかです。6つの暗号スイートのうち2つは選択的開示機能を備えています。

図8. Generic view of the proof generation steps.

この図にあるように、3つの暗号化スイートを定義しており、それぞれについて正規化のパターンで分類をしています。また大切なのは選択的開示（Selective Disclosure）を実現できるかどうか、です。このW3CのドキュメントにあるBBSか、IETFのSD-JWT-VCなのか、ということがしばしば対立軸的に語られますがいずれにしても選択的開示は必要になるケースが増えてくると思うので、この辺りを中心に押さえていけると良いと思います。

NOTE 

A common characteristics of all these cryptosuites is that keys must always be encoded using the Multikey encoding. The keys, whose exact formats are defined in the respective signature scheme specifications, also carry the choice of the hash functions to be used by the proof generation algorithm. This provides yet another differentiation axis among cryptosuites although, in practice, SHA-256 [RFC6234] is usually used.

注

これらの暗号スイートに共通する特徴は、キーを常にマルチキーエンコーディングでエンコードしなければならないことです。キーの正確なフォーマットは、それぞれの署名スキームの仕様で定義されていますが、証明生成アルゴリズムで使用されるハッシュ関数の選択もキーに含まれます。これにより、暗号スイート間の差別化要素がさらに1つ追加されますが、実際には通常、SHA-256 [RFC6234] が使用されます。

2.3.1. Full Disclosure Schemes

The two EdDSA cryptosuites, as well as ecdsa-rdfc-2019 and ecdsa-jcs-2019, follow the proof generation pipeline as described in 4.2.1 Generic Data Integrity Structure: the Credential is canonicalized (using either JCS or RDFC-1.0), the result is hashed (using the hash functions as defined by the signature key), and the proof is generated using that hash value. There is, however, an extra twist: the same pipeline is also used on a set of claims called "proof options", i.e., all the claims of the proof graph except proofValue. This set of claims is therefore also canonicalized and hashed, following the same process as for the Credential, yielding a second hash value. It is the concatenation of these two values that is signed by EdDSA or ECDSA, respectively, producing a value for the proofValue property.

2つのEdDSA暗号スイート、ecdsa-rdfc-2019およびecdsa-jcs-2019は、4.2.1で説明されている証明生成パイプラインに従います。一般的なデータ完全性構造：クレデンシャルは正規化され（JCS または RDFC-1.0 を使用）、その結果はハッシュ化され（署名鍵で定義されたハッシュ関数を使用）、そのハッシュ値を使用して証明が生成されます。ただし、さらに別の工夫がされています。同じパイプラインが「proof options」と呼ばれる一連のクレームにも使用されているのです。つまり、proofValue を除く証明グラフのすべてのクレームです。この一連のクレームも、クレデンシャルと同じプロセスに従って正規化およびハッシュ化され、2つ目のハッシュ値が算出されます。これらの2つの値の連結が、EdDSAまたはECDSAによってそれぞれ署名され、proofValueプロパティの値が生成されます。

署名対象となるクレデンシャルに加えてproof optionsに関しても変換・ハッシュ化・Proof作成というステップを踏むわけですね。

2.3.2. Selective Disclosure Schemes

The ecdsa-sd-2023 and bbs-2023 cryptosuites provide selective disclosures of individual claims. In both cases, the process separates the "Base Proof" (calculated by the issuer), and the "Derived Proof" (which is typically calculated by the holder when selectively presenting the credential claims to the verifier). The challenge is that the verifier should check that the holder can be trusted when verifying a partial value, without having access to the full original data.

To calculate the Base Proof, the Credential is supplemented with extra information that separates the "mandatory" and "non-mandatory" claims. Using that extra information, the transformation step described in 4.2.1 Generic Data Integrity Structure does not only canonicalize the Credential, but also transforms it by explicitly separating these two types of claims into their own sets. Furthermore, each non-mandatory claim must be signed individually, yielding a series of signatures. The final Base Proof is, conceptually, the concatenation of all these signatures and related informations like the separation of mandatory and non-mandatory claims.

The Derived Proof is generated by the holder, when presenting the (derived) Credential. These data are combined with the kind of selective disclosure requests the holder is prepared to honor; it is the combination of all these data that are used for the creation of a Derived Proof that is forwarded to the verifier.

ecdsa-sd-2023およびbbs-2023暗号スイートは、個々のクレームを選択的に開示します。いずれの場合も、プロセスは「ベースプルーフ」（発行者によって算出）と「派生プルーフ」（通常、検証者にクレデンシャルクレームを選択的に提示する際に保有者によって算出）を分離します。検証者は、元のデータ全体にアクセスすることなく、部分的な値を検証する際に、保有者が信頼できることを確認する必要があります。 

ベースプルーフを計算するために、クレデンシャルには「必須」と「非必須」の主張を区別する追加情報が追加されます。この追加情報を使用して、4.2.1 汎用データ完全性構造で説明されている変換ステップでは、クレデンシャルを正規化するだけでなく、これらの2種類の主張をそれぞれのセットに明示的に分離して変換します。さらに、各非必須の主張は個別に署名され、一連の署名が生成されます。最終的なベースプルーフは、概念的には、これらの署名と必須および非必須の主張の分離などの関連情報の連結です。

派生証明は、（派生）クレデンシャルを提示する際に、保有者によって生成されます。これらのデータは、保有者が応じる用意のある選択的開示要求の種類と組み合わせられます。検証者に送付される派生証明の作成には、これらのデータの組み合わせがすべて使用されます。

選択的開示をするためにベースプルーフと派生プルーフに分けるんですね。開示したくない属性を落としても全体として完全であるということを示さなければならないので、開示されない可能性のある派生クレームについては個別で署名をしていくということのようです。

2.4. Example: the Core Example Secured with ECDSA

The Credential example, shown in Example 1, and enriched with a reference to a JSON Schema in Example 3, can be secured via an embedded proof as follows:

例 1 の「Credential」の例では、例 3 の JSON スキーマへの参照を付加することで、次のように埋め込み証明を使用してセキュリティ保護することができます。

EXAMPLE 9: An ECDSA proof added to a Credential

{
  "@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",
    "cryptosuite": "ecdsa-rdfc-2019",
    "created": "2010-01-01T00:00:00Z",
    "expires": "2040-01-01T00:00:00Z",
    "verificationMethod: "did:example:2g55q912ec3476eba2l9812ecbfe#ecdsa-public-key"
    "proofPurpose": "assertionMethod"
    "proofValue": "zQeVb…Wx"
  } 

}

When dereferenced, the URL did:example:2g55q912ec3476eba2l9812ecbfe#ecdsa-public-key should return an ECDSA public key in Multikey format, for example:

dereferenced された URL、:example:2g55q912ec3476eba2l9812ecbfe#ecdsa-public-key は、例えば次のような Multikey 形式の ECDSA 公開鍵を返すべきです。

EXAMPLE 10: An ECDSA public key

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/multikey/v1"
  ],
  "id": "did:example:2g55q912ec3476eba2l9812ecbfe#ecdsa-public-key",
  "type": "Multikey",
  "controller": "did:example:2g55q912ec3476eba2l9812ecbfe",
  "publicKeyMultibase": "z42twTcNeSYcnqg1FLuSFs2bsGH3ZqbRHFmvS9XMsYhjxvHN" 

}

Note that the value of the verificationMethod property may have been the public key itself, instead of a reference to a separate resource containing the key.

検証方法プロパティ（verificationMethod）の値は、キーを含む別のリソースへの参照ではなく、公開キーそのものである可能性があることに注意してください。

proof内のverificationMethodのプロパティに設定されたdidに関連するdid documentから公開鍵を取得するわけですね。（注意書きにもある通り公開鍵そのものが設定されるケースもある）

ということでこれでSecuring credentialsの章はおしまいです。

次から本文の最後となるbitstring statuslistの話です。要するにCredentilasのRevokeをした場合のステータスをどうやって表すのかという話ですね。

ではまた次回。