did:webの課題をカバーするdid:websがパブリックレビューへ

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

みなさん大好きなdidメソッドの話です。

結局did:webが結構使われてるけどdid:webって既存のwebサイトの管理方法（DNSとかCA）に依存しちゃうので分散型じゃないよね、という課題（？）をカバーするためにdid:websっていうのをToIP（Trust Over IP） Foundationのdid:webs Method Task Forceで検討して仕様策定している、ということのようです。

ToIP Foundationからのアナウンス

https://trustoverip.org/news/2023/12/15/announcing-public-review-of-the-didwebs-method-specification/

個人的には結局インターネット上でDIDを使うユースケースに限っていえば既存のインターネットの仕組みであるDNSのレジストラやHTTPSのCA局のポリシーやガバナンスを信頼する必要があるはずなので、そこまで分散型に拘る必要性は感じない派なのですが・・・

did:webにおける課題

did:webに限らずdid全般において言えることですが、結局did、Decentralized Identifiersはつまるところ識別子なのでどうやってメソッド内の名前空間におけるユニークネスを担保するのかがポイントになります。ユニークネスを担保するためには多くの場合においてレジストリ（Trusted Data Registry）を構築し重複レコードがないことを管理することが必要となります。その際の登録〜管理プロセスを特定の管理主体（群）を通して行うモデルが従来のDNSやCA局などが取ってきたモデルです。一方で衆人環視の元、あらかじめ合意されたコンセンサスアルゴリズムに則ってレジストリへの登録〜管理を行うモデルがいわゆるブロックチェーンベースのレジストリ管理のモデルです。

一方でOpenID ConnectにおけるSIOPv1（v2と区別する意味であえてv1とつけます）における自己発行の証明書のThumbprintを識別子として用いる、つまり証明書のエントロピーに全振りし特定のレジストリを用いないモデルも存在します。

この辺りは上記のToIPからのアナウンスにも記載されていますが、整理するとdidメソッドにおける識別子の管理方法は、

1. 権威ある管理主体を利用する方式
2. ブロックチェーンを利用する方式
3. 自己発行の証明書を利用する方式

に分類されるわけです。

前述の通りdid:webはdid:web:example.jp:users:taroの様にドメイン名を識別子に利用する上にDID Documentを取得するレジストリ（did.json）の正当性についてはHTTPSを用いるので1番めの権威ある管理主体を利用する方式に該当します。

しかしながら前述の通り、Decentralized Identifierというからには分散している方が良いのである、という主張も存在するわけで2番めのブロックチェーンを利用する方式なども依然として利用されている状態にあります。

この様なカオスがdidメソッドの乱立を招いてしまっているわけで、本ポストを書いている時点で186個もメソッドが登録されいる状態にありますし、もちろんW3Cのdidレジストリに登録せずにプライベートでdidを利用しているシステムも多数存在している状態となっています。

話を戻すと、分散型の必要性を主張するシナリオに対応するためにdid:webを拡張するのが今回のToIPのタスクフォースの対応だということになります。

did:websにおける対応

では、具体的にどの様な対応をしているのかを見ていきましょう。非常に単純です。

要するに従来のdid:webのDNS名前空間はそのまま利用し、最後に3番めの自己発行の識別子をくっつけることで対応しようという試みです。こんな感じの識別子ですね。

did:webs:example.jp:users（ここまではdid:web）:xxxxxxxx（自己発行の識別子）

この最後の自己発行識別子の部分については既にToIP FoundationのACDC（Authenticated Chained Data Container） Task Forceで議論しているので、こちらを使おうという話の様です。いわゆるGLEIFがvLEIで採用しているKERI（Key Event Receipt Infrastructure）の話ですね。この辺りはIIW（Internet Identity Workshop）でも毎回活発に議論されています。

私もACDCやKERIについてはあまり知らないのでこれ以上は突っ込みませんが、did:web+ACDC=did:websって考えておけば良いのかな、、というぐらいの理解です。

まぁ、冷静に考えると結局のところDNSやHTTPSへの依存は一定以上残るわけなので、そこまで分散型に拘るなら素直にブロックチェーンベースのdidメソッドを使えば良いのでは？と思いましたが。。いずれにしてもユースケース次第ですね（という逃げ口上）。