DIDs v1.0を読む【Introduction】
はじめに
こんにちは。Audius音楽プラットフォームだけじゃなくて色々な取り組みを展開していて面白いなあ、と感じている細谷です。記事も書いてみたので暇な時間の選択肢にどうぞ。
今回から本格的に仕様書を読んでいきます。まずはIntroduction編です。
調べてみるとQiitaで分かりやすく簡単に全体感をまとめられている記事があありました。手っ取り早く理解したい方はそちらの記事をお勧めします。
（このnoteシリーズは私の勉強日記みたいな物です。Qiitaは読むとモチベが無くなりそうで読めてません笑）
Introduction
概要
ウェブサイトは世界で唯一固有のURL(Uniform Resource Locator)によって紐付けられている。
一方で私たちの情報は一意に規定されているわけではなく企業や組織が各々で管理している状況であり、中央集権的な管理はいくつかの欠点を含んでいる。
情報をユーザー個人が管理できない
情報漏洩が起こりうる
管理者の事情によって情報にアクセス出来なくなる可能性
（倒産や期限切れなど）
既存の管理体制から生じる課題に、DIDは解決策を提供しています。デジタル署名などの信頼できる暗号化技術によって個人や組織自体がIDを発行することが出来る。
特定の組織が情報へのアクセスを保証する(IDの発行)一方で、DIDsによって個人は自らの個人情報をどこまで開示するか制御することが可能になる。
こちらより引用
DIDsの作成とアサーションはエンティティによって制御され、エンティティは相手や状況に依存しないように必要な数のDIDsを持つことが出来る。
よく分からない単語があるので調べてみる。
assertion
表明、断言、主張などの意味を持つ英単語。プログラミングにおいて、あるコードが実行される時に満たされるべき条件を記述して実行時にチェックする仕組みをアサーションという。
entity
In general, with computers, an entity can be another name to describe a user using a system or the system itself. With a program running on a system, an entity may be another way to describe an object.
つまり、DIDsはデータの所有者によって制御されTPOに合わせて開示する範囲を変更することが出来る。といった感じでしょうか。
この仕様書はDIDsの作成から表現までに特定の技術や暗号を前提としているわけではありません。実装者は従来の管理システムに存在するIDからDIDを作成することが出来るため、中央集権的な管理と分散型管理システムは繋ぎこみが可能となっている。
想定読者
DIDsの基盤となっているアーキテクチャの原理を理解したい人
DIDsの発行によって既存のデータと紐付けたいソフトウェア開発者
これからDIDでの操作メソッドを作っていきたい人
A Simple Example
DIDは３つの構成要素からなる文字列です。
Scheme
URI schemeです。URI schemeとはなんでしょうか？chatGPTに聞いてみます
インターネット上にあるデータにアクセスする際の規格を定めている。従来のhttp://とかhttpsです。DIDs上に保存するデータにアクセス際はdidという共有規格を使用する。
DID Method
A definition of how a specific DID method scheme is implemented. A DID method is defined by a DID method specification, which specifies the precise operations by which DIDs and DID documents are created, resolved, updated, and deactivated. See 8. Methods.
didという共通規格のなかでどのような操作を行うのか規定する箇所。
EXAMPLE 1: A simple DID document
{
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/suites/ed25519-2020/v1"
]
"id": "did:example:123456789abcdefghi",
"authentication": [{
"id": "did:example:123456789abcdefghi#keys-1",
"type": "Ed25519VerificationKey2020",
"controller": "did:example:123456789abcdefghi",
"publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
}]
}DIDドキュメント(上記)の中には認証情報まで含められているよう。
Design Goals
DIDsとはVerifiable Credentials Data Modelなどのシステムのコンポーネント(部品)でしかない。後ほど出てくるアーキテクチャ図が分かりやすい。
Verifiable Credentials Dataとは
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. This specification provides a mechanism to express these sorts of credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable.
A verifiable credential can represent all of the same information that a physical credential represents. The addition of technologies, such as digital signatures, makes verifiable credentials more tamper-evident and more trustworthy than their physical counterparts.
今までファジカルなものとして発行されてきた免許証、学位、資格などが暗号化技術を用いることで検証可能なデータとして表すことができるようになる。
DIDsの設計目標は以下にまとめられている。
分散化
ID管理における中央管理機関の存在やsingle point failureを取り除くこと
single point of failure (SPOF)
SPOF refers to one fault or malfunction that can cause an entire system to stop operating.
管理
人間かどうかに関わらず、全てのエンティティに外部管理機関に依存することのない直接的な管理力を付与するプライバシー
エンティティは情報のプライバシーを開示する範囲を設定することで管理することができるセキュリティー
DIDサブジェクトを記述するデータのセットであり、DIDサブジェクトまたはDID委譲者が自らを 認証し、DIDとの関連を証明するために使用できる暗号化公開鍵などの仕組みを含む。DIDドキュメントは、6.表現で定義されるように、1つまたは複数の異なる表現を持つ可能性がある。RepresentationsまたはW3C DID Specification Registries [DID-SPEC-REGISTRIES]で定義されているように、DIDドキュメントは1つまたは複数の異なる表現を持つ可能性がある。
(個人の英語力だとよく分からないので、deeplの翻訳を一旦載せておく)証明ベース
DIDコントローラーが他のエンティティと関わる際暗号化証明を付与することができる(分からん)
DID controller
An entity that has the capability to make changes to a DID document. A DID might have more than one DID controller. The DID controller(s) can be denoted by the optional controller property at the top level of the DID document. Note that a DID controller might be the DID subject.
DID subject
The entity identified by a DID and described by a DID document. Anything can be a DID subject: person, group, organization, physical thing, digital thing, logical thing, etc.
DID document
A set of data describing the DID subject, including mechanisms, such as cryptographic public keys, that the DID subject or a DID delegate can use to authenticate itself and prove its association with the DID.
DID documentによって規定されたエンティティ(DID subject≒ DID controller)が他のエンティティとインタラクティブに関係性を持つ時、暗号化証明を付与することが出来る。いまいち何に対して付与するのかが分からない。
見つけやすさ
他のエンティティを見つけやすくすることで、知ったりインタラクティブな行動を取れる相互運用性
DID インフラが既存の相互運用性を意識してデザインされたソフトウェアやツールを活用できるポータビリティ
システム、ネットワークに依存せずDIDs, DID methodsを装備しているあらゆるシステムで使用できるシンプル
シンプルな機能セットによって技術的理解・導入・デプロイを簡易にする拡張性
相互運用性・ポータビリティ・シンプルさを損なわない拡張性を担保する
Architecture Overview
Verifiable Data RegistryはIPFSに代表されるような分散型サーバーの理解で一旦大丈夫そう。DID resolverはDIDを入力として受け取るとDID documentを出力するもの
Conformance
本仕様書を読むにあたっての注意書き。割愛
感想
イントロだけ読んでもDIDに関する解像度上がった感ある。
$${初学者が書いているため間違いを含む可能性があります。ご了承ください}$$
この記事が気に入ったらサポートをしてみませんか？