要約

  • W3Cの10月1日版には、ネットワーク越しにDID URLを参照解決する適合区分とHTTP(S)の例があった。24日版でこの区分とHTTP規定が消え、26日版にも反映された。
  • DID自体をHTTPSで解決する規定は残る。返された文書から目的の鍵や資源に進む処理は、クライアントの選択と実装に委ねられる。

荷物の追跡画面に「配達完了」と出ても、箱の中の鍵を取り出した人までは分からない。did:example:123#key-1 を扱うアプリにも、よく似た二段階がある。DID文書を受け取る段階と、その中の #key-1 を使う段階だ。

W3Cの10月1日版「DID Resolution」は、両段階をHTTP(S)の結び付けで扱い、ネットワーク型DID URL参照解決器の適合区分まで置いていた。24日版でその区分とHTTPの参照解決例が削除された。26日版の改訂履歴は、OpenAPI定義からも同じ機能を外したと記している。

窓口そのものは続く。現行草案はDIDの解決についてHTTPSの仕様を定め、適合する解決器にGETへの対応を求める。POSTは任意だ。窓口が返すのはDID文書と解決メタデータであり、異なるDID方式を扱うアプリに共通の入口を与える。

その先の仕事はURLの内容で変わる。草案の参照解決アルゴリズムでは、クライアントが利用者にDID方式ごとの解決器を選ばせ、応答を見て処理方法を決める。フラグメントは例示でもクライアント側が扱う。サービスを指すURLなら、該当するサービスと資源をたどる工程が加わる。文書を渡したサーバーには、アプリが最後にどの文脈で何を使うかまで決められない。

この線引きの種は春からあった。W3Cの課題306は、フラグメントの最終処理がクライアント側で起こる点を挙げる。10月15日の議事録では、抽象的なアルゴリズムをどう具体的な試験口に結び付けるかが議論された。運用側が確かめるべきものも二つになる。HTTPSの解決結果と、URL全体を処理した結果だ。

参照解決は候補勧告段階で「変更の可能性がある機能」として残っている。現時点の調達仕様や障害記録には、解決器の名前だけでなく、フラグメントやサービスを処理するクライアントの経路も書いておきたい。受付番号一つで配達後の開封まで説明するのは無理がある。