分散型アイデンティファイアー (DIDs: Decentralized Identifiers) （後編）
【概要】分散型アイデンティファイアー（中編）ではW3C勧告のDecentralized Identifiers (DIDs) Core Specification v1.0が定める分散型アイデンティファイアー(DIDs: Decentralized Identifiers)を実現するための技術的課題と解決方法について説明しました。(後編)ではHyperledger Indyを例に、DID生成の具体例を見ることで更に理解を深め、併せてDID普及の課題についても考えたいと思います。
*************** 目次 ****************
【10】Hyperledger IndyによるDIDの生成
【11】DIDドキュメント
【12】CPKIとDPKIの比較考察
【13】W3C DIDs Core Specification の今後
*************************************
【10】Hyperledger IndyによるDIDの生成
前回の記事でPKIの3つのバインディング問題は、公開鍵からDIDを生成することで第三者に依存せずに解決できることを説明しました。
① コントローラとアイデンティファイアー
② アイデンティファイアーと公開鍵
③ 公開鍵と秘密鍵
公開鍵からDIDを生成するアルゴリズムはDIDメソッドとして仕様が定められており、DID Specification Registries ( https://www.w3.org/TR/did-spec-registries/ )には本稿執筆時点で169のDIDメソッドが登録されています。その中からHyperledger Indy( https://hyperledger.github.io/indy-did-method/ )のDIDメソッドを例に実際にDIDを作成してみましょう。Indy DID methodはDIDの形式を以下のように定めています。
did:indy:{namespace identifier}
ここで{namespace identifier}= BASE58(Truncate_msb(16(SHA256(publicKey))))と決められています。つまり公開鍵のハッシュ値をSHA256で求め、その上位16バイトを取り出してBASE58でエンコードしてdid:indy:に続けるとDIDが作成できます。
Indy DID method に従って私のMacBookでDIDを作成してみました。
先ず秘密鍵・公開鍵の生成ですが、Macを含むUnix系システムではssh-keygenコマンドでランダムに鍵を生成できます。
% cd ~
% mkdir .ssh
% ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/akishiseki/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/akishiseki/.ssh/id_rsa
Your public key has been saved in /Users/akishiseki/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:KsI7wQNz60TS350cMiASQ22A2zTausrw/684Lrquw7c
秘密鍵はid_rsa、公開鍵はid_rsa.pubに出力されます。公開鍵の中身はこんな感じです。
% cat .ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDZ/uE76/6tJX5raFxGW/2WUF5ILW0clSjhJcEaw6LXKD9Mqq2H7Pr8kuQqbv9cIDtbeZPw0GL9MwBTdc7mgnzz5dubdSg/dvcKb2HtaTA6K7gMwhf7I+OFme7eQQ4IMLWn+HT5fKU/pibiO86VNQCuNYAXz3zjINj9JXAQEQu4EhFAfxmpJDxCN2PBip1lUmo3PMjWJ21Xp+00Xxe30Z67QaT8Rq4XyoHO3i3+M+8vjcucleMu72yEW9t3JONndM90mp8fhZ7pJmcsSMq8AHaSuFvRiFu7KmI2lEJAe/oMOfGIL1E81gTwGATsvZC7LC4DI09R8Q1y9yzFv4Ot2nYqYInPzTamQcHMsQK6YYdhEJt41FdLq50lWiFmGJi7omRr7ABFq8y35T9EPKX35Ee3UDOm2OJD4z19PVgrIuxQmbcLkMjVsE1PnPKQUqDrwhJbjy2PBrz2vfjDFoikp1ZKsdiToi7aa5Bmhno3U8dYx3vUwClWgICpyuojsKmMqjE= akishiseki@ShisekiAkimitsu-MacBook-Air.local
公開鍵からSHA256 (Secure Hash Algorithm 256)でハッシュ値を求めます。SHA256はネット上に公開されているツールを利用しました。
A0D009D24B6D54A26937D6699265318F63F22496EB0E9BDC4B6265F9A22B4E31
ハッシュ値の上16バイトをBASE58でエンコードします。BASE58もネット上に公開されているツールを利用しました。
5PUBsJnaC5hyoh5D2CXVZKnp7b1P3fQ7L4rGeqMvd6WH
Indy DIDのフォーマットに当てはめればDIDの完成です。
did:indy:5PUBsJnaC5hyoh5D2CXVZKnp7b1P3fQ7L4rGeqMvd6WH
以上の手順をssh-keygenからもう一度繰り返してみます。ssh-keygenが内部で乱数を発生しているため、毎回異なる秘密鍵・公開鍵が生成さることに注意してください。
% mkdir .ssh2
% ssh-keygen
今回は .ssh2/に秘密鍵・公開鍵をアウトプットします。
% cat .ssh2/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDXIjFYtvUbDuI1ofNYUTgpeRjvwNidkFz8mMFJEsCtz7bIKP8iG4orW+Fio0ilWP+YdF8IaWeTXLO+hVkyzE6ckPOQYg9GL6KHNa3BwBYVtewKp3xHdEG5Jl/oNxC6vWTpqmSjnGuKMCDgVsbrKtgzkR2nF1aTT8cw1Z8Rhd0vH2PAOIIp2gYXXjE5T8XG0uuFpbJi18C57uJ+sYWo4v0vRHn8NkN21+3mdptpRY4RPux7El1QCgXkq1JwLHRQcZcnSBACDwNxCpSiK8531Re1caA3D16AnIf8lakZJYE13KlHwMKS3szV9rz8F90sLpjMXi6V3yh0PWNeyyys+9gj+ldMJgzPg8rO3YQO5WqREzZ8N4FUMlfOm4t6WNCWd2ZSo20FJ/FhYuMfZxyVjkLQPynePSgQjrrfKy79JjlIGzwMZQdcUcZdXDzbPZSm3P+LG50VTvsEWoq2PBKo9zhcpfBa1cUAHW36VC0dKVjuC8bBnwIArE23C2WtVETRaJE= akishiseki@ShisekiAkimitsu-MacBook-Air.local
公開鍵からSHA256 (Secure Hash Algorithm 256)でハッシュ値を求めます。
F4575FA2BAB0D0418D21D001D260CEB534798F13882B97FF534A66E5703AF898
ハッシュ値の上16バイトをBASE58でエンコードします。
5j3iHLF1uJqLCCK5fnS9q1nVHXjEnSDZN1t9wrSTvWFn
DIDのフォーマットに当てはめDIDを作成します。
did:indy:5j3iHLF1uJqLCCK5fnS9q1nVHXjEnSDZN1t9wrSTvWFn
以上により２つのDIDを簡単に作成することが出来ました。
did:indy:5PUBsJnaC5hyoh5D2CXVZKnp7b1P3fQ7L4rGeqMvd6WH
did:indy:5j3iHLF1uJqLCCK5fnS9q1nVHXjEnSDZN1t9wrSTvWFn
それぞれに対応する公開鍵を公開し（もしくは通信する特定の相手だけに知らせ）、秘密鍵を秘密に管理することで私は２つのDIDを第三者に依存することなく作成できました。これらのDIDと公開鍵が結び付いていることは今ここで行ったのと同じ手順を踏めば誰でも検証することができます。つまりこれらのDIDと公開鍵は対応する秘密鍵を持つ私のDIDと公開鍵であることが誰でも瞬時に確認できることになります。
【11】DIDドキュメント
本項の前編でToIPレイヤー１のアイデンティファイアーに求められる要件を4つ挙げました。
1. 中央集権的な発行機関が存在しない
2. 永続的であり、それを支える組織の継続的運用を必要としない
3. 持ち主を暗号学的に証明できる
4. 対象(subject)に関するメタデータをリゾルブできる
ここまで1.〜3.について見てきましたので、最後に残った4.についてこれから解説します。
このメタデータとは、具体的にはアイデンティファイアーにバインドされた公開鍵やDIDサブジェクト（DIDが指す対象）にアクセスするためのサービスエンドポイントなどの公開情報のことです。それらはDIDドキュメントとして記述され検証可能なデータレジストリ（VDR: Verifiable Data Registry）に記録されます。DIDからDIDドキュメントを得ることをリゾルブする (resolve)と言い、それを行うソフトウエアをリゾルバーと呼びます。DID、リゾルバー、DIDドキュメントの関係は、URL、Webブラウザー、Webページ(リソース)の関係と似ています。ユーザーは、DIDを、そのDIDメソッドに対応したリゾルバーに入力することでDIDドキュメントを得て、その内容から公開鍵やサービスエンドポイントを知ることが出来ます。
ユーザーはDID URLをリゾルバーに入力してDIDドキュメントから特定の情報をピンポイントで得ることも出来ます。URLなのでDIDにパス、クエリーパラメータ、フラグメント等を付加して必要な情報だけ（例えば公開鍵だけ）を指定して得る(dereference)ことが出来ます。
次にDIDドキュメントの内容を見てみましょう。システム内のデータモデルであるDIDドキュメントは、様々な方法でシリアライズして表記 (represent)することが可能です。W3C DIDs v1.0 ではJSONおよびJSON-LDによる表記を定めていますが、XML、YAMLなどを利用することも可能です。以下にJSON-LDによる表記例を示します。
JSON-LDはJSONの拡張フォーマットで、@context文でスキーマを読み込んで以下に続く構造化データの語彙を柔軟に定めることが出来ます。上記のDIDドキュメントは4つのパートから出来ています。
① @context:
② “id”:
③ “authentication”:
④ “service”:
①“@context”では２つのスキーマを読み込んでいます。一つはDIDに共通のもの、もう一つは暗号に関するものです。Ed25519はエドワーズ曲線デジタル署名を意味し、25519は素数(2**255)–19を使っていることに由来しています。
②“id”は、このDIDドキュメントの対象 (subject)がdid:example:123であることを示しています。
③ “authentication”は、このDIDにバインドされた公開鍵を示しています。より正確に述べると、”authentication:”に続く配列[]内のオブジェクトとして複数のverification methodを指定することが出来ます。その指定方法はこの例のように{}内にverification methodを直接埋め込むembedded方式と、”verification method”プロパティで別途定義したものを配列の要素として{}で囲まずに参照するreferenced方式があります。そしてこの”authentication”プロパティはverification relationshipと呼ばれ、DID subjectに対してどのような目的でverification methodが使われるかを表します。方法(verification method)と用途(verification relationship)を分けて指定出来るのです。verification relationshipには以下のようなものがあります。
- authentication: DID subjectやDID controllerの認証に使う
- assertionMethod：検証可能な資格情報 (VC: Verifiable Credential)の検証に使う
- keyAgreement：DID subjectへ暗号文を送る時、復号鍵をこの公開鍵でラッピングする
- capabilityInvocation：DID subjectがprotected HTTP APIのアクセスやDIDドキュメントの更新をする時、それ(capability)が認可されていることを証明する
④ “service”は、DID subjectや関連するエンテイティとコミュニケーションする方法を示しています。DID subjectが公開したいサービスには以下のようなものがあります。
- ネゴシエーション・エンドポイント：DID subjectとコミュニケーションを確立するために使う。ネゴシエーションの結果、コミュニケーションチャネルが作られ、それにアクセスするための証明書が得られる。
- メディエータ・エンドポイント：共用のプロキシーのサービスエンドポイントで、相手ごとに別のエンドポイントが不要なためコリレーションのリスクを回避できる。
- 機密ストレージ：DIDドキュメントに機密情報を直接入れることは、特にDIDドキュメントが変更不可能な (immutable) VDRに公開される場合、避ける必要がある。外部のリソースサービスを指定することで権限チェックや情報の削除ができるようになる。
DIDドキュメントは、DID subjectの通信相手がコミュニケーションチャネルを作成し、提示された証明書 (VC: Verifiable Credential/VP: Verifiable Presentation)の真正性を確認するために必要な情報を公開するための仕組みです。従ってこの中にプライバシーや機密に関する情報を入れることは推奨されません。
また集団プライバシー(Herd Privacy)、つまり当該DID subjectが集団の中の他者と区別がつかない状態を確保するための注意も必要です。例えば一つのDIDドキュメント内で複数のサービスエンドポイントを指定するとそれらの記述内容を突き合わせることでプライバシーリスクが高まることがあります。
また特定の相手とのコミュニケーションにだけ使われるDID (pairwise DID)のサービスエンドポイントは、専用のものを使うとトラフィックを分離・分析され易いため多くの相手のDIDと共通のものを使うことが推奨されています。
【12】CPKIとDPKIの比較考察
従来型PKI (CPKI: Conventional PKI)ではURLに代表される既存アイデンティファイアーの管理者およびその所属組織の存在を認証局が確認し、アイデンティファイアーと公開鍵の結び付きを認証局の署名付き証明書によって保証しました。
一方、分散型PKI (DPKI: Decentralized PKI)ではDIDコントローラが公開鍵・秘密鍵ペアを自分のウォレットで生成し、公開鍵から生成したアイデンティファイアーと公開鍵をDIDドキュメントとして公開することでコントローラ、アイデンティファイアー、公開鍵の結び付きを保証します。
CPKIでは管理者や組織の存在確認を認証局が人手で行うため時間とコストが掛かりますが、証明書にはアイデンティファイアーに加えて組織名、所在地が入り、これだけで組織の存在証明書になります。DPKIはコントローラ、アイデンティファイアー、公開鍵の結び付きを証明しますが、アイデンティファイアーが指すsubjectの身元を証明するには、DIDドキュメントにCPKIで存在が保証されているURL (Well-known URL)を含め、公開鍵をそのURLから得る、あるいは証明可能な資格証明書(VC)として第三者に別途発行してもらうなどする必要があります。つまりCPKIではアイデンティファイアーとアイデンティティが一体として扱われ、DPKIでは基本的にはアイデンティファイアーと鍵の生成およびバインディングのみを扱い、アイデンティティの保証は第三者に委ねています。
アイデンティファイアーと鍵のバインディイング、組織の存在証明をセットにしたCPKIは企業のサーバーのURLなどの真正性証明に広く利用されています。一方発行対象(subject)が個人やIoTデバイスのように数が多く、アイデンティティも存在証明だけでなく多岐に渡る（出生証明、学歴証明、資格証明、品質証明、製造証明、等々）場合はアイデンティファイアーとアイデンティティが切り離され低コストのDPKIが適しています。例えば個人の場合、自分でDIDを発行し、行政から本人確認の証明書(VC)をそのDID宛に受け取り、以降はインターネット上でそのDIDから本人確認VCを提示することで様々なエンティティから追加のVC（大学から卒業証明書、所属企業から社員証明書、金融機関から口座証明書、等々）をそのDID宛に受け取ることができます。そしてDIDと蓄積したVCにより様々なサービスをインターネット上で利用することが可能になります。ここでDIDとVCはその個人が所有していて、本人が望む限りDIDは永久に利用でき、またサービスを利用する際にどのVCからどの情報を提示するか（選択的開示: selective disclosure)も個人の裁量で行えることが自己主権型アイデンティティの特徴になります。
【13】W3C DIDs Core Specification の今後
Decentralized Identifiers (DIDs) Core Specification v1.0がW3Cから標準として発表されたのは2022年7月です。Verifiable Credential Data Model v1.0の発表が2019年11月ですから3年近く後に標準化されたことになります。DIDとVCは異なる概念の標準であり一方が他方を前提としていませんが、どちらも自己主権型アイデンティティを可能にする基盤を提供します。
DIDはW3C Decentralized Identifier Working Groupで2019年から仕様が検討されてきました。標準化前から業界の期待は高く、ドラフト版の仕様がVCの実装の中で使われることも多くありました。しかしながら、3年の歳月とW3Cメンバーのレビューを経て作成された仕様は標準化の最終段階で、世界の4大ブラウザーベンダーのうちマイクロソフト社を除く3社のW3Cメンバーから承認反対に合いました。その反対理由は以下のとおりです。
1. DID 1.0はDID全般を標準化しているが、特定のDIDメソッドを標準化していない。
2. DID 1.0はDIDメソッドの発散を促し、DIDメソッドの収束を意図していない。
3. DID 1.0は中央集権的なDIDメソッドを禁止していない。
4. DID 1.0は地球環境に問題があるブロックチェーン（Proof of Workを指している)の利用を推進する。
これらの反対意見に共通するのは「DID 1.0は分散アイデンティファイアーの枠組みを標準化しているが具体的なDIDメソッドを規定していないので実装間の相互運用性が確保できない」と言うことです。反対意見も枠組みの標準化の価値は認めていますが、DIDメソッドの標準化も同時に行うべきであると主張しています。
DID Working GroupにはDID Core Specを作成するに当たって2つの選択肢がありました。つまり ①枠組み（DIDの文法と仕組み）の標準化を先に行いDIDメソッドの標準化は後日行う、②DIDメソッドの標準化も併せて行いそれが完成するまで枠組みの標準化は遅らせる、であり、WGは確信的に前者を選んだのです。WGの狙いは次の要件に応えるアイデンティファイアーのクラスを定義し得るCore Specを標準化することでした：
· アイデンティファイアーを発行する中央集権的な機関が存在しない
· アイデンティファイアーはそれ自体永続的で、それを支える機関の継続的運営を必要としない
· （管理者は）アイデンティファイアーを管理していることを暗号学的に証明できる
· （参照者は）アイデンティファイアーに関するメタデータを取得できる
つまりCore Specで標準化されたアイデンティファイアーの文法や仕組みはこれらの要件を満たすアイデンティファイアーの拡張可能なクラスを定義することが目的であり、この標準に準拠するアイデンティファイアーが多数開発されたり、これら要件のいくつかを満たさないアイデンティファイアーが実装されたりすることすら問題にしていないのです。最初から実装の幅を狭めることはせず、この標準に沿って４つの要件を満たすのは実装者に任せ、それに対する評価はコミュニティとマーケットに委ねているのです。
DIDが使われるユースケースの幅は広く、それぞれの用途にあったアイデンティファイアーの開発を市場に委ねるのはW3Cらしい考え方と思います。DIDメソッドの種類は一旦増加し、やがて市場に淘汰されて収束に向かうと期待されます。それに合わせてW3C DID WGはDIDメソッドの標準化を追加していくと表明しています。
最後までお読み頂きありがとうございます。記事へのご意見やご質問などがございましたらお気軽に下記までご連絡ください。
info@kaula-lab.com
カウラ株式会社HP: kaula.jp
関連記事
· Web3.0におけるアイデンティティレイヤー（前編）https://medium.com/kaula-lab/web3-0-identity-layer-89494f479c14
· Web3.0におけるアイデンティティレイヤー（後編）https://medium.com/kaula-lab/web3-0-identity-layer-2-4632344ec069
· 分散型アイデンティファイヤー (DIDs: Decentralized Identifiers)（前編）https://medium.com/kaula-lab/%E8%A8%98%E4%BA%8B%EF%BC%93-%E5%88%86%E6%95%A3%E5%9E%8B%E3%82%A2%E3%82%A4%E3%83%87%E3%83%B3%E3%83%86%E3%82%A3%E3%83%95%E3%82%A1%E3%82%A4%E3%83%A4%E3%83%BC-dids-decentralized-identifiers-%E5%89%8D%E7%B7%A8-9f4f6421bd01
· 分散型アイデンティファイヤー (DIDs: Decentralized Identifiers)（中編）· https://medium.com/kaula-lab/%E5%88%86%E6%95%A3%E5%9E%8B%E3%82%A2%E3%82%A4%E3%83%87%E3%83%B3%E3%83%86%E3%82%A3%E3%83%95%E3%82%A1%E3%82%A4%E3%82%A2%E3%83%BC-dids-decentralized-identifiers-%E4%B8%AD%E7%B7%A8-fddbabd7eff1
