DID（Decentralized Identifier）は「分散型ID」と訳されることが多い。しかし、DIDは個人情報をブロックチェーンへ保存する仕組みでも、本人確認を自動化する仕組みでもない。本記事では、DIDの構造と解決できる課題を整理する。
1. 基礎概念
DIDは、中央のID発行事業者に依存せずに管理できる識別子である。形式は次のようになる。
did:example:123456789abcdefghi`did`はURI Scheme、`example`はDID Method、末尾はMethod固有の識別子である。DID Methodは、DIDの作成、解決、更新、無効化をどのように行うかを定義する。
DIDを解決すると、DID Documentを取得できる。DID Documentには主に次の情報を記録できる。
- 公開鍵などの検証手段
- 認証や署名に使う鍵との関係
- 通信先を示すService Endpoint
- DIDを管理するController
DID Documentに氏名や住所を直接記録する必要はない。DIDが示すのは、基本的には識別子と、その識別子を制御していることを暗号学的に検証するための情報である。
また、DIDを持っているだけでは、その人物が実在することや、特定の氏名・資格を持つことは証明されない。それらの属性を証明する役割は、Verifiable Credentialsなど別の仕組みが担う。
2. 技術フロー
DIDを使った署名検証を単純化すると、次のようになる。
DID Controller
│ 1. 鍵ペアを生成
│ 2. DIDとDID Documentを登録
▼
DID Method固有の基盤
▲
│ 3. VerifierがDIDを解決
│ 4. DID Documentを取得
Verifier
│ 5. 公開鍵を使って署名を検証
▼
検証結果DID Methodごとに、DID Documentの保存・解決方法は異なる。分散台帳を使うMethodもあれば、Webドメインや他の基盤を使うMethodもある。そのため、「DIDだから必ずブロックチェーンを使う」とは限らない。
運用では鍵のライフサイクルが重要になる。秘密鍵が漏えいした場合に検証鍵を更新できるか、古い鍵で作られた署名をどう扱うか、Controllerを変更できるかをMethodの仕様とシステム要件に沿って決める必要がある。
3. 何を解決できる技術か
従来のサービスIDは、特定の事業者のデータベース内でのみ意味を持つ。事業者がサービスを終了したりアカウントを削除したりすると、その識別子を利用できなくなる。
DIDは、識別子の制御と特定事業者のアカウント管理を分離し、異なるシステム間で同じ主体を暗号学的に参照する基盤を提供できる。これにより、組織をまたぐ証明書の利用や、特定のIdentity Providerへ依存しない署名検証が可能になる。
ただし、DIDだけで信頼関係は完成しない。Verifierは、DID Methodの信頼性、鍵管理、DID Documentの取得可能性、相手と現実世界の主体との結び付きを別途評価する必要がある。相関可能なDIDを複数サービスで使い回せば、行動追跡の手掛かりにもなる。
DIDが解決する中心的な問題は、「誰かの属性を証明すること」ではなく、「特定事業者に閉じない識別子と検証鍵の管理」である。
DIDを運用するための補足
DID Subjectは人間に限らず、組織、端末、ソフトウェア、製品にもなり得る。DID ControllerはDocumentを変更できる主体であり、Subjectと同一とは限らない。
Verification Methodには公開鍵の種類、鍵データ、Controllerが含まれる。さらに、その鍵をAuthentication、Assertion Method、Key Agreementなど、どの目的に使えるかをVerification Relationshipで指定する。鍵が存在しても、許可された目的と異なる用途へ使うべきではない。
Service Endpointは通信先や関連サービスを表現できる。しかし、公開Documentへ個人と結び付くEndpointを置けば、追跡や攻撃の手掛かりになる。仕様上記載できることと、プライバシー上記載すべきことは別である。
「Decentralized」は中央管理者が一切存在しないという意味ではない。実際の分散性はMethod、台帳運営、Resolver、鍵保管、ガバナンスによって異なる。
ResolverはDIDを受け取り、Methodの規則に従ってDocumentと解決メタデータを返す。構文、Methodの対応状況、Documentの状態、取得結果の真正性を確認する。共通Resolverを使っても各Methodの信頼モデルの差は消えない。
`did:web`はDNSとHTTPSを利用してDocumentを公開するため導入しやすいが、ドメイン管理と認証局へ依存する。分散台帳型Methodは複数参加者による状態共有を実現できる一方、費用、性能、公開情報の永続性、運営ルールが課題になる。Methodは理念ではなく要件から選択する。
鍵ローテーションでは新しいVerification Methodを追加し、移行後に古い鍵を無効化する。過去署名を後から検証するなら、履歴、署名時刻、署名時点の鍵状態も必要になる。Deactivationも単なる削除ではなく、現在は無効であることを記録する処理である。
DIDは鍵を交換しても識別子を維持できる余地を持つ。主体は長期間存続するが、鍵は漏えい、端末交換、アルゴリズム更新で変更されるからである。
一方、DIDの制御証明は秘密鍵の制御証明であり、自然人としての本人性を直接証明しない。端末認証、鍵保護、失効、リカバリー、属性証明が別途必要になる。同じDIDを使い回すと行動を関連付けられるため、Pairwise DIDも選択肢になるが、管理は複雑になる。
DID Methodを評価する観点
DID Methodを選ぶときは、作成速度や手数料だけでなく、誰が状態変更を承認するかを確認する。台帳への書き込み権限が少数組織へ集中していれば、技術的に分散台帳を使っていてもガバナンスは中央集権的になり得る。反対に、変更を誰にも止められない構成では誤登録への対応が難しくなる。
可用性も重要である。VerifierがDocumentを解決できなければ署名を検証できない。Resolver障害やMethod終了を想定し、Cacheの期間、古いDocumentを許容する条件、代替Resolverを決める。ただし、長期Cacheは鍵更新やDeactivationの反映を遅らせる。
暗号方式の更新可能性も評価する。Documentが複数方式の鍵を持てるか、新方式へ移行できるか、利用側が対応アルゴリズムを制限できるかを確認する。Resolverが返した未知または弱い方式を自動的に受け入れてはならない。
単一組織内だけで使い、外部へ検証可能な識別子を渡さないなら、通常のデータベースIDの方が単純である。複数組織が共通管理者なしに検証し、鍵更新可能な識別子を長期利用したい場合にDIDの価値が現れる。
参考資料
- [Decentralized Identifiers（DIDs）v1.0](https://www.w3.org/TR/did-core/)
- [DID Specification Registries](https://www.w3.org/TR/did-spec-registries/)
