W3C Verifiable Credentials Overviewが更新されました

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

先月から読んできたW3C Verifiable Credential Overviewが少しだけ更新されています。

2024年6月13日版から2024年7月6日版への更新です。

まぁ、結果的にあまり大きな更新はありませんでした。サンプルが変わったくらいです。

ざっと変化点を。

1. サンプルの@Contextが変わった

3.2 Serialization in JSON

Example1:

@Contextに指定されているボキャブラリーが

"https://www.example.org/vocabs/alumni"

から、ネームスペース

"https://www.w3.org/ns/credentials/examples/v2"

へ変更されています。これは以降のExampleでも同様です。

2. サンプルの$idが変わった

同じくExample4では$idの値が、

"https://example.com/schemas/email.json"

から、

"https://university.example/schemas/credential.json"

へ変更されています。

3. JOSEに加えてCOSEのサンプルも載せようとしている

Example 6: A Simple Credential in JWT (unencoded)では前のバージョンではJOSEのサンプルだけだったのがCredential本体、JOSE、COSEの3つがタブで選択表示できるようになっています。だた、現状ではCredential部分しか書かれていないのでそのうちJOSEとCOSEのサンプルも書かれると思います。

4. ECDSAに加えてEdDSAのサンプルも載せようとしている

Example 8: the Core Example Secured with ECDSAの部分は、ECDSAだけのサンプルだったのがEdDSAのサンプルが追加されています。こちらもExample 6と同様にCredential本体、ECDSA、EdDSAでタブに分かれていますが、まだCredential本体部分しか記載がありません。

5. 完全なサンプルを纏めとして載せようとしている

最後にExample 12にComplete Exampleという形でVerifiable Credential with a Reference to a Credential Schema and to a Status ListがCredential本体、ECDSA、EdDSA、BBS、JOSE、SD-JWT、COSEのそれぞれでのサンプルが追記されようとしています。（同じくCredential部分しか書かれていない）

うん、まだまだ更新がかかるんだと思います。

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

ようやくメイン部分の最後にあたるBitstring Status Listです。

これは、以前Status List 2021の解説をしたときはDIF（Decentralized Identity Foundation）のスペックだったのがW3Cに移管されたものです。

中身はあんまり変わっていません。相変わらず微妙なスペックです・・・・（そもそも16Kbで実装しちゃうと後からハマる、今時ビット配列をパースするのは面倒くさい・・・など）

何はともあれみていきます。

It is often useful for an issuer of Verifiable Credentials to link to a location where a verifier can check to see if a credential has been suspended or revoked. This additional resource is referred to as a "status list".

The simplest approach for a status list, where there is a one-to-one mapping between a Verifiable Credential and a URL where the status is published, raises privacy as well as performance issues. In order to meet privacy expectations, it is useful to bundle the status of large sets of credentials into a single list to help with group privacy. However, doing so can place an impossible burden on both the server and client if the status information is as much as a few hundred bytes in size per credential across a population of hundreds of millions of holders. The Bitstring Status List v1.0 [VC-BITSTRING-STATUS-LIST] specification defines a highly compressible, highly space-efficient bitstring-based status list mechanism.

Conceptually, a bitstring status list is a sequence of bits. When a single bit specifies a status, such as "revoked" or "suspended", then that status is expected to be true when the bit is set and false when unset. One of the benefits of using a bitstring is that it is a highly compressible data format since, in the average case, large numbers of credentials will remain unrevoked. If compressed using run-length compression techniques such as GZIP [RFC1952] the result is a significantly smaller set of data: the default status list size is 131,072 entries, equivalent to 16 KB of single bit values and, when only a handful of verifiable credentials are revoked, GZIP compresses the bitstring down to a few hundred bytes.

検証可能な資格情報の発行者は、資格情報が停止または取り消されたかどうかを確認できる場所へのリンクを張ることが有用な場合があります。この追加リソースは「ステータスリスト」と呼ばれます。

検証可能な資格情報とステータスが掲載されている URL との 1 対 1 の対応関係があるステータスリストの最も単純なアプローチは、プライバシーとパフォーマンスの両面で問題が生じます。プライバシーに関する期待に応えるためには、多数の資格情報のステータスを 1 つのリストにまとめてグループとしてのプライバシー保護に役立てる方法が有効です。しかし、数百万人規模の保有者に対して、1つのクレデンシャルにつきステータス情報が数百バイトにも及ぶ場合、サーバーとクライアントの両方に不可能なほどの負担がかかる可能性があります。Bitstring Status List v1.0 [VC-BITSTRING-STATUS-LIST] 仕様では、非常に圧縮率が高く、スペース効率に優れたビットストリングベースのステータスリストの仕組みが定義されています。

概念的には、ビット文字列ステータスリストはビットのシーケンスです。1つのビットが「無効」や「一時停止」などのステータスを指定する場合、そのビットが設定されているときはステータスが有効、設定されていないときはステータスが無効であると見なされます。ビット文字列を使用する利点の一つは、圧縮率が高いデータ形式であることです。平均的な場合、多数のクレデンシャルは有効のままであるからです。GZIP [RFC1952] などのランレングス圧縮技術を使用して圧縮すると、データセットが大幅に縮小されます。デフォルトのステータスリストサイズは 131,072 エントリで、16 KB の単一ビット値に相当します。検証可能なクレデンシャルのうちごく一部にのみ無効化処理が実行された場合、GZIP 圧縮によりビット文字列は数百バイトにまで縮小されます。

まぁ、思想はわかります。

有効性確認をするためにIssuerに問い合わせをしちゃうとHolderがどのVerifierにクレデンシャルを提示しようとしているのかがわかってしまいますから。その意味でStatus Listを独立させた形で持たせるのはわかりますし、あまり情報量を多くするとパフォーマンス問題につながることも理解出来ます。その意味でビットで管理するのも理解はできますが、実装者にとって見積もりが難しいです。131,072までしかクレデンシャルを発行しないのか？後から増やそうと思ったらどうできるのか、諸々考えることはあります。まさにご利用は計画的に。

図9. A visual depiction of the concepts outlined in this section.

The specification introduces the credentialStatus property, as well as some additional sub-properties, that should be used to add this additional information to a Verifiable Credential.

Example 11 shows our example from Example 9, combined with the information on the credential status: the purpose of that status information, the reference to the bitstring, and the index into this bitstring for the enclosing credential:

この仕様では、Verifiable Credential にこの追加情報を追加するために使用されるべき、credentialStatus プロパティと、いくつかの追加サブプロパティが導入されています。

例 11 は、例 9 の例に、クレデンシャルのステータスに関する情報を加えたものです。ステータス情報の目的、ビット列への参照、およびこのビット列の、クレデンシャルを囲むためのインデックスを示しています。

EXAMPLE 11: Verifiable Credential with a Reference to a Status List

{
  "@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"
  },
  "credentialStatus": {
    "id": "https://university.example/statuslist#123456",
    "type": "BitstringStatusListEntry",
    "statusPurpose": "revocation",
    "statusListIndex": "123456",
    "statusListCredential": "https://university.example/CredentialStatusList"
  },
  "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"
  } 

} 

The statusListCredential property, when dereferenced, should return a separate Credential for the status list. The status list itself is the subject of that Credential (which, of course, can also be signed). An example is:

statusListCredential プロパティは、参照解除されると、ステータスリスト用の個別のクレデンシャルを返します。ステータスリスト自体がそのクレデンシャルの対象となります（もちろん、署名することもできます）。例：

EXAMPLE 12: A Credential for a Bitstring Status List

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2"
  ],
  "id": "https://university.example/CredentialStatusList",
  "type": ["VerifiableCredential", "BitstringStatusListCredential"],
  "issuer": "did:example:2g55q912ec3476eba2l9812ecbfe"",
  "validFrom": "2005-01-01T00:00:00",
  "credentialSubject": {
    "id": "https://university.example/statuslist#list",
    "type": "BitstringStatusList",
    "statusPurpose": "revocation",
    "encodedList": "uH4sIAAAAAAAAA-3BMQEAAADCoPVPbQwfoAAAAAAAAAAAAAAAAAAAAIC3AYbSVKsAQAAA"
  } 

}

The core property in this case is encodedList, which is a base64url encoded version of the GZIP compressed bitstring status list.

このケースで重要なプロパティはencodedListで、GZIP圧縮ビット文字列ステータスリストのbase64urlエンコード版です。

まぁ、この辺りを含め以前書いたポストでカバー済みなので省略します。

一応これで本編は終わりです。

追加リソース部分は解説するかもしれませんししないかもしれません。 

 

 

 

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をした場合のステータスをどうやって表すのかという話ですね。

ではまた次回。

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を見ていきます。

前回は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を作成する、という流れということです。続いて各ステップについて解説がされています。

1. 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.
2. 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.
3. 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.

1. 変換とは、入力データを受け取り、ハッシュ化処理の準備をする変換アルゴリズムによって記述されるプロセスです。JSONでシリアライズされたデータの場合、変換には、スペース、改行、JSON名の順序など、データの意味に影響を与えないアーティファクトの除去が含まれます（正規化と呼ばれるステップ）。場合によっては、変換はより複雑になることがあります。
2. ハッシュ化は、暗号ハッシュ関数を使用して変換されたデータの識別子を計算するハッシュアルゴリズムによって記述されるプロセスです。通常、生成されたハッシュのサイズはデータよりも小さいため、デジタル署名のような複雑な暗号機能に適しています。
3. 証明生成とは、証明方法によって記述されるプロセスであり、入力データの整合性を改ざんから保護する値、または特定の信頼性基準を満たすことを証明する値を計算します。典型的な例として、非対称鍵を使用した暗号署名アプリケーションがあり、これによりデータの署名が生成されます。

この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）の状態です。

EXAMPLE 8: Skeleton of a 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",
    …
    // All the details about the proof
    …
    "proofValue": "zQeVb…Wx"
  }
}

Note the proofValue property, whose object is the result of the proof generation process.

proofValue プロパティに注目してください。このプロパティのオブジェクトは、証明生成プロセスの結果です。 

NOTE

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からは次回に送りたいと思います。

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です。

1. Enveloping Proofs

Enveloping proofs of Credentials, defined by this Working Group, are based on JSON Object Signing and Encryption (JOSE), CBOR Object Signing and Encryption (COSE) [RFC9052], or Selective Disclosure for JWTs [SD-JWT]. These are all IETF specifications, or groups of specification like JOSE that refers to JWT [RFC7519], JWS [RFC7515], or JWK [RFC7517]). The Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE] recommendation defines a "bridge" between these and the Verifiable Credentials Data Model v2.0, specifying the suitable header claims, media types, etc.

In the case of JOSE, the Credential is the "payload" (to use the IETF terminology). This is preceded by a suitable header whose details are specified by Securing Verifiable Credentials using JOSE and COSE for the usage of JWT. These are encoded, concatenated, and signed, to be transferred in a compact form by one entity to an other (e.g., sent by the holder to the verifier). All the intricate details on signatures, encryption keys, etc., are defined by the IETF specifications; see Example 6 for a specific case.

このワーキンググループが定義する資格証明書の包括的な証明は、JSON Object Signing and Encryption (JOSE)、CBOR Object Signing and Encryption (COSE) [RFC9052]、または Selective Disclosure for JWTs [SD-JWT]に基づいています。これらはすべて IETF 仕様、または JOSE のような仕様グループ（JWT [RFC7519]、JWS [RFC7515]、または JWK [RFC7517] を参照）です。Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE] 勧告は、これらの仕様と Verifiable Credentials Data Model v2.0 間の「ブリッジ」を定義し、適切なヘッダークレームやメディアタイプなどを指定しています。

JOSE の場合、クレデンシャルは「ペイロード」（IETF の用語を使用）です。これは、JWT の使用方法として JOSE および COSE を使用した検証可能なクレデンシャルの保護で詳細が規定されている適切なヘッダーに先行します。これらはエンコードされ、連結され、署名され、1 つのエンティティから別のエンティティにコンパクトな形式で転送されます（例えば、保有者から検証者に送信されます）。署名や暗号化キーなどに関する複雑な詳細はすべて、IETF 仕様で定義されています。具体的な例については、例 6 を参照してください。 

以前も書きましたがエンベロープ証明はJOSE/COSE/SD-JWTのデジタル署名ですので、特にJOSEについてはOpenID Connectにおけるid_tokenと共通する点も多く、以前からOpenID Connectをやっている人にはとっつき易いと思います。

COSEですか？個人的にバイナリは好きですが万人受け（特に最近は）はしないでしょう。ただFIDO関連やmDLな人は通らないとダメな道だと思います。頑張りましょう。

The usage of COSE [RFC9052] is similar to JOSE, except that all structures are represented in CBOR [RFC8949]. From the Credentials point of view, however, the structure is similar insofar as the Credential (or the Presentation) is again the payload for COSE. The usage of CBOR means that the final representation of the Verifiable Credential (or Presentation) has a significantly reduced footprint which can be, for example, shown in a QR Code.

The [SD-JWT] is a variant of JOSE, which allows for the selective disclosure of individual claims. Claims can be selectively hidden or revealed to the verifier, but nevertheless all claims are cryptographically protected against modification. This approach is obviously more complicated than the JOSE case but, from the Credentials point of view, the structure is again similar. The original Credential is the payload for SD-JWT; and it is the holder's responsibility to use the SD-JWT when presenting the Credential to a verifier using selective disclosure.

COSE [RFC9052] の使用法は JOSE と似ていますが、すべての構造が CBOR [RFC8949] で表現されている点が異なります。しかし、クレデンシャルという観点から見ると、クレデンシャル（またはプレゼンテーション）が COSE のペイロードであるという点では、構造は似ています。CBORの使用により、検証可能なクレデンシャル（またはプレゼンテーション）の最終的な表現は、例えばQRコードで表示できるほど、フットプリントが大幅に削減されます。

[SD-JWT] は JOSE のバリエーションであり、個々のクレームの選択的な開示を可能にします。 検証者に対して、クレームを選択的に非表示または表示することができますが、それにもかかわらず、すべてのクレームは暗号技術によって改ざん防止が保護されています。 このアプローチは JOSE の場合よりも明らかに複雑ですが、クレデンシャルという観点から見ると、構造は再び似ています。SD-JWTのペイロードがオリジナルクレデンシャルであり、選択的開示を使用して検証者にクレデンシャルを提示する際にSD-JWTを使用するのは、所有者の責任です。

はい、CBORを使うメリットはやはりサイズの問題でしょうね。ただ結局はOpenID for Verifiable Credential Issuanceのcredential_offer_uriの様に、間接的にクレデンシャル発行を行う場合ばかりだと思いますので、Wallet to Walletの様なシナリオ以外ではあまり出番はないのかもしれません。

4.1.1 Example: the Core Example Secured with JOSE

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

例 1 の「Credential」の例は、例 3 の JSON スキーマへの参照により強化されており、以下のとおり、エンベロープ証明により保護することができます。

EXAMPLE 6: A Simple Credential in JWT (unencoded)

// Header
{
  "iss": "did:example:2g55q912ec3476eba2l9812ecbfe",
  "alg": "HS256",
  "cty": "vc+ld+json",
  "typ": "vc+ld+json+jwt"
}

---

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

} 

まぁ、ここはサンプルですが、ヘッダに記載の方式でデジタル署名が打たれる、ということを覚えておけば良いと思います。

As a next step, the header and the payload is encoded, concatenated, and then signed using the methods defined by JWS [RFC7515]. The encoded and signed Credential could look like (using the string "VC Overview" as the signature's secret):

次のステップとして、ヘッダーとペイロードは、JWS [RFC7515] で定義された方法を使用して、エンコード、連結、そして署名されます。 エンコードおよび署名されたクレデンシャルは、次のようになります（署名用の秘密鍵として「VC Overview」という文字列を使用）。

ここもJWSの話ですね。慣れ親しんだ方法です。

EXAMPLE 7: A Simple Credential Enveloped using JOSE

eyJpc3MiOiJkaWQ6ZXhhbXBsZToyZzU1cTkxMmVjMzQ3NmViYTJsOTgxMmVjYmZlIiwiYWxnIjoiSFMyNTYiLCJjdHkiOiJ2YytsZCtqc29uIiwidHlwIjoidmMrbGQranNvbitqd3QifQ.eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy5leGFtcGxlLm9yZy92b2NhYnMvYWx1bW5pIl0sImlkIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvQ3JlZGVudGlhbDEyMyIsInR5cGUiOlsiVmVyaWZpYWJsZUNyZWRlbnRpYWwiLCJFeGFtcGxlQWx1bW5pQ3JlZGVudGlhbCJdLCJpc3N1ZXIiOiJkaWQ6ZXhhbXBsZToyZzU1cTkxMmVjMzQ3NmViYTJsOTgxMmVjYmZlIiwidmFsaWRGcm9tIjoiMjAxMC0wMS0wMVQwMDowMDowMFoiLCJjcmVkZW50aWFsU3ViamVjdCI6eyJpZCI6Imh0dHBzOi8vd3d3LmV4YW1wbGUub3JnL3BlcnNvbnMvcGF0IiwibmFtZSI6IlBhdCIsImFsdW1uaU9mIjp7ImlkIjoiZGlkOmV4YW1wbGU6YzI3NmUxMmVjMjFlYmZlYjFmNzEyZWJjNmYxIiwibmFtZSI6IkV4YW1wbGUgVW5pdmVyc2l0eSJ9fSwiY3JlZGVudGlhbFNjaGVtYSI6eyJpZCI6Imh0dHBzOi8vdW5pdmVyc2l0eS5leGFtcGxlL0NyZWRlbnRpYWwxMjMtc2NoZW1hLWNyZWRlbnRpYWwiLCJ0eXBlIjoiSnNvblNjaGVtYUNyZWRlbnRpYWwifX0.Ic1SxIMuwAuTHVQ_2i3wzLvRTSP9EwIS6_G_nEAueVg

これがサンプルですが、みんな大好きeyJですね。

次回はEmbedded Proof（VC Data Integrity）を見ていきます。

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

今回は3つ目のVerifiable Credentials Data Modelの続きのJSONスキーマの部分です。

3. Checking Structure with JSON Schemas

A significant part of the integrity of a Verifiable Credential comes from the ability to structure its contents so that all three parties — issuer, holder, verifier — may have a consistent mechanism of trust in interpreting the data that they are provided with. One way of doing that is to use [JSON-SCHEMA] to check the structural validity of the Credential. The Verifiable Credentials JSON Schema Specification [VC-JSON-SCHEMA] specification adds standard properties to express the association of a Credential with a JSON Schema.

検証可能なクレデンシャルの整合性の重要な部分は、発行者、保有者、検証者の3者すべてが、提供されたデータを解釈する際に一貫性のある信頼メカニズムを持つことができるように、その内容を構造化できる能力から生じます。その方法のひとつとして、[JSON-SCHEMA]を使用してクレデンシャルの構造的妥当性を確認する方法があります。検証可能な資格情報 JSON スキーマ仕様 [VC-JSON-SCHEMA] 仕様では、資格情報と JSON スキーマとの関連性を表現するための標準プロパティが追加されています。

はい、その通りです。

クレデンシャル（コンテナ）のフォーマットや署名形式、トランスポートプロトコルが一致していたとしてもやり取りされるデータの構造が合っていないと少なくとも機械的に処理ができません。もう一つ言うならデータの意味も、ですね。この辺りを踏まえてスキーマと言うべきでしょう。（現実世界では単なるデータ構造だけを指していて、意味の解釈についてはあまり踏み込めていないところもあり、ここは今後の課題となるでしょう）

例を挙げて考えてみています。

EXAMPLE 3: A Simple Credential with a JSON Schema

{
  "@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/Credential-schema.json",
    "type": "JsonSchema"
  }
}

When dereferenced, the URL https://university.example/Credential-schema.json should return a JSON Schema, for example:

URL https://university.example/Credential-schema.jsonが参照解除されると、JSONスキーマを返す必要があります。例えば、

EXAMPLE 4: JSON Schema for the Simple Credential

{
  "$id": "https://example.com/schemas/email.json",
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "ExampleAlumniCredential",
  "description": "Alumni Credential using JsonSchema",
  "type": "object",
  "properties": {
    "credentialSubject": {
      "type": "object",
      "properties": {
        "alumniOf": {
          "type": "string",
          "format": "url"
        }
      },
      "required": [
        "alumniOf"
      ]
    }
  }
}

Using this JSON Schema, a verifier can check whether the Credential is structurally valid or not.

この JSON スキーマを使用することで、検証者はクレデンシャルが構造的に有効であるか否かを確認することができます。

こんな形でスキーマ定義を用いてデータ構造が望んだ通りになっているかどうかを確認することができるってわけですね。

 

For security reasons one may want to go a step further: check/verify the JSON Schema itself to see if, for example, it has been tempered with. This can be done by referring to the JSON Schema indirectly through a separate Verifiable Credential. The reference to such a Verifiable Credential looks very much like Example 3 except for the value of the type:

セキュリティ上の理由から、さらに一歩踏み込んで、JSON スキーマ自体が改ざんされていないかどうかを確認/検証したい場合もあるでしょう。これは、別の検証可能なクレデンシャルを介して間接的に JSON スキーマを参照することで行うことができます。このような検証可能なクレデンシャルへの参照は、type の値を除いて、例 3 とほとんど同じです。 

EXAMPLE 5: A Simple Credential with a JSON Schema 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/Credential-schema-credential",
    "type": "JsonSchemaCredential"
  }
}

タイプ属性を使って間接的に他のスキーマ定義を読み込んで検証することもできます。まぁ、この辺りはVerifiable CredentialsというよりもJSON-LDの話ですね。

In this case, when dereferenced, the URL https://university.example/Credential123-schema-credential should return a Verifiable Credential, whose credentialSubject property refers to the required JSON Schema (i.e., https://university.example/Credential-schema.json). See the example in the Verifiable Credentials JSON Schema Specification specification for an example and for further details.

この場合、URL https://university.example/Credential123-schema-credential を参照解除すると、Verifiable Credential が返され、その credentialSubject プロパティが要求される JSON スキーマ（すなわち、https://university.example/Credential-schema.json）を参照します。例と詳細については、Verifiable Credentials JSON Schema Specification 仕様書の例を参照してください。 

まぁ、こんな感じでスキーマの制限を入れるって言うのも相互運用性を保つためには重要なことですね。

次回はSecuring Mechanismについて読んでいきたいと思います。 

 

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

今回は3つ目のVerifiable Credentials Data Modelの続きのシリアライズの部分です。

2. Serialization in JSON

In the [VC-DATA-MODEL-2.0] specification, as in the other documents, Verifiable Credentials and Presentations are mostly expressed in JSON [RFC7519], more specifically [JSON-LD11]. In this serialization, properties of claims are represented as JSON names, and values as JSON literals or objects. Subjects of claims are either explicitly identified by an id property, or implicitly by appearing as an object of another claim. 

Standard properties defined by the [VC-DATA-MODEL-2.0] form a distinct set of JSON names, referred to as a (standard) vocabulary. An important characteristics of Verifiable Credentials in JSON-LD is that it favors a decentralized and permissionless approach to extend to a new application area through application-specific set of properties, i.e., vocabularies, distributed on the Web. Anyone can "publish" such a vocabulary, following some rules described in the extensibility section of the specification.

[VC-DATA-MODEL-2.0]仕様では、他の文書と同様に、検証可能な資格情報とプレゼンテーションは、主にJSON [RFC7519]、より具体的には[JSON-LD11]で表現されます。このシリアライズでは、クレームのプロパティはJSON名として、値はJSONリテラルまたはオブジェクトとして表現されます。クレームのサブジェクトは、idプロパティで明示的に識別されるか、別のクレームのオブジェクトとして表示されることで暗黙的に識別されます。

[VC-DATA-MODEL-2.0]で定義された標準プロパティは、JSON名として一意のセットを形成し、（標準）語彙と呼ばれます。JSON-LDにおける検証可能なクレデンシャルの重要な特性は、分散型で許可不要のアプローチを推奨し、Web上に分散されたアプリケーション固有のプロパティセット、すなわち語彙を通じて、新しいアプリケーション領域への拡張を可能にすることです。仕様書の拡張性セクションに記載されているいくつかのルールに従うことで、誰もがこのような語彙を「公開」することができます。

重要な点はW3C Verifiable Credentials Data Model 2.0においてはVerifiable CredentialsやVerifiable PresentationはJSON-LDによって表現される、ということですね。VCDM1.1まではJSONシリアライゼーションについても許容していましたが、SD-JWT-VCがIETFで策定が進められることになったことを受けW3C側ではJSON-LD+Data Integrity Proofに振り切った、ということですね。標準が割れるのはうーん、、ですね。今後どうやって棲み分けていくのかは要注目です。

The following JSON-LD code is an example for a simple Credential. It states that the person named "Pat", identified by https://www.exampl.org/persons/pat, is an alumni of the Example University (identified by did:example:c276e12ec21ebfeb1f712ebc6f1). The Credential is valid from the 1st of January 2010, and is issued by an entity identified by did:example:2g55q912ec3476eba2l9812ecbfe. Most of the properties in the Credential are from the standard Verifiable Credentials vocabulary, but some terms (like alumniOf, AlumniCredential) are added by the application-specific vocabulary referred to by https://www.example.org/vocabs/alumni.

以下の JSON-LD コードは、シンプルなクレデンシャルの例です。https://www.exampl.org/persons/pat で識別される「Pat」という人物が、Example University の卒業生（did:example:c276e12ec21ebfeb1f712ebc6f1 で識別）であることを示しています。この資格情報は2010年1月1日より有効であり、did:example:2g55q912ec3476eba2l9812ecbfeで識別されるエンティティによって発行されたものである。クレデンシャルのプロパティのほとんどは、標準の検証可能なクレデンシャル用語集に由来しますが、一部の用語（alumniOf、AlumniCredentialなど）は、https://www.example.org/vocabs/alumniで参照されているアプリケーション固有の用語集に追加されています。

EXAMPLE 1: A Simple 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"
    }
  }
}

Figure 6 shows the same Credential, but represented as a graph of claims, as described in 3.1.1 Claims, Properties.

図6は、3.1.1節「クレーム、プロパティ」で説明されているように、同じクレデンシャルをクレームのグラフとして表したものです。

図6. Credential in Example 1 represented as a collection of claims.

 

Note

The Credential in Example 1 is used throughout this document to show how to apply additional features defined by the various specifications.

例 1 の「Credential」は、この文書全体を通して、さまざまな仕様で定義された追加機能の使用方法を示すために使用されています。

The Credential in Example 1, issued by Example University, is stored by a holder (who may be a person, a digital wallet, or any other entity). On request, the holder may "present" a Credential to a verifier, encapsulated in a Verifiable Presentation. This is how the result may look like in the JSON-LD serialization:

例 1 のクレデンシャルは、例大学が発行したもので、保有者（人、デジタルウォレット、またはその他のエンティティ）によって保管されます。要求に応じて、保有者は検証者に「提示」することができます。これは、検証可能なプレゼンテーションにカプセル化されています。JSON-LD シリアライズでは、結果は次のようになります。

EXAMPLE 2: Presenting the Credential

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.example.org/vocabs/alumni"
  ],
  "type": "VerifiablePresentation",
  "id": "urn:uuid:313801ba-24b7-11ee-be02-ff560265cf9b",
  "holder": "did:example:12345678",
  "validUntil": "2020-12-31T00:00:00Z"
  "verifiableCredential": {
    "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"
      }
    }
  }

}

 

Note that the holder could have presented several Credentials within the same presentation or create a new Credential by either combining it with others, or removing some claims as irrelevant for the specific context.

保有者は、同じプレゼンテーションの中で複数のクレデンシャルを提出することも、他のクレデンシャルと組み合わせたり、特定の状況では無関係なクレームを削除したりして、新しいクレデンシャルを作成することもできることに留意してください。 

後半はコードサンプルですね。

次回は3.3. Checking Structure with JSON Schemasをみていこうと思います。 

 

 

 

 

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

今回は3つ目のVerifiable Credentials Data Modelです。

ちょっと長いので分割したいと思います。今回は3.1のBasic Structureに関してです。

1. Basic Structure

1-1. Claims, Properties

A core concept is "claims": statements made about various entities, referred to as "subjects". Subjects may be a holder, an issuer, or a verifier as listed above, but may also any be another person (e.g., the person holding a university degree), an animal, an abstract concept, etc. Claims may also be on a Credential itself, such as issuance date, validity periods, etc. (Such claims are also loosely referred to as "credential metadata".)

Claims are expressed using "properties" referring to "values". Values may be literals, but may also be other entities referred to, usually, by a [URL]. It that case, the entity may become the subject of another claim; these claims, together, form a "graph" of claims that represents a Credential. (See Figure 6 for an example of such a graph, represented graphically. For more complex examples, refer to the Verifiable Credentials Data Model v2.0 specification itself.)

中心となる概念は「クレーム」です。これは、さまざまなエンティティ（「サブジェクト」と呼ばれます）について述べられた文です。サブジェクトは、上記の保有者、発行者、検証者のいずれの場合もありますが、それ以外の者（例えば、大学の学位を持つ者）、動物、抽象的な概念などである場合もあります。また、クレームは、発行日や有効期間など、クレデンシャル自体に関するものでもあります（このようなクレームは、大まかに「クレデンシャルメタデータ」とも呼ばれます）。

「クレデンシャルメタデータ」とも呼ばれる。クレデンシャルメタデータは、通常、[URL]で参照される他のエンティティを指すこともある。その場合、そのエンティティは別のクレデンシャルの主題となり得る。これらのクレデンシャルメタデータは、クレデンシャルを表す「グラフ」を形成する。このようなグラフの例については、図6を参照のこと。より複雑な例については、Verifiable Credentials Data Model v2.0 仕様書を参照してください。

図3. The basic structure of a claim with (in this case) a literal value.

この「クレーム」という考え方の理解は非常に重要です。属性（Attribute）からクレーム（Claim）へのパラダイムシフトについてはKim Cameronの最後のスピーチでも語られた通りです。（日本語訳はこちら）
該当部分を引用しておきます。

私は、属性からクレームへとパラダイムを変更する必要があると話し合った日のことを覚えています。属性とは、単一企業の閉じた世界での特性を表す言葉でしたが、世界を開いてドメイン間を行き来するようになると、そのことに気付きます。それは単に属性の問題ではなく、誰が誰について何を言っているかという問題です。属性はある存在によって語られ、その存在を実際に信じるかどうかを判断しなければなりません。つまり、クレームという概念が生まれたのです。クレームとは、疑わしい属性のことであり、どのような目的のために何を信用するかを決めるための技術が必要なのです。

つまり、サブジェクトやクレデンシャルに関する情報で検証されるべきものなんですよね。そう言う意味でが元々Verifiable Credentialsが「Verifiable Claims」という名称で仕様の検証が行われていた時代の方が伝わりやすかったのでは？と個人的には思ったりします。

The Verifiable Credentials Data Model v2.0 document specifies a number of standard properties. These include, for example, credentialSubject, type, issuer, or validFrom. Developers may define their own properties to express specific types of Credentials, like a driving license, a university degree, or a marriage certificate.

Verifiable Credentials Data Model v2.0文書では、多くの標準プロパティが指定されています。 例えば、credentialSubject、type、issuer、validFromなどが挙げられます。開発者は、運転免許証、学位、結婚証明書など、特定の種類のクレデンシャルを表現するために独自のプロパティを定義することができます。

そのようなサブジェクトとクレームの関係性をプロパティとして表現しているわけですが、VCDM2.0では標準のプロパティを多く定義していますし、独自でクレデンシャルを定義する際には必要なプロパティを定義することができるわけです。

1-2. Verifiable Credentials

A Credential is a set of one or more claims made by the same entity. Credentials might also include an identifier and metadata to describe properties of the Credential, such as a reference to the issuer, the validity date, a representative image, the revocation mechanism, and so on. A Verifiable Credential is a set of claims and metadata that also includes verification mechanisms that cryptographically prove who issued it, ensures that the data has not been tampered with, etc.

For a more detailed description of abstract Verifiable Credentials, with examples, see the relevant section in the data model specification.

クレデンシャルとは、同一のエンティティによってなされた1つ以上のクレームのセットです。クレデンシャルには、発行者、有効期限、代表画像、取り消しメカニズムなど、クレデンシャルの特性を記述する識別子やメタデータも含まれる場合があります。検証可能なクレデンシャルとは、誰が発行したかを暗号技術によって証明し、データが改ざんされていないことを保証する検証メカニズムも含む、一連のクレームとメタデータのセットです。

抽象的な検証可能なクレデンシャルの詳細については、データモデル仕様書の該当セクションを参照してください。

図4. Basic components of a Verifiable Credential.

ここではVerifiable Credentialsの構造について語られています。すでにこれまでも語られてきたことばかりではありますが、Verifiable Credentialsにはメタデータ、クレーム、証明（これはIntroductionでも触れた通りJWSだったりData Integrity Proofの場合もあります）で構成されています。

1-3. Verifiable Presentations

Enhancing privacy is a key design feature of Verifiable Credentials. Therefore, it is important, for entities using this technology, to be able to express only the portions of their persona that are appropriate for a given situation. The expression of a subset of one's persona is called a Verifiable Presentation. Examples of different personas include a person's professional persona, their online gaming persona, their family persona, or an incognito persona.

A Verifiable Presentation is created by a holder, can express data stemming from multiple Verifiable Credentials, and can contain additional metadata in forms of additional claims. They are used to present claims to a verifier. It is also possible to present Verifiable Credential directly.

A Verifiable Presentation is usually short-lived, it is not meant to be stored for a longer period.

For a more detailed description of abstract Verifiable Presentations, with examples, see the relevant section in the data model specification. 

プライバシー保護の強化は、検証可能なクレデンシャルの重要な設計上の特徴です。したがって、この技術を使用する主体にとって、特定の状況に適した人格の一部分のみを表現できることが重要です。人格の一部分のみを表現することを検証可能なプレゼンテーションと呼びます。異なる人格の例としては、職業上の人格、オンラインゲーム上の人格、家族としての人格、匿名人格などがあります。

検証可能なプレゼンテーションは保有者によって作成され、複数の検証可能なクレデンシャルに由来するデータを表現し、追加のクレームという形で追加のメタデータを含めることができます。これらは検証者にクレームを提示するために使用されます。また、検証可能なクレデンシャルを直接提示することも可能です。

検証可能なプレゼンテーションは通常、短期間しか有効ではなく、長期間保存されるものではありません。

抽象的な検証可能なプレゼンテーションの詳細については、例を交えてデータモデル仕様の該当セクションを参照してください。

図5. Basic components of a verifiable presentation.

ここれはVerifiable Presentationについて語られています。ポイントは選択的開示などプライバシーに配慮するためにはVerifiable Credentialsを「そのまま」Verifierに渡すのではなく、Verifiable Presentationという形でHolderによって表明されることが重要、ということです。

次回はシリアライズの部分についてみていこうと思います。

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

今回は2つ目のEcosystem Overviewです。今回も和訳はDeepLです。

最初にいつもの3パーティモデルの説明です。

The Verifiable Credential specifications rely on an ecosystem consisting of entities playing different "roles". The main roles are:

Issuer

An entity that creates a Credential, consisting of a series of statements related to the subject of a Verifiable Credential. An example is a university that issues credentials for university degrees or certificates for alumni.

Holder

An entity that possesses one or more Credentials, and that can transmit presentations of those Verifiable Credentials to third parties. An example may be the person who "holds" his/her own educational degrees. Another example may be a digital wallet that contains several Credentials on someone's behalf.

Verifier

An entity that performs verification on a Verifiable Credential to check the validity, consistency, etc., of a Credential. An example may be an employer's digital system that checks the validity of a university degree before deciding on the employment of a person.

For a more precise definition of these roles, as well as other roles, see the relevant section in the data model specification.

検証可能な資格情報の仕様は、異なる「役割」を担う複数の主体からなるエコシステムに依存しています。主な役割は以下のとおりです。

発行者

検証可能な資格証明書の対象に関する一連のステートメントで構成される資格証明書を作成する主体。例えば、大学の学位や卒業生向けの修了証書を発行する大学などが挙げられます。

保有者

1つ以上のクレデンシャルを所有し、その検証可能なクレデンシャルの提示を第三者に送信できる主体。例えば、自身の学歴を「保持」する人などが挙げられます。また、デジタルウォレットに複数のクレデンシャルを保管し、本人を代理するケースも考えられます。

検証者

検証可能なクレデンシャルについて、その有効性、一貫性などを確認する検証を行う主体。例えば、雇用者がデジタルシステムを使用して、大学学位の有効性を確認してから採用を決定する場合などが挙げられる。

これらの役割、およびその他の役割のより正確な定義については、データモデル仕様の該当セクションを参照してください。

図2. The roles and information flows forming the basis for the VC Data Model.

今回はシンプルですね。単純にVCを発行する「Issuer（発行者）」と、発行されたVCを保有する「Holder（保有者）」、Holderから提示を受けたVCを検証する「Verifier（検証者）」の3つが主たる登場人物である、という話です。

もちろん実装する上では、VCの検証を行うために必要な公開鍵をどうやって共有するか（DIDにおけるVerifiable Data Registryなど）、各登場人物の間でVCをやり取りするプロトコルをどうするか、クレデンシャルのフォーマットや完全性を証明する方式をどうするか、などの付帯要素がたくさん存在するわけですが。

次回はVerifiable Credentials Data Modelの話です。

W3C Verifiable Credentials Overviewを読む（２）

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

引き続きW3C Verifiable Credentials Overviewを見ていきます。

https://www.w3.org/TR/2024/NOTE-vc-overview-20240613/

前回触れた通り、以下の目次構成となっているドキュメントです。

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

今回はIntroductionを見ていきます。

まずは本文書の目的から。詳細ではなく概念を把握してもらうことが主目的です。

（なお、全体を通じて日本語訳はDeepLを使った機械翻訳です）

This document provides a non-normative, high-level overview for W3C's Verifiable Credential specifications and serves as a roadmap for the documents that define, describe, and secure these credentials. It is not the goal of this document to be very precise, nor does this overview cover all the details. The intention is to provide users, implementers, or anyone interested in the subject, a general understanding of the concepts and how the various documents, published by the Verifiable Credentials Working Group, fit together.

この文書は、W3Cの検証可能な資格証明書の仕様に関する非規範的な概要を提示し、これらの資格証明書を定義、説明、保護する文書のロードマップとしての役割を果たします。この文書は、非常に正確であることを目指しているわけではなく、またこの概要はすべての詳細を網羅しているわけでもありません。このドキュメントの目的は、ユーザー、実装者、またはこのテーマに関心のある人々に、概念の一般的な理解と、検証可能な資格情報ワーキンググループが発行するさまざまなドキュメントがどのように関連しているかを理解してもらうことです。 

1.1 High Level View of the Specifications

Figure 1 provides an overview of the main building blocks for Verifiable Credentials, including their (normative) dependencies. For more details, see the subsequent sections in this document.

図 1 は、検証可能な資格情報の主な構成要素の概要を示しており、それらの（規範的な）依存関係も含まれています。 詳細については、このドキュメントの以降のセクションを参照してください。

先に図1を貼っておきます。Verifiable Credential Data Modelばかりに目が行きますが様々な関連スペックから構成されていることがわかります。

図１ Verifiable Credentials Working Group Recommendations

 

The Verifiable Credentials Data Model v2.0 [VC-DATA-MODEL-2.0] specification, which defines the core concepts that all other specifications depend on, plays a central role. The model is defined in abstract terms, and applications express their specific credentials using a serialization of the data model. The current specifications mostly use a JSON serialization; the community may develop other serializations in the future. 

他のすべての仕様が依存するコア概念を定義する Verifiable Credentials Data Model v2.0 [VC-DATA-MODEL-2.0] 仕様が、中心的な役割を果たします。このモデルは抽象的な用語で定義され、アプリケーションはデータモデルのシリアライズを使用して固有のクレデンシャルを表現します。現在の仕様では、主に JSON シリアライズが使用されていますが、将来的にコミュニティが他のシリアライズを開発する可能性もあります。 

シリアライズ周りはVCDM2.0で明確に変化した部分ですね。

ここからは各構成要素の役割を紹介しています。

まずはVC-JSON-SCHEMAはクレデンシャルの解釈を行うためのスキーマを定義しています。

When Verifiable Credentials are serialized in JSON, it is important to trust that the structure of a Credential may be interpreted in a consistent manner by all participants in the verifiable credential ecosystem. The Verifiable Credentials JSON Schema Specification [VC-JSON-SCHEMA] defines how [JSON-SCHEMA] can be used for that purpose.

検証可能なクレデンシャルを JSON でシリアライズする場合、検証可能なクレデンシャルエコシステムに参加するすべての関係者が、クレデンシャルの構造を一貫性のある方法で解釈できると信頼することが重要です。検証可能なクレデンシャルの JSON スキーマ仕様書 [VC-JSON-SCHEMA] では、[JSON-SCHEMA] をその目的で使用する方法を定義しています。

クレデンシャルを保護するメカニズムについて触れていきます。

Credentials can be secured using two different mechanisms: enveloping proofs or embedded proofs. In both cases, a proof cryptographically secures a Credential (for example, using digital signatures). In the enveloping case, the proof wraps around the Credential, whereas embedded proofs are included in the serialization, alongside the Credential itself.

クレデンシャルは、2つの異なるメカニズム（エンベロープ型証明または埋め込み型証明）を使用して保護することができます。いずれの場合も、証明は暗号技術を使用してクレデンシャルを保護します（例えば、デジタル署名を使用）。エンベロープ型の場合、証明はクレデンシャルを包み込みますが、埋め込み型の場合は、クレデンシャル自体とともにシリアル化に含まれます。 

エンベロープ型、いわゆるJWSは全体を署名してしまう方式です。 

A family of enveloping proofs is defined in the Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE] document, relying on technologies defined by the IETF. Other types of enveloping proofs may be specified by the community.

JOSE および COSE を使用した検証可能なクレデンシャルの保護 [VC-JOSE-COSE] 文書では、IETF が定義した技術に依存する、エンベロープ型証明の一連が定義されています。その他のエンベロープ型証明は、コミュニティによって指定される場合があります。

埋め込み型はVC Data Integrityの話ですね。 

The general structure for embedded proofs is defined in a separate Verifiable Credential Data Integrity 1.0 [VC-DATA-INTEGRITY] specification. Furthermore, the Working Group also specifies some instances of this general structure in the form of the "cryptosuites": Data Integrity EdDSA Cryptosuites v1.0 [VC-DI-EDDSA], Data Integrity ECDSA Cryptosuites v1.0 [VC-DI-ECDSA], and Data Integrity BBS Cryptosuites v1.0 [VC-DI-BBS]. Other cryptosuites may be specified by the community.

埋め込み証明書の一般的な構造は、別個の検証可能なクレデンシャルデータ完全性 1.0 [VC-DATA-INTEGRITY] 仕様で定義されています。さらに、ワーキンググループは、この一般的な構造を「暗号スイート」の形でいくつか規定しています。データ完全性 EdDSA 暗号スイート v1.0 [VC-DI-EDDSA]、データ完全性 ECDSA 暗号スイート v1.0 [VC-DI-ECDSA]、データ完全性 BBS 暗号スイート v1.0 [VC-DI-BBS]。コミュニティによって他の暗号スイートが指定される場合もあります。 

そして発行済みクレデンシャルのステータス（取り消し状態）を管理するためのBitString Status Listです。以前StatusList2021とか言っていたものですね。（過去の記事）

相変わらずBitStringです。。。

The Bitstring Status List v1.0 [VC-BITSTRING-STATUS-LIST] specification defines a privacy-preserving, space-efficient, and high-performance mechanism for publishing status information, such as suspension or revocation of Verifiable Credentials, through the use of bitstrings. 

Bitstring Status List v1.0 [VC-BITSTRING-STATUS-LIST] 仕様は、検証可能なクレデンシャルの一時停止や取り消しなどのステータス情報を、ビットストリングを使用して公開するための、プライバシー保護、省スペース、高性能なメカニズムを定義しています。

 そして最後はコントローラードキュメントです。DIDにおけるDID Documentなどクレデンシャルを検証するための方法などについて書かれているものです。

Finally, the Controller Documents 1.0 [CONTROLLER-DOCUMENT] specification defines some common terms (e.g., verification relationships and methods) that are used not only by other Verifiable Credential specifications, but also other Recommendations such as Decentralized Identifiers (DIDs) v1.0 [DID-CORE].

最後に、Controller Documents 1.0 [CONTROLLER-DOCUMENT] 仕様では、他の検証可能な資格情報仕様だけでなく、分散型識別子 (DID) v1.0 [DID-CORE] などの他の勧告でも使用されるいくつかの共通用語（検証関係や方法など）を定義しています。 

とりあえずはIntrodutionなので全体の概要が語られましたが、実際問題この関係性についてはちゃんと理解しておかないと後からついていけなくなるので非常に大切なパートでした。

次回はEcosystem Overviewを見ていきます。

W3C Verifiable Credentials Overviewを読む（１）

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

W3CのVerifiable Credentials Working GroupからVerifiable Credentialsの全体像に関する技術報告書（Group Note）がリリースされているのでみていきたいと思います。Verifiable Credentials Data Mode（VCDM）2.0の標準化に向けての取り組みの一環ですね。

Verifiable Credentials Overview

https://www.w3.org/TR/2024/NOTE-vc-overview-20240613/

なお、Group NoteはW3Cの定義を見ると、以下のように位置付けられる文書とのことです。

A W3C Group Note is a document produced by a W3C Working Group, a W3C Interest Group, the Advisory Board (AB), or the W3C Technical Architecture Group (TAG). A W3C Group Note is a W3C Technical Report.

A Group Note is to provide a stable reference for a document that is not intended to be a formal standard. These notes have not received formal review and are not endorsed W3C.

These notes MUST NOT be cited as W3C standards and may or may not become W3C Statements.

Software MAY implement these reports at their own risk. Implementation is neither discouraged nor encouraged but can contribute to proposals for further action on a specification.

There are no patent protection covering the implementations of the Group Note.

W3C Group Note は、W3C ワーキンググループ、W3C 関心グループ、諮問委員会（AB）、W3C 技術アーキテクチャグループ（TAG）によって作成される文書です。W3C Group Note は、W3C 技術報告書です。

グループノートは、正式な標準規格となることを意図していない文書の安定した参照先を提供することを目的としています。これらのノートは正式なレビューを受けておらず、W3Cの承認も受けていません。

これらのノートは、W3C標準として引用してはならず、W3Cステートメントとなる場合もあれば、ならない場合もあります。

ソフトウェアは、自己責任においてこれらのレポートを実装してもよい。実装は推奨されるものではないが、仕様に関する今後の取り組みの提案に貢献できる可能性がある。

グループノートの実装には特許による保護はありません。 

（DeepLによる機械翻訳）

文書の構成はこのようになっています。

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

今回は前段となるAbstactだけを。

Credentials are a part of our daily lives; driver's licenses are used to assert that we are capable of operating a motor vehicle, university degrees can be used to assert our level of education, and government-issued passports enable us to travel between countries. The family of W3C Recommendations for Verifiable Credentials, described in this overview document, provides a mechanism to express these sorts of credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable.

運転免許証は自動車を運転できることを証明するために、大学の学位は教育レベルを証明するために、そして政府発行のパスポートは国と国との間を移動することを可能にします。この概要文書で説明されている W3C 検証可能な資格証明書のファミリーは、暗号的に安全でプライバシーを尊重し、機械検証可能な方法で、こうした資格証明書をウェブ上で表現するための仕組みを提供します。

（DeepLで機械翻訳） 

 

 

VC-JOSE-COSEがCRに

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

VC-JOSE-COSEがW3CのCR（勧告候補）になっていますね。

https://www.w3.org/TR/2024/CRD-vc-jose-cose-20240425/

Mike Jonesも書いているように先日同じく勧告候補になったVCDM（Verifiable Credentials Data Model）v2.0では前のバージョンと異なりクレデンシャルフォーマットにJSON-LDだけをサポートするようになっています。

一方でこのVC-JOSE-COSEはJOSE、SD-JWT、COSEをスコープとしているのでなんだかチグハグな感じになりつつあります。

まぁ、そもそもクレデンシャルフォーマットがISOのmDoc、IETFのSD-JWTやJWP、W3CのVCDMと割れてしまっているが今後どうなっていくんだろうか・・・という話ではあるんですが。

追記）崎村さんからOpen Wallet Foundationが見ているクレデンシャルフォーマットの一覧を頂いたので貼っておきます。16種類もある・・・（2024年4月末時点）

https://github.com/openwallet-foundation/credential-format-comparison-sig/tree/main/data/Credential-Format

[DID]リゾルバあれこれ

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

完全に個人メモです。

ご存知の通りDID（Decentralized Identifier）の構造は
did:{method}:{method specific identifier}
となっています。

例えば、イーサリアムだったら
did:ethr:0xE6Fe788d8ca214A080b0f6aC7F48480b2AEfa9a6
という感じです。

現状Blockchainの系がバラバラと乱立している状態なので、系の間でユニバーサルに一意に識別できる仕組みがないとDIDがIdentifier（識別子）としての役割を果たせないことはわかるんですが、そもそも論としてメソッド名が識別子の中に入っているって言うのもなぁ、と個人的には思いますが他にいいアイデアが出せるわけではないので自粛しておきます。

話はそれましたがDIDが上記の様な形式になっている以上、系を跨いで識別子（DID）および関連する情報（DID Metadata）を解決する仕組みがないと、DIDを使ったアイデンティティ管理システムが成立しません。ということで今日の本題の「リゾルバ」が必要になるわけで、実質標準になっているのがMarcusがやっている「Universal Resolver」である、というわけです。

元々DID関係はW3CのWeb Payment WG、Verifiable Credentials TF、OASISのXDI TC Registry WGが別々にやっていて、2015年〜2016年あたりでDPKIとかのドラフトとして出てきた中でレゾルバの必要性に注目してUniversal Resolverを作った、みたいな話を2018年のEuropean Identity and Cloud ConferenceでMarkusから聞いたとき、リソルバ自身の信頼性ってどうやって担保するの？？みたいな話を聞いた覚えがあります。その時にMarkusはリゾルバ自体はOSSだからプライベート実装しても良いし、アプリに組み込んでも良いよ、みたいな話をしていました。

そんな中でMarkusがサンプル実装として公開したのが先の https://uniresolver.io/ で、他にもベンダが実装してきている例としてMicrosoftが自前のDID Projectで実装したのが、 https://beta.discover.did.microsoft.com/ だったりする、ということなんですね。

と言うことで、それぞれどんな感じなのかみてみようと思います。

登録されているDID method

そもそも現在どんなDID methodが存在しているのか、という話になるのですが、DID methodはW3Cのコミュニティグループで「ゆるく」管理？されています。

https://w3c-ccg.github.io/did-method-registry/

今日（2020/07/23）の段階で59個も登録されてるんですね。残念ながらuPortはdeprecatedになってます（単にethrに引っ越しただけですが）。

Universal Resolverの状況

Universal ResolverではメソッドをサポートするためにDriverという単位でプラグインを追加していく形になります。

githubのレポジトリを見るとDriverの開発の方法や現在開発されているDriverの一覧を確認することが出来ます。

https://github.com/decentralized-identity/universal-resolver/

同じく今日時点で28種類ある様です。

使い方としては非常にシンプルでUniversal Resolverをデプロイし、エンドポイントに対して

curl -X GET http://localhost:8080/1.0/identifiers/did:sov:WRfXPg8dantKVubE3HX8pw

という感じでGETしてあげればDID metadataが返ってくるという仕掛けです。

これをWebで簡単に触れる様にしたのが先に書いた

https://uniresolver.io/

ってことです。

Microsoftの実装は？

前回のポストでも紹介しましたがMicrosoftもDIDの世界に突き進んでいるわけですが、当然マネージドなリゾルバを提供しています。
公開されているサンプルソースを掘っていくと、

https://beta.discover.did.microsoft.com/

というURLが出てきます。

ご存知の通りMicrosoftのDID/IONのメソッドは ion で、現在Universal Resolverではサポートされていません。ionメソッドのDIDをUniversal Resolverで解決しようとしてもNFです。

と言うことでMicrosoftのDIDを解決するには上記のリゾルバを使うしかなさそうです。

使い方としては、Universal Resolverと同じで

curl -X GET https://beta.discover.did.microsoft.com/1.0/identifiers/did:ion:EiBo3GQwMgF...

と言う感じです。

DID metadataの視認性を上げるためにFirefoxで開いてみます。

ふとした疑問として、どこまでMicrosoftのリゾルバは他のメソッドをサポートしているんだろう？と思って実験してみました。サンプルとして使ったDIDはUniversal Resolverのレポジトリにあるテスト用のものを使いました。

以下が結果です。

method	support
sov	OK
btctr	OK
v1:test	OK
key	OK
ipid	NG? Universal ResolverでもTimeoutするのでipid側の不具合かも
web	NG? サンプルになっているのがdid:web:uport.meなのでDIDの問題かと
ethr	NG. Timeout
nacl	OK
jolo	NG. Timeout
stack	OK
erc725	NG? Universal ResolverでもExceptionが出るのでドライバの問題っぽい
hcr	OK
neoid	NG? Universal ResolverでもExceptionが出るのでドライバの問題っぽい
elem	NG
github	NG
ccp	OK
work	OK
ont	OK
kilt	OK
evan	OK
echo	OK
factom	OK
dock	OK
abt	OK
trustbloc	NG
sirius	NG? Universal ResolverでもExceptionが出るのでドライバの問題っぽい
mpg	NG? Universal ResolverでもExceptionが出るのでドライバの問題っぽい
trust	NG? Universal ResolverでもExceptionが出るのでドライバの問題っぽい
io	NG? Universal ResolverでもExceptionが出るのでドライバの問題っぽい

ということで完全に自分メモでした。