なんだか想定以上に長いシリーズになってしまっています。
引き続きW3C Verifiable Credentials Overviewを読んでいきます。
- Introduction
- Ecosystem Overview
- Verifiable Credentials Data Model
- Securing Credentials
- Bitstring Status List
- 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までしかクレデンシャルを発行しないのか?後から増やそうと思ったらどうできるのか、諸々考えることはあります。まさにご利用は計画的に。
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エンコード版です。
まぁ、この辺りを含め以前書いたポストでカバー済みなので省略します。
一応これで本編は終わりです。
追加リソース部分は解説するかもしれませんししないかもしれません。
0 件のコメント:
コメントを投稿