 |
| Trusted Webのサイトより |
こんにちは、富士榮です。
先日日本語版のホワイトペーパーが公開されたTrusted Webですが、英語版がリリースされています。
https://trustedweb.go.jp/en/documents/
関連URL）
https://www.kantei.go.jp/jp/singi/digitalmarket/trusted_web/index.html
https://www.kantei.go.jp/jp/singi/digitalmarket/index_e.html
こんにちは、富士榮です。
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 スキーマとの関連性を表現するための標準プロパティが追加されています。
はい、その通りです。
クレデンシャル（コンテナ）のフォーマットや署名形式、トランスポートプロトコルが一致していたとしてもやり取りされるデータの構造が合っていないと少なくとも機械的に処理ができません。もう一つ言うならデータの意味も、ですね。この辺りを踏まえてスキーマと言うべきでしょう。（現実世界では単なるデータ構造だけを指していて、意味の解釈についてはあまり踏み込めていないところもあり、ここは今後の課題となるでしょう）
例を挙げて考えてみています。
{
"@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スキーマを返す必要があります。例えば、
{
"$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 とほとんど同じです。
{
"@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について読んでいきたいと思います。
こんにちは、富士榮です。
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で参照されているアプリケーション固有の用語集に追加されています。
{
"@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 シリアライズでは、結果は次のようになります。
{
"@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をみていこうと思います。
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. |
私は、属性からクレームへとパラダイムを変更する必要があると話し合った日のことを覚えています。属性とは、単一企業の閉じた世界での特性を表す言葉でしたが、世界を開いてドメイン間を行き来するようになると、そのことに気付きます。それは単に属性の問題ではなく、誰が誰について何を言っているかという問題です。属性はある存在によって語られ、その存在を実際に信じるかどうかを判断しなければなりません。つまり、クレームという概念が生まれたのです。クレームとは、疑わしい属性のことであり、どのような目的のために何を信用するかを決めるための技術が必要なのです。
つまり、サブジェクトやクレデンシャルに関する情報で検証されるべきものなんですよね。そう言う意味でが元々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では標準のプロパティを多く定義していますし、独自でクレデンシャルを定義する際には必要なプロパティを定義することができるわけです。
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. |
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. |
こんにちは、富士榮です。
先日開催されたOpenIDファウンデーションジャパンのデジタルアイデンティティ人材育成推進ワーキンググループの中間活動報告会の動画が公開されています。
中間活動報告会自体についてはこちらでアナウンスさせていただいた通りです。
こちらが動画です！
技術・ビジネスの両面から勉強しながら成果物をまとめていこうという会なので、内容は試行錯誤をしてくれている最中となり詰めが甘い部分もありますが、ぜひ暖かく見守っていただければと思います。
こんにちは、富士榮です。
このブログでも色々と取り上げたり、各種記事でも話題になったデジタル庁の認証アプリがついにリリースされるようです。
今回のニュースリリース
https://www.digital.go.jp/news/f0d122a1-0608-4e99-b6c6-59461900ca0a
※なんか消えたみたいです。（復活したみたいです）
アプリのページは残っています。
読売新聞（若江さんの記事）※崎村さんの「なだこれは」が頭の中でリフレインされると話題になった
日経BP（長倉さんの記事）
https://xtech.nikkei.com/atcl/nxt/column/18/00989/022000140/
当ブログでも
軽く公開された資料を眺めた程度ですが、まとめるとこんな感じかと。
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. |
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を見ていきます。
Verifiable Credentials Overview
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による機械翻訳）
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で機械翻訳）
Preparing for SAP Identity Management’s End-of-Maintenance in 2027
このアナウンスを見ると同社が提供しているクラウド版のIdentity ManagementサービスであるSAP Cloud Identity Servicesへの移行、もしくはSAP社から見るとパートナーソリューションであるMicrosoftのEntra IDへの移行を検討するように記載されています。
ちなみに、SAP Cloud Identity Serviceのインテグレーションガイドはこちらにありますので、シンプルにこちらに移行するユーザも多いのかとは思います。
しかし、SAP Identity Managementは懐かしいというか思い入れがあるというか・・・
昔、MaXwareがSAPに買収されたことに伴いNetWeaver（懐かしい！）ブランドとなったIdentity Managementを手元にセットアップして遊んでいた時期もありました。
SAP NetWeaver Identity Management事始め（アーキテクチャ整理）
https://idmlab.eidentity.jp/2009/01/sap-netweaver-identity-management.html
そう、実は2002年とか2003年くらいにアイデンティティの世界にどっぷりハマり始めたきっかけの一つがノルウェーのMaXware社が提供していたDSE（Data Synchronization Engine）やMIC（MaXware Identity Center）だったんです。その後、これらの製品はSAP社によるMaXware社の買収（2006年くらいだったかな？）に伴いSAPエコシステムの中に溶けていったわけですが、プロビジョニング中心だった当時のIdentity Managementの潮流の中では結構良い製品だったなぁ、と個人的には思います。（他にもSunやNovell、Microsoftなどの製品もかなり触ったのですが直感的にGUIでルールが構成できて、細かいルールはJavaScriptでカスタマイズできる、という点でMaXware製品はすごく簡単でよかったです）
ということでEntra IDへのマイグレーションについてです。こちらでアナウンスおよびガイドが公開されています。
Microsoftブログでのアナウンス
ID 管理シナリオの SAP IDM から Microsoft Entra への移行
https://learn.microsoft.com/ja-jp/entra/identity/app-provisioning/migrate-from-sap-idm
ガイドをみていきます。
全体像としてはSAP SuccessFactorsからEntra IDへのリコンサイル（取り込み）、オンプレのSAP ECCへのプロビジョニング、S/4 HANAなどへのプロビジョニングをするためにSAP Cloud Identity Servicesへの連携がベースになっているようです。
※プレフィックスが「MX_」、、、変わってないなぁ・・・MaXwareのMXです。
個人的には非常に感慨深い、製品のライフサイクルの終焉と新たなエコシステムの構成が見られた瞬間でした。。。SAP IdMをお使いの皆さん、頑張って移行してください。
こんにちは、富士榮です。
しばらく間が開きましたが、自民党の政策提言「デジタル・ニッポン2024」をみていきます。今回で本体部分は終わりです。ということで最後の「提言」部分です。
デジタル・ニッポン 2024 では、デジタル社会推進本部における議論を踏まえ、「データ戦略」に軸足をおいてデータ連携と利活用のための課題や具体的な取組を示した。
これまでのデータ戦略の課題を克服し、変化の速い技術やサービスの進展の中でデータ戦略が⾃律的にアップデートされていくようにするため、制度ベースの戦略プロセスと技術ベースの戦略プロセスが相互に関連しながら新たな価値を創造していく「プロセス指向のデータ戦略」を構築すべきである。このようなプロセスを各プロジェクトにおいて妨げられることなく高速で柔軟に回転させていくことが求められる。
データ戦略については本文内で「データそのものの真正性や完全性」や「DFFT具現化」などが掲げられていた部分ですね。
昨年のデジタル・ニッポン 2023 でも議論された社会インフラの整備について、行政や⾃治体サービスを中心にさらに進めていくべきであるが、先進的な⺠間サービスとの連携も進めていく必要がある。その際、先の能登半島地震の教訓をしっかりと生かしていく点にも言及したい。
同じく民間サービスと連携するためにはマイナンバーカードの利活用の推進の文脈で「運転免許証や在留カードとの一体化やiPhoneへの電子証明書搭載を早期に実現」ということも語られていた部分もありました。iPhone部分については早々に実現しそうですが。また、官民のみならず民間のデータ連携についても政府が一定の関与をすることの必要性、そのためにルールやトラストサービスの必要性が語られていました。
データの利活用に当たっては様々な制度的課題への対処が必要となるが、中でもデータ利活用の妨げとなっている個人情報保護法の改革が急務である。個人情報保護委員会において法改正に向けた検討が進められているが、我が国の経済社会に恩恵をもたらすはずのデータ利活用を阻害する規律強化を認めることはできない。あくまでマルチなステークホルダーの意見を丁寧に聴きながら、個人情報の保護と利活用の両立を実現する抜本的な制度見直しを行うことを強く求める。
ちょうど改訂の節目な個人情報保護法に関しても、同意疲れの話に触れ、同意不要とするケースは何なのかを見直すべきである、ということが語られていました。
これらの国内の制度的課題への対処と並行して、国際的なデータ連係基盤の構築やトラストサービスの制度整備が急務であり、そのための検討を早急に進めなければならない。今後は、舞台を世界に移して AI のような新技術をも前提とした新たなデータ戦略のプロセスを展開していくことに期待したい。
最後にデータ戦略の基盤として国や地方の DX をさらに加速して推進するべきであるが、その司令塔であるデジタル庁の体制を強化しつつ、本提言に示したさまざまな施策を戦略的に推進し、我が国社会全体のデジタル変革を進めていくことをここに提言する。
やはりトラストサービスの重要性については本文でも語られた通りであることが提言の中でも繰り返されています。そしてそのためにはEUにおけるeIDASのような統一化された規範がないことが課題として挙げられていた通り、ここでも制度整備が急務である、というように語られているわけです。そして信頼性を担保するためには体制を整え、プロセスの整備とガバナンスが効くような姿を実現することが必要である、ということはこれまでに触れられてきた通りだということですね。
ということで一旦本文のところはこれでおしまいです。公開された資料の添付資料には別途公開されてきたweb3PTのホワイトペーパーなど有益な資料も付いていますので、時間があればこちらも見どころは紹介していければと思います。
こんにちは、富士榮です。
昨日のInteropカンファレンスのセッションでも触れましたが、Trusted Web推進協議会の2023年度の成果物がひっそりと（？）公開されています。
2023年度 Trusted Web に関する調査研究の成果物について
https://www.kantei.go.jp/jp/singi/digitalmarket/trusted_web/2023seika/index.html
ホワイトペーパーは以前から公開されていましたが、実証事業の成果物が今回公開されました
ホワイトペーパー
https://trustedweb.go.jp/documents/
なかなかのボリュームですが、ぜひ気になるユースケースがあれば読んでみてください。
また、同時に各種調査レポートも公開されており、私も少しだけお手伝いした
OpenID Foundation規格に関するコンフォーマンステスト結果
こんにちは、富士榮です。
一昨日に引き続きcheqdのDID Resolverを試してみます。
今回は手元に環境をセットアップしてみようと思います。
まずは、gitのレポジトリのクローンをします。
git clone https://github.com/cheqd/did-resolver.git
そしてdocker compose。これでおしまいです。もちろんdocker-compose.ymlをいじってカスタマイズすることもできます。
docker compose -f docker/docker-compose.yml up --detach
これでlocalhostの8080で起動してきますので、curlなどでDIDを投げ込んで解決してみましょう。
まぁ、当たり前ですがちゃんと動きますね。
手軽にDID Resolverが手元で動かせる時代になってきましたね。良い意味でUniversal Resolverのみに頼らなくても良い時代がもう少しで到来しそうです。何しろ最終的にはリゾルバの信頼性が問題になってきてしまうので。
こんにちは、富士榮です。
先日のIdentiverseやEuropean Identity & Cloud Conferenceで目についたのが「Reusable Identity」というキーワード。
どうも話の流れを聞いていると、一般名詞としてのVerifiable Credentials（mDocやSD-JWT-VCやW3C VCDM、anonCredまで含む）の中でIdentity Verificationに使うものをReusable IdentityとかDecentralized Reusable Identityと呼ぶことに（誰かが）したらしいです。
ちょっと検索してみると、identity.comの人のこんな記事が見つかりました。
What Is a Reusable Identity?
Reusable identity is a single set of identity credentials that allows individuals to access multiple platforms without repetitive verification. Unlike traditional centralized systems, which demand separate identity verifications for each service or platform, a reusable identity streamlines the user experience. This approach reduces the burden of multiple verifications and addresses inefficiencies and security risks linked to the repeated sharing of personal information.
再利用可能な ID とは？
再利用可能な ID とは、個人に複数のプラットフォームへのアクセスを許可する、1 セットの ID 認証情報です。従来の中央集権型システムとは異なり、各サービスやプラットフォームごとに個別の ID 認証を要求するシステムとは異なり、再利用可能な ID はユーザーエクスペリエンスを合理化します。このアプローチは、複数の認証の負担を軽減し、個人情報の繰り返し共有に伴う非効率性とセキュリティリスクに対処します。（Deeplによる機械翻訳）
この話とWalletのセキュリティの話がかなり密接に結びついて分類が始まってきているように思えているので、今日はその辺りの話を整理し始めようかと思います。
そもそもWalletとHolderが同じものとして扱われてしまうことが多いのですが、EICのパネルでも少し話題に登った通り、IssuerはクレデンシャルをWalletに対して発行するのではなく、Holderに対して発行するんですよね。
W3C VCDM1.1のいつもの図を見てもそのように記載されています。
ここでは3つの話があります。
まずHolder-クレデンシャスのバインディングです。
発行されたクレデンシャルがHolderとちゃんと紐づいているか（バインディング。要するにちゃんと対象者に対して発行されているか）はVerifierの視点からすると大切な点です。
例えば、特定の資格情報をVerifierが受け取った時に、提示してきた人（Holder）が他人のクレデンシャルを渡してきていたら問題になるケースも多いはずです。（もちろん全てのケースではない。これはVerifierのシナリオに依存する。このVerifier側の都合である、という点は非常に重要）
Verifiable Credentialsの場合、通常はVerifiable Presentationの発行者となるHolderのデジタル署名と、発行者の識別子とVerifiable Credential内のCredential Subjectの識別子が一致していることを持ってHolderとクレデンシャル発行対象が同一のエンティティであることを確認するわけです。
次に、Wallet-クレデンシャルのバインディングです。
前述のHolder-クレデンシャルのバインディングの前提はWalletが悪さをしない、ということになるので、特に国が発行する身分証明書などについては特定の基準を満たした（例えば鍵の管理がしっかりしているなど）Wallet出ないと困るわけです。こうなるとWalletとクレデンシャルの紐付け（バインディング）も検証する必要が出てきます。
このためにはWalletプロバイダが発行するWallet自体を証明するクレデンシャルと、Issuerから発行されるクレデンシャルを紐付けてデジタル署名を施す、という方法が取られたり、Secure Element等にプロビジョニングされた「管理された」鍵を使ってHolder署名をすることによりWallet自体が管理されたものであることを検証可能にする、という方法が取られたりします。
最後に、Holder-Walletのバインディングです。
要するに、他人がWalletを勝手に使っていないか？という話です。一般にWalletを起動する時にFace IDなどのOSの生体認証機能を使ってアンロックする方法が取られます。
先に挙げたバインディングを含め全て検証をすれば確かに固い仕組みが出来上がると思います。ただし、Verifierは全ての資格情報の種別に対してそれらの検証をしたいわけではないことに注意しないといけないと思います。
例えば、単にお店の会員カードのような資格情報だった場合に持参人（Holder）とCredential Subjectが異なっても大きな問題にならないでしょうし、ビジネス機会を考えるとある程度のクレデンシャル共有は許容すべきとの意見もあると思います。
また、全てのWalletがSecure Elementに鍵を持ち、確実にIssuer等によって管理された状態となるのは非常に難しいですしToo Muchと言えます。（現実的にSecure Elementが使える端末は限定されますし、そのためにSIMを使うのか、またはマイナンバーカードやNational IDカードのICチップやクラウドHSMなどを使うのか？など非常に無理がある話です）
こんにちは、富士榮です。
そういえばDIFのUniversal Resolverばっかり使っていましたが、他にもオープンソースのDID ResolverとしてcheqdのDID Resolverもあるなぁ、ということでセットアップしてみたいと思います。
cheqdのWebサイト。最近よくあるVC関係のプラットフォームを提供している会社ですね。（VC-JWT、JSON-LD、AconCredに対応しているようです）
https://docs.cheqd.io/identity/advanced/did-resolver
なお、https://resolver.cheqd.net/でホストされているものをそのまま使うことも可能ですので手軽に試したい場合はこちらでも良いと思います。
まずは今日は手始めにこちらから試してみようと思います。
こんな感じのサンプルが掲載されています。
curl -X GET https://resolver.cheqd.net/1.0/identifiers/did:cheqd:testnet:55dbc8bf-fba3-4117-855c-1e0dc1d3bb47
細かいですが、サンプルのDIDのDID Documentが帰ってきますね。
"error": "methodNotSupported",
って言われます。
ドキュメントを見ると、
The resolver.cheqd.net API endpoint is run by the cheqd team and only handles did:cheqd credentials.
If you want to resolve DIDs from multiple DID methods, the Universal Resolver project provides a multi DID method resolver.
とありますね。要するに他のDIDを解決したければUniversal Resolverを使え、と。まぁ仕方がないですね。
ちなみに逆にUniversal Resolverでdid:cheqdのDIDは解決することができました。
次回は手元にセットアップしてみたいと思います。
こんにちは、富士榮です。
以前告知させていただいた通り、明後日6月12日〜14日でInteropカンファレンスが幕張で開催されます。
今回は（も）、Trusted Webの話を２コマにわたってお届けしますので、ぜひお越しください。QAも対応する予定なのでぜひ質問してくださいね。（某林檎の件とか質問くるのかなぁ）
YB2-01
YB2-02
素晴らしいパネリストの方々と議論できるのが私も楽しみです！
