この記事はDigital Identity技術勉強会 #iddance Advent Calendar 2020 20日目の記事です。
この記事の目的
はじめまして、最近一身上の都合によりDIDに入門したkazuhideYSです。某社でID技術をやってます。
さて、最近話題のDIDですが、勉強していて最初に躓いたのはどの仕様書から読めばいいかわからないということでした。
DID関連の仕様を策定している組織は
の2つがメインです。それぞれのサイトには仕様書(のGithubリポジトリ)の一覧はあるのですが、「どれから読んでいけばよいのか」というガイドはありません。私は結局手当たり次第に読んでいきましたが、読んだあとで「これそんなに重要じゃないな……」と思ったり、「こっちから先に読んでおけば他のを理解しやすかったのに……」と思ったりとあまり効率がよく有りませんでした。
本記事では、DIDを効率よく勉強するために、どの仕様から読み進めていくのが良いかを筆者の私見を交えつつ紹介していきます。本記事が皆様の理解の一助となれば幸いです。
注意事項
- 星4以下の優先度は筆者の私見が多分に含まれるため、あくまでも目安としてください。
- 筆者は今秋からDIDの勉強を始めたばかりの初心者であるため、勘違い・誤り等が含まれる可能性が大いにあります。コメント等でご指摘いただけると幸いです。
対象仕様書
本記事ではW3C DID Working Group及びDecentralized Identity Foundationが策定しているDID関連仕様を俯瞰します。各仕様書にはそれぞれのWGのホームページからアクセス可能です。
全体俯瞰図
ここに上げた以外にも様々な仕様が活発に議論・策定されています。
優先度 ★★★★★
DID関連でまず最初に理解するべき概念は下記の2つです。
- Decentralized Identifiers (分散型識別子、DIDs)
- Verifiable Credentials (検証可能なクレデンシャル)
とりあえずこの2つの定義から読み進めて行きましょう！以下の仕様がこれらを定義しています。
Decentralized Identifiers (DIDs)
自己主権型・分散型の識別子(Identifier)であるDIDを定義します。
自己主権型とはすなわち個人が自分のIDを自分自身で管理するということです。IDの発行・更新・無効化といった操作はすべて自分の手元で行います。どこかのサービス事業者が預かって一元管理する、というようなことはしません。
DIDは下記の3パートで構成されるURI文字列です。
ところで、WebのURIはDNSによって何らかのリソースに名前解決されます。DIDも同様に、DID Documentという構造化ドキュメントに名前解決されます。DID DocumentにはDID自体・認証用公開鍵・DID主体との対話手段(=サービスエンドポイント)といった情報が記述されており、そのDID主体とどのようにコミュニケーションをすればよいかという説明書になっています。
- 相手に自分のDIDを伝える
- そのDIDのDocumentを相手に名前解決してもらう
というステップを踏んで初めて、DIDに基づいたコミュニケーションが可能となるわけですね。
DIDからDID Documentを名前解決する手段はDID Methodと呼ばれます。DID文字列の2パート目が「どのDID Methodで名前解決するか」という指示になっています。DID Methodの実装は
- 分散型台帳技術(DLT)をバックエンドとした分散システムにDocumentを格納しておく (ION, Sovrinなど多数)
- Web上にDocumentを配置して、そのWeb URIを一定の法則に従ってDID文字列に変換する(did:web)
- DID Documentを2者間で私的に共有し、お互いにだけ分かる状態にする(did:peer)
など様々で、現在多くのDID Methodが活発に議論・策定されています。
✔ キーワード
- DID (Decentralized Identifier) ... 自己主権型・分散型識別子
- DID Document ... DIDの性質を記述する構造化ドキュメント
- DID Method ... DIDからDID Documentを引く名前解決方法
Verifiable Credentials Data Model
Verifiable Credentials(検証可能なクレデンシャル)を定義します。
ここで言うクレデンシャルとは「対象が特定の性質を持つことを証明する情報」のことで、運転免許証や大学の学位などの資格を証明するもの、社員証・学生証などの所属を表すもの、優勝トロフィーや賞状など過去の実績を表すもの、果ては領収書やスタンプカードのような行動証明まで様々です。
例に上げたような物理クレデンシャルには、それが本物か(信頼できる機関が確かに発行したものか)を本気で確かめるには発行元に問い合わせるしか無い、という問題があります。これは手続き的に手間であるだけでなく、発行元によってユーザ行動がトラッキングされてしまうというプライバシーリスクが存在します。
Verifiable Credentials(検証可能なクレデンシャル)はこの問題を解決するために設計されたデジタルクレデンシャルです。デジタル署名によって発行者・記述内容を暗号論的に検証可能なため、発行元への問い合わせが必要ありません。また、クレデンシャルに記載された発行者を信頼するかどうかは検証者側で決定するため、個人が自分で署名したニセクレデンシャル等にも対処できます。
発行者の署名検証用の公開鍵だけはクレデンシャルの外部から取得する必要があるのですが、発行者がDIDで記載されていれば、DID Documentに記載された公開鍵情報を利用することができます。これがVerifiable CerdentialsとDIDが並列に語られる所以です。
✔ キーワード
- Verifiable Credentials …… 第三者が検証可能なデジタルクレデンシャル
- Verifiable Presentations …… VCを提示用に加工したもので、これ自体も検証可能。主な用途は「複数VCを一纏めにし提示しやすくする」「渡す情報を最小限に絞るためVC内の情報を一部秘匿する」など。
優先度 ★★★★☆
DIDの基礎を理解したら次はイメージ固めです。具体的なユースケース例や策定中の汎用通信プロトコルなどを読みながらメンタルモデルを作っていきましょう。
Use Cases and Requirements for Decentralized Identifiers
DIDの解説記事は結構出てきているのですが、日本語記事となるとまだまだ数は少なく、また取り上げられるユースケースもDIDというよりVerifiable Credentialsのユースケースである事が多い印象です。でもそれだけじゃないんだ、DIDのポテンシャルはもっともっとすごいんだ……という熱意を感じられるのがこの仕様書です。
本仕様書ではDID利用のユースケースが複数例示されるとともに、それぞれのユースケースで必要とされるDIDの性質もまとめられています。DIDベースのサービスを検討するなら一度読んでみましょう。
Introduction of DIDAuth
W3Cのドラフトではないのですが、よくまとまっている文書なので紹介します。DIDを用いた認証の方法について、様々なアーキテクチャを提案しています。
DIDを用いた認証(DIDAuth)は、Decentralized Identifiersの仕様では「DID Documentに書かれた公開鍵でチャレンジ＆レスポンスする」とだけ書かれており、具体的なプロトコルは言及されていません。既存のシステム・通信路に依存しないように定義したいというW3Cの姿勢もわかるのですが、これでは使う側としては困ってしまいます。
本文書はチャレンジ・レスポンスの具体的なデータフォーマットを定義し、様々な対話アーキテクチャを提案しています。これらはWebページ-Webブラウザ間であったり、Webページ-スマホアプリ間であったり、あるいは2つのスマホの間だったりと様々な通信路を想定しており、DIDAuthのイメージ固めを助けてくれます。
DIDComm Messaging
DIDを宛先とした非同期単方向メッセージングプロトコル、DIDCommの仕様書です。
DIDは各々勝手に発行するものなのに、どうやってメッセージをDIDの持ち主まで到達させるのか？というとサービスエンドポイントという仕組みを使います。サービスエンドポイントとはDIDの持ち主とコミュニケーションをするためのエンドポイント(URI)で、DID Document内にユーザが任意で記述することができます。DIDCommはサービスエンドポイント種別の一つとして定義されており、そのURIに所定のフォーマットのメッセージを送ることでDIDの持ち主まで配送される、というものです。
DIDCommは具体的な配送路は全く規定しておらず、むしろ「配送路は何でもいい」と明言しています。HTTPでもメールでも郵送でも伝書鳩でもいいし、途中に中継者が何人いてもいい。最終的にユーザまで到達しさえすればそれで……というわけです。ただしそのトレードオフとして、メッセージが相手に届いたことを送信者側が確認することはできません(非同期)し、復路の存在は保証されません(単方向)。
DIDCommは自由度・拡張性がかなり高く、単なるメッセージングサービスというよりはDID-baseの通信インフラ層というべき代物です。これの上に更に様々なアプリケーション固有のプロトコルが乗る、という実装になると予想しています。
Peer DID Method Specification
各DID Methodの仕様書はDIDを勉強する上であまり優先度が高くないのですが、Peer DID Methodだけは他と毛色がかなり違うのでこの優先度を付けました。
Peer DIDは、簡単に言えば「対話する2者間だけで共有するDID」です。アリスがボブとDIDCommで個人的な会話をしたい、としましょう。このとき、アリスとボブはお互いのDID(とDID Document)を知っている必要がありますが、他の人にそのDIDを公開する必要は全くありません。DIDCommのサービスエンドポイントはDID Documentに記載されているので、二者でDID Documentを共有し合えば完結するからです。
Peer DID Methodはこの「2者間(あるいはn-者間)でのDID Document共有」の仕方を規定し、Private DIDを実現するためのDID Methodです。全体公開を必要としないためセキュアではありますが、共有したDIDを格納するパーソナルストレージが必要だったりと他のDID Methodと比べて特殊な点も多くあります。
✔ ポイント
- DID Documentは対話する2者間(あるいはn-者間)だけで共有され、余人には公開されない。
- DID Documentの変更履歴がDID Document自身に内包される(Backing Storage)。履歴は「差分(delta)」と「変更者の署名(proof)」で表現され、過去バージョンまで遡って検証可能。
- ユースケースによってはPeer DIDをPublicなDIDに昇格させたい場合がある。その場合でも、DID・DID Documentに簡単な変換を施すことで、もとのPeer DIDとの整合性を保ったまま全体公開系DID Methodに移植することができる(grafting)。
優先度 ★★★☆☆
ここから先はより具体的な仕様になっていきます。実際のサービス設計や実装のフェーズになってから読むのでも構わないと思います。
Sidetree
DLT(Decentralized Ledger Technology、分散型台帳技術)はDIDの非中央集権的な要請と相性が良いため、現在様々なDLTをベースとしたDID Methodが提案されています。これらDLT-base DID Methodの共通インタフェースを規定するのがSideTreeです。
SideTreeに則ったDID Methodはすべて同じインタフェースで利用できるため、利用者側の開発負担を減らすことができます。とはいえ、実際のところは後述するUniversal Resolver / Universal Registrarを使うことが多いと思います。DID Methodを自分で実装したいという人は読んでおきましょう。
DID Specification Registries
DID Documentの詳細仕様を知りたい場合はここを参照しましょう。DID-Core (Decentralized Identifiers)やその他周辺仕様で定義されたパラメータがこの文書にまとめられています。
また、後ろの方に「現在知られているDID Method一覧」が掲載されています。各Method仕様書へのリンクやそれぞれのバックエンドシステム等がまとめられているので、一度眺めてみると良いと思います。殆どはDLT-baseですが一部変わり種があったりして面白いです(did:gitとか)。
DID Method Rubric
DID Methodは本当にたくさんあるので、どのMethodを使えば良いのかわからなくなりそうです。DID Method Rubricは各DID Methodをどのような観点で評価すればよいのかという指針を与える仕様書です。
本仕様書ではDID Methodの評価する上での様々な評価軸を定義するとともに、いくつかのDID Methodについて評価例を上げています。注意点として、本仕様書はあくまで評価軸を定義するのであって、評価自体は自分でする必要があります。とはいえ、迷ったときには一度読んでおくとよいかと思います。
Universal Resolver / Universal Registrar
仕様というより実装のリポジトリですが頻出なのでこちらに。各種DID Methodに対応した名前解決/DID登録のファサードです。
どちらもDockerイメージが提供されており、立ち上げてcurl等でREST APIを叩けば機能します。またドライバー形式を採用しており、各DID Methodに対応したドライバーを組み込むことで対応Methodを拡張することができます。
２つのうち特に有用なのはResolverのほうです。というのも、対話相手がどのDID Methodを使うのか、というのは対話相手が(勝手に)決めることだからです。どんなDIDにも対応できるようにしたい、となればUniversal Resolverは有用になります。
逆にRegistrarのほうは重要性が一段下がるのかな？と思います。これも理由は同じで、自分がどのDID Methodを使うかは自分で(勝手に)決められるので、複数対応する動機が少し薄くなるからです。
優先度 ★★☆☆☆
個人的にあんまり優先度高くないな……という分類のものです(自分が理解しきれていないとも言う)。ツッコミ・マサカリお待ちしています。
Confidential Storage
分散型暗号化ストレージの仕様で、DIFのSecure Data Storage Working Groupが策定しています。
従来のストレージサービスは、格納されているデータをストレージ管理者に見られてしまう可能性が有ります。これはディスク暗号化のようなストレージ単位の暗号化がなされていても同じで、どうやって管理者を信頼するのかという問題が有りました。
Confidential Storageでは、すべてのデータはそのデータの所有者自身によって暗号化されます。実際にデータを格納する物理ストレージ(及びその管理者)からはデータを複合できなくなるため、セキュリティレベルの向上が見込めます。DID/VC的な観点では、DID Documentに書けない個人情報やDAppの個人データ、他社に発行してもらったVCなどをここに格納することが想定されているようです。
現時点でUnofficial Draftだったり抜けている項目が多かったりするため優先度は低くしましたが、今後の発展に注目しています。
Well Known DID Configuration
OIDCの.well-known/openid-configurationのようなものです。.well-known/did-configurationに配置するJSONドキュメントで、そのWebサービスが使う(Public) DID等を記述します。
一応言っておくと、このドキュメント自体の真正性は暗号論ではなくサービス主体のドメイン管理能力に依拠しているため、例えば過去に不正アクセスされたことがある……というようなことがあるとドキュメントの信頼性が揺らぐ可能性があります。
KERI
KERIはKey Event Receipt Infrastructureの略で、キーに関するイベントの検証可能なログを提供します。
「キーに関するイベント」とは鍵ペアの作成/ローテーション/署名のことを指すようで、要するにキーローテーションが本当に正当なものかを検証可能にするための仕組み……だと個人的に理解しています。DIDのキーローテーションに関わってきそうです。
……正直まだあまり勉強できていない範囲のため、この優先度を付けています。めちゃくちゃ重要だよ！等のご意見有りましたらコメント等でご指摘いただけると幸いです。
優先度 ★☆☆☆☆
今は一旦置いといて良さそうなもの。
Self-Issued OpenID Connect Provider DID Profile
DIDAuthをOIDCのSIOPで実現するための仕様……だったのですが、先月DIFからOIDC AB WGにプロジェクトが移管されたようです。現在は破壊的変更を含むv0.2を策定中らしいので、参考程度に留めるのが良さそうです。
まとめ
DID界隈はまだ仕様の議論が続いているという状況もあり、追いかけるのは大変だと実感しています。この記事が皆様のDID理解の一助となれれば幸いです。