2024年6月30日日曜日

Trusted WebがDX実現にどの様に貢献するかに関するドキュメントが公開されています

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

先日のホワイトペーパー英語版に加えて
  • DX実現に向けたデータ活用におけるトラスト向上のためのアクションリスト(α版)
  • Trusted Webにおけるガバナンスの構築に関する考え方
の2つのドキュメントが公開されています。



Trusted Webのサイトより



残念ながら「トラスト」の概念は簡単に理解できるものではなく現場レベルでシステム設計に影響を与えるには時間がかかります。そこで、トラストが経営やDXにどの様に影響を与えるのかを執行役員レベルの方々に理解いただくのは非常に重要なことです。

また、ITシステムのみで実現できることではなく、ホワイトペーパーにも記載しているガバナンス設計も非常に重要な要素となっています。そのため、ガバナンス構築に関する考え方をホワイトペーパーに加えてより噛み砕いてドキュメント化しているので、こちらも非常に有用だと思います。

ぜひ活用していきましょう。

2024年6月29日土曜日

Shared SignalsのPublic Review期間が始まっています

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

先日のOpenID Technightの中心テーマでもあったShared Signals Frameworkに関連する仕様群のPublic Review期間が始まっています。


今回対象となっているのは、
  • Shared Signals Framework Draft 03
  • CAEP Draft 03
  • CAEP Interoperability Profile Draft 00
の3つです。

今後のスケジュールは、
  • Implementer’s Draft public review period: Thursday, June 27, 2024 to Sunday, August 11, 204 (45 days)
  • Implementer’s Draft vote announcement: Monday, July 29, 2024
  • Implementer's Draft early voting opens: Monday, August 5, 2024 *
  • Implementer’s Draft voting period: Monday, August 12, 2024 to Monday, August 5, 2024 (7 days)*
となっていますので、この機会にOpenID Foundation(米国)の会員になって投票してみてはいかがでしょうか?

2024年6月28日金曜日

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


2024年6月27日木曜日

Auth0 Ambassadorプログラム

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

Auth0がOktaの一部となり一つの時代が終わったなぁ、とAuth0 Ambassadorの一人としても感慨に耽っていたここ3年くらいですが、諸々のプログラムが終わっていくのは寂しいものです。


ということでAuth0 Ambassadorプログラムはまだページは残っていますが終了していますね。

少し前のことですが、プログラム終了に伴い記念メダルをもらいました。



色々と面白いプログラムだったので少し寂しい思いはありますが、Auth0改めOkta CICはたまに触っていこうと思います。

ちなみに、Market Placeって仕組みもあり、某社がこんな感じでIdentity VerificationのActionを公開していますよ。


2024年6月26日水曜日

W3C Verifiable Credentials Overviewを読む(6)

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


続けて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について読んでいきたいと思います。 

 

2024年6月25日火曜日

Internet DogからInternet Toasterへ

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

インターネットにおけるデジタルアイデンティティの課題を説明する際に昔から使われているのがお馴染みの「The Internet Dog」です。この絵は1993年にThe New Yorkerという雑誌に掲載された風刺画で、「インターネットの向こう側であなたとやり取りしている人は犬かもしれない」という現在も続くアイデンティティに関する課題を見事に表現したものでした。




どうやら最近は犬ですらなく(AIとかIoTを想起しているのかと)、トースターを例にした絵がTwitter上に投稿されています。




いずれにしてもインターネット上に限らずデジタルアイデンティティの重要性はますます高まっていくことになりそうです。



2024年6月24日月曜日

W3C Verifiable Credentials Overviewを読む(5)

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


続けて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をみていこうと思います。 

 


 

 

 


2024年6月23日日曜日

W3C Verifiable Credentials Overviewを読む(4)

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

続けて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によって表明されることが重要、ということです。


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




2024年6月22日土曜日

デジタルアイデンティティ人材育成推進ワーキンググループの中間報告会の動画が公開されました

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

先日開催されたOpenIDファウンデーションジャパンのデジタルアイデンティティ人材育成推進ワーキンググループの中間活動報告会の動画が公開されています。

中間活動報告会自体についてはこちらでアナウンスさせていただいた通りです。

https://idmlab.eidentity.jp/2024/05/blog-post_23.html


こちらが動画です!

技術・ビジネスの両面から勉強しながら成果物をまとめていこうという会なので、内容は試行錯誤をしてくれている最中となり詰めが甘い部分もありますが、ぜひ暖かく見守っていただければと思います。



2024年6月21日金曜日

デジタル認証アプリがついにやってきた

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

このブログでも色々と取り上げたり、各種記事でも話題になったデジタル庁の認証アプリがついにリリースされるようです。

今回のニュースリリース

https://www.digital.go.jp/news/f0d122a1-0608-4e99-b6c6-59461900ca0a

※なんか消えたみたいです。(復活したみたいです)

アプリのページは残っています。 

https://services.digital.go.jp/auth-and-sign/ 


これまでの記事など

読売新聞(若江さんの記事)※崎村さんの「なだこれは」が頭の中でリフレインされると話題になった

https://www.yomiuri.co.jp/national/20240423-OYT1T50126/

日経BP(長倉さんの記事)

https://xtech.nikkei.com/atcl/nxt/column/18/00989/022000140/

当ブログでも

https://idmlab.eidentity.jp/2024/04/blog-post.html



軽く公開された資料を眺めた程度ですが、まとめるとこんな感じかと。

  • 実装ガイドラインおよび民間向けと行政機関向けそれぞれのAPIリファレンスが公開されている
  • 6/24から利用したい事業者の登録申請が開始される
  • すでに「横浜市 子育て応援アプリ(パマトコ)」と「三菱UFJ銀行スマート口座開設」への導入が予定されている
  • 開発者向けのAPIリファレンス等が公開されている(割とシンプルなOpenID ConnectのOP)
  • 認証と署名はスコープで使い分ける仕組みになっている(署名の場合はsignをスコープに指定する)
  • 取得できるのは基本4情報となっている(券面の写真なんかは取得できなさそう)
  • Discoveryエンドポイントはすでに公開されている(本番環境:https://auth-and-sign.go.jp/api/realms/main/.well-known/openid-configuration
  • パブコメにも書いた国による情報収集の話はFAQに『デジタル庁は、「電子証明書のシリアル番号」を保有しますが、氏名や住所等をはじめ、その他の個人に関する情報は保存しません。(デジタル庁は、行政機関等及び民間事業者から依頼を受けて署名API又は4情報連携機能を提供する場合は、氏名等の4情報を一時的に保持しますが、1時間以内に必要な処理を行った後、デジタル認証アプリサーバから削除します。)』と記載された

導入予定のサービスとして横浜市子育て応援アプリと三菱UFJ銀行スマート口座開設が紹介されています。

Discoveryエンドポイントは公開済みなので色々と実装が見えてきます。

国による情報収集についてはFAQに記載されました。


全般的に良い方向だと思うので、色々なところで使えるようになるといいですね。
今後も気になる点があればXで文句を言うだけじゃなくてフィードバックをちゃんとしていくのが良いと思います。

2024年6月20日木曜日

W3C Verifiable Credentials Overviewを読む(3)

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

引き続き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の話です。

2024年6月19日水曜日

W3C Verifiable Credentials Overviewを読む(2)

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

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

前回触れた通り、以下の目次構成となっているドキュメントです。
  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ばかりに目が行きますが様々な関連スペックから構成されていることがわかります。

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

2024年6月18日火曜日

京都大学 学術情報メディアセンターセミナー「デジタルIDの最新動向」でお話します

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

来週6月25日に京都大学の学術情報メディアセンターでデジタルIDについてお話しさせていただきます。


告知・申込サイト

会場はもちろん京都大学ですが、ハイブリッド形式での開催となるのでリモート視聴も可能です。
旧来のSAMLをベースとしてアカデミックフェデレーションの話からOpenID Connectへの道筋の話や、学術機関におけるトラストフレームワークの今後の話、学位・学修歴などのデジタルクレデンシャルの利活用へのシナリオの話など、80分でまるっとお話ししようと思います。
ぜひご参加ください。

こちらがアジェンダです。

◆16時30分~16時35分 オープニング

◆16時35分~17時05分
講演者:清水 さや子(国立情報学研究所アーキテクチャ科学研究系 助教)
講演題目:Persistent IDの可能性とオンライン本人確認システムの紹介
講演概要:組織で提供されるIDは、通常、入学や採用時に発行され、卒業や離職時には無効化されます。そのため、所属組織が変更されると、その時点で、新しいIDを利用することになります。一方で、研究データ基盤サービスなど、所属組織の異動に関係なく継続利用が求められるサービスも存在します。このようなケースに対しては、オンラインでの本人確認を利用したスムーズなID移行が期待されています。本セッションでは、Persistent IDの活用や、スムーズにID移行を支援するためのオンライン本人確認システムについて紹介します。

◆17時05分~18時25分
講演者:富士榮 尚寛(伊藤忠テクノソリューションズ株式会社・みらい研究所長)
講演題目:学術機関におけるデジタルIDとトラストのこれから
講演概要:従来の学生や教員のアカウント管理や認証など、各種情報システムへのセキュアなアクセスを行うためのID管理・認証という世界観から、デジタル学修歴やデジタル学生証など新たなデジタルツールの利活用を行うためのデジタル・トラストをいかにして構築するか?が近年着目されています。本講演では従来のデジタルIDやトラストのあり方を踏まえた上で、今後のデジタル社会の発展に向けたデジタルIDとトラストのあり方について議論します。

◆18時25分~18時30分 クロージング




2024年6月17日月曜日

W3C Verifiable Credentials Overviewを読む(1)

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


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

なお、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で機械翻訳) 

 

 


2024年6月16日日曜日

SAP Identity ManagementからEntra IDへのマイグレーションガイド

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

MicrosoftがSAPと協力してSAP Identity ManagementからEntra IDへのマイグレーションガイドを発行しています。SAP社が同社が提供するオンプレミス版のIdentity ManagementソリューションであるSAP Identity ManagementのEOSL(サービス終了)を2027年で終了することを受けての対応ですね。

SAP社からのEOSLのアナウンス
Preparing for SAP Identity Management’s End-of-Maintenance in 2027

https://community.sap.com/t5/technology-blogs-by-sap/preparing-for-sap-identity-management-s-end-of-maintenance-in-2027/ba-p/13596101

 

このアナウンスを見ると同社が提供しているクラウド版の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ブログでのアナウンス

https://techcommunity.microsoft.com/t5/microsoft-entra-blog/sap-identity-management-to-microsoft-entra-id-migration-guidance/ba-p/2520428

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_PERSON、MX_ROLE、MX_PRIVILEGEの各表をGraph APIやPowerShell等でユーザやIGA等へマッピングしていくというアプローチが紹介されています。

※プレフィックスが「MX_」、、、変わってないなぁ・・・MaXwareのMXです。


個人的には非常に感慨深い、製品のライフサイクルの終焉と新たなエコシステムの構成が見られた瞬間でした。。。SAP IdMをお使いの皆さん、頑張って移行してください。

2024年6月15日土曜日

政策提言「デジタル・ニッポン2024」を見ていく(5)

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

しばらく間が開きましたが、自民党の政策提言「デジタル・ニッポン2024」をみていきます。今回で本体部分は終わりです。ということで最後の「提言」部分です。


基本的にはこれまでみてきたことのまとめが記載されています。

デジタル・ニッポン 2024 では、デジタル社会推進本部における議論を踏まえ、「データ戦略」に軸足をおいてデータ連携と利活用のための課題や具体的な取組を示した。

これまでのデータ戦略の課題を克服し、変化の速い技術やサービスの進展の中でデータ戦略が⾃律的にアップデートされていくようにするため、制度ベースの戦略プロセスと技術ベースの戦略プロセスが相互に関連しながら新たな価値を創造していく「プロセス指向のデータ戦略」を構築すべきである。このようなプロセスを各プロジェクトにおいて妨げられることなく高速で柔軟に回転させていくことが求められる。

データ戦略については本文内で「データそのものの真正性や完全性」や「DFFT具現化」などが掲げられていた部分ですね。

昨年のデジタル・ニッポン 2023 でも議論された社会インフラの整備について、行政や⾃治体サービスを中心にさらに進めていくべきであるが、先進的な⺠間サービスとの連携も進めていく必要がある。その際、先の能登半島地震の教訓をしっかりと生かしていく点にも言及したい。 

同じく民間サービスと連携するためにはマイナンバーカードの利活用の推進の文脈で「運転免許証や在留カードとの一体化やiPhoneへの電子証明書搭載を早期に実現」ということも語られていた部分もありました。iPhone部分については早々に実現しそうですが。また、官民のみならず民間のデータ連携についても政府が一定の関与をすることの必要性、そのためにルールやトラストサービスの必要性が語られていました。

データの利活用に当たっては様々な制度的課題への対処が必要となるが、中でもデータ利活用の妨げとなっている個人情報保護法の改革が急務である。個人情報保護委員会において法改正に向けた検討が進められているが、我が国の経済社会に恩恵をもたらすはずのデータ利活用を阻害する規律強化を認めることはできない。あくまでマルチなステークホルダーの意見を丁寧に聴きながら、個人情報の保護と利活用の両立を実現する抜本的な制度見直しを行うことを強く求める。

ちょうど改訂の節目な個人情報保護法に関しても、同意疲れの話に触れ、同意不要とするケースは何なのかを見直すべきである、ということが語られていました。

これらの国内の制度的課題への対処と並行して、国際的なデータ連係基盤の構築やトラストサービスの制度整備が急務であり、そのための検討を早急に進めなければならない。今後は、舞台を世界に移して AI のような新技術をも前提とした新たなデータ戦略のプロセスを展開していくことに期待したい。

最後にデータ戦略の基盤として国や地方の DX をさらに加速して推進するべきであるが、その司令塔であるデジタル庁の体制を強化しつつ、本提言に示したさまざまな施策を戦略的に推進し、我が国社会全体のデジタル変革を進めていくことをここに提言する。

やはりトラストサービスの重要性については本文でも語られた通りであることが提言の中でも繰り返されています。そしてそのためにはEUにおけるeIDASのような統一化された規範がないことが課題として挙げられていた通り、ここでも制度整備が急務である、というように語られているわけです。そして信頼性を担保するためには体制を整え、プロセスの整備とガバナンスが効くような姿を実現することが必要である、ということはこれまでに触れられてきた通りだということですね。


ということで一旦本文のところはこれでおしまいです。公開された資料の添付資料には別途公開されてきたweb3PTのホワイトペーパーなど有益な資料も付いていますので、時間があればこちらも見どころは紹介していければと思います。

2024年6月14日金曜日

Trusted Web推進協議会の23年度の成果物が公開されています

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

昨日の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規格に関するコンフォーマンステスト結果

についても公開されていますので、こちらもご参照ください。
現在OpenID Foundationで開発中のOpenID for Verifiable Presentationsのコンフォーマンステストに関するレポートとなっています。


2024年6月13日木曜日

cheqdのDID Resolverを試してみる②

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

一昨日に引き続き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のみに頼らなくても良い時代がもう少しで到来しそうです。何しろ最終的にはリゾルバの信頼性が問題になってきてしまうので。

2024年6月12日水曜日

Verifiable Credentials改めReusable Identity?何をどこまで検証すべきなのか

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

先日のIdentiverseやEuropean Identity & Cloud Conferenceで目についたのが「Reusable Identity」というキーワード。

どうも話の流れを聞いていると、一般名詞としてのVerifiable Credentials(mDocやSD-JWT-VCやW3C VCDM、anonCredまで含む)の中でIdentity Verificationに使うものをReusable IdentityとかDecentralized Reusable Identityと呼ぶことに(誰かが)したらしいです。

openart.aiに描かせてみたら、なんだか資源ごみみたいになってしまった。

ちょっと検索してみると、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による機械翻訳) 

https://www.identity.com/what-is-reusable-identity/


この話とWalletのセキュリティの話がかなり密接に結びついて分類が始まってきているように思えているので、今日はその辺りの話を整理し始めようかと思います。

WalletとHolderの違い

そもそもWalletとHolderが同じものとして扱われてしまうことが多いのですが、EICのパネルでも少し話題に登った通り、IssuerはクレデンシャルをWalletに対して発行するのではなく、Holderに対して発行するんですよね。

W3C VCDM1.1のいつもの図を見てもそのように記載されています。

どうもこのHolder=Walletというイメージが先行し過ぎてしまっていることが混乱を招く一因になってしまっていると思います。


WalletとHolderとクレデンシャルのバインディング

ここでは3つの話があります。

  1. Holder-クレデンシャルのバインディング
  2. Wallet-クレデンシャルのバインディング
  3. Holder-Walletのバインディング


まず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は何をどこまで、どうやって検証するべきなのか

先に挙げたバインディングを含め全て検証をすれば確かに固い仕組みが出来上がると思います。ただし、Verifierは全ての資格情報の種別に対してそれらの検証をしたいわけではないことに注意しないといけないと思います。

例えば、単にお店の会員カードのような資格情報だった場合に持参人(Holder)とCredential Subjectが異なっても大きな問題にならないでしょうし、ビジネス機会を考えるとある程度のクレデンシャル共有は許容すべきとの意見もあると思います。

また、全てのWalletがSecure Elementに鍵を持ち、確実にIssuer等によって管理された状態となるのは非常に難しいですしToo Muchと言えます。(現実的にSecure Elementが使える端末は限定されますし、そのためにSIMを使うのか、またはマイナンバーカードやNational IDカードのICチップやクラウドHSMなどを使うのか?など非常に無理がある話です)


こうなると、Verifierの視点で何をどこまで検証すべきなのか?についてはシナリオと資格情報の種別によって変わってきそうです。
  • シナリオは、対面なのかリモートなのか
  • 資格情報の種別は、身元確認(Identity Verification)に使うものなのか単なる資格確認なのか
こんな視点で分類ができると思います。

また、「検証」という言葉についても何を?という話があります。NIST SP800-63A-3的に言うと、
  • Validation:エビデンスの真正性の確認
  • Verification:持参人がエビデンスが指し示すエンティティと同一であることの確認
だと思います。(NIST SP800-63の中でもValidationとVerificationの使い分けは混乱が見られるので全体にこの定義が当てはまるわけではありませんが)

これらの視点で考えると、Verifierは対面(デジタル)でもリモートでも
  • 受け取ったクレデンシャルのValidationは行いたい
  • 持参人の検証はシナリオによる
ということが言えると思います。

また、対面かリモートかによって、Verificationの方法は若干変わります。
  • 対面ならValidateされたクレデンシャル内の顔写真などと持参人を比較(Verify)する
  • リモートならValidateされたクレデンシャルが指し示すエンティティと同一であることを別途本人確認(例えばeKYCを含む)した結果と比較する

おそらく、Reusable Identityの文脈においてはこのリモートにおけるVerificationも一つのクレデンシャルの中で閉じて実施する必要があるので、先に挙げた3つのバインディングにかなり気を使うことになります。(要するにパスキーのように一回の動作で多要素認証と同等のことを行う)
しかしながら、単なる資格確認であればVerificationについては他のオプション(eKYCなど)と組み合わせることで実現が可能な話なので、Walletの作り方を含めそこまで気にし過ぎなくても良いのではないか、と思います。(現に、OpenBadgeなどではバッジと持参人の紐付けの確認は検証側の仕事として整理されています)

ちょっとダラダラと書きましたが、Walletのエコシステムを拡充させるためにはApple Walletがマイナンバーカードを格納できるようになった!万歳!で思考停止せずにちゃんと考える必要がありそうです。

2024年6月11日火曜日

cheqdのDID Resolverを試してみる①

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

そういえばDIFのUniversal Resolverばっかり使っていましたが、他にもオープンソースのDID ResolverとしてcheqdのDID Resolverもあるなぁ、ということでセットアップしてみたいと思います。

cheqdのWebサイト。最近よくあるVC関係のプラットフォームを提供している会社ですね。(VC-JWT、JSON-LD、AconCredに対応しているようです)


こちらに開発者向けドキュメントがあり、dockerにセットアップする方法が書かれています。

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が帰ってきますね。

ちなみに、サンプルはdid:cheqdという独自メソッドですが、他のメソッドへの対応状況はどうなっているのかみてみます。とりあえず手元にあったdidがionとwebだったので試してみましたが、両方ともNGでした。。。。

    "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は解決することができました。



次回は手元にセットアップしてみたいと思います。






2024年6月10日月曜日

いよいよInteropカンファレンスが迫ってきました

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

以前告知させていただいた通り、明後日6月12日〜14日でInteropカンファレンスが幕張で開催されます。

今回は(も)、Trusted Webの話を2コマにわたってお届けしますので、ぜひお越しください。QAも対応する予定なのでぜひ質問してくださいね。(某林檎の件とか質問くるのかなぁ)


YB2-01

Trusted Web(1)  デジタル空間におけるトラストをいかにして実現するか?


YB2-02

Trusted Web(2)  実社会での本格利用に向けて動き始めた 分散型IDとデジタルIDウォレット



素晴らしいパネリストの方々と議論できるのが私も楽しみです!


2024年6月9日日曜日

Internet Identity Workshop 2024Bの申し込みが始まりました

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

Identiverse、EICが終わったところですが、今日からInternet Identity Workshop(IIW)の申し込みが開始されました。
次は10月29日〜31日、場所は変わらずMountainViewのComputer History Museumです。



ちなみに、今ならEarly Bird Registrationができるので安いですよ。
ギリギリになると満席になって申し込めなかったりすることもあるので行く予定の方はお早めに。

ちなみにIIWの前の週はSIDI Hubの東京イベント、翌週はIETF(ダブリン)ですので、全部参加する人は大変ですね・・・(多分私もその一人)

2024年6月8日土曜日

OpenID Federation Implementer's Draft4のパブリックレビュー期間が始まっています

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

Identiverse、EICで全然書く暇がありませんでしたが、OpenID FederationのImplementer's Draft 4のパブリックレビュー期間が始まっています。



X.509と並びトラストを確保するためのプロトコルとして注目が集まっている仕様なので要注目ですね。

European Identity & Cloud Conference クィックレビュー Day4

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

いよいよEICも最終日です。
そして私の出番でもあります。出番が最終日にあるとずっと落ち着かないんですよねぇ。

まあ、私もコマはそのうち国内でもご説明する機会があると思うのでその際に詳細は、ということで。
DNPの岡本さんに写真いただきました。ありがとうございます。

しかしキーノート部屋がアサインされるとは思わなかったので無駄に広い空間でビビりました。
ちなみに舞台裏はこんな感じになっております。


ということで自分の出番が終わると一気に気が抜けてしまったのですが、午後もちょっとだけセッションを聞きました。

Food Supply Chain: Pioneering a Digital Farm Wallet with a Consortium in New Zealand - Klaeri Schelhowe

Identiverseの初日にPaul Ashleyが話していた農業領域でのVerifiable Credentialsの利活用ユースケースの話です。
主に農業の中で発生するデータマネジメントについてフォーカスしている内容ですね。


農業セクターもグローバルサプライチェーンですし、当然データの真正性や相互運用性は大事ですし、サステナビリティ(GHGなど)の文脈におけるエビデンスにも検証可能性は非常に大きな意味を持つわけです。


ということでニュー字ランドでTrust Alliance NZというアライアンスを作ったという話です。Farmer Association(農協?)に加えて技術スタックを持った人たちも含めアライアンスを組んでいるそうです。

農業領域におけるインプットデータ、アウトプットデータとして以下に着目している、と。


ユースケースは多岐に渡り、金融アクセスやGHGエミッションなどデータ共有が必要となる14のユースケースを選定しているとのことです。


期待される成果としては、
  • 市場参入、持続可能な金融、業務効率の向上を促進
  • ブランド価値の向上(信頼から証明によるブランドへ)
  • コンプライアンスへの取り組みを付加価値に変える
が挙げられています。やっぱり農業ってブランドだよなぁって思います。

実装側面から言うと、Digital Farm Wallet Pilot ProjectをAnonyomeと一緒にやっているとのこと。こちらは先日のPaulのセッションで話のあった組織ウォレットの話ですね。

農家さんにとってのメリットも色々と。

ただ、コンソーシアムモデルならではの難しさも。競争と協業のバランスなど泥臭い話は多いと思います。今後の動きに注目ですね。


Closing Keynote - Martin Kuppinger

いよいよClosingです。4日間は長いようであっという間です。


来年は2025/5/6-9、同じ場所です!