ブログ・ 2026年7月28日

W3C分散型識別子（DID）仕様解説 (JA)

W3C DID Core仕様の技術的な解説：識別子とDID URLの構文、主体、コントローラー、DIDドキュメント、メソッド、解決、検証関係、サービス、プライバシー、検証可能なクレデンシャルについて。.

By Didit2026年7月28日更新日 2026年7月28日

W3C分散型識別子（DIDs）仕様は、URI構文、共通データモデル、DIDドキュメント、コアプロパティ、表現、メソッド要件、および解決とDID URLの参照解除のための抽象インターフェースを定義しています。DID Core 1.0は2022年7月19日にW3C勧告となりました。DID Core 1.1は2026年3月5日にCandidate Recommendation Snapshotとして公開されました。これは異なる標準化段階の新しい作業です。

DID Coreは、ブロックチェーンを必須とせず、個人の法的身元を証明せず、すべてのDIDドキュメント内にクレデンシャルを保存せず、解決されたすべてのエンドポイントを信頼できるものとしません。識別子とドキュメントのアーキテクチャを標準化します。個別のDIDメソッドは、特定のDIDが選択されたインフラストラクチャ上でどのように作成、読み取り、更新、および非アクティブ化されるかを定義します。

主なポイント

DIDはURIであり、クレデンシャルではありません。その一般的な形式はdid:<method-name>:<method-specific-id>です。
主体とコントローラーは異なる役割です。主体はDIDが識別するものであり、コントローラーはメソッドによってDIDドキュメントを変更する権限を与えられたものです。
鍵には明確な目的が必要です。検証メソッドは、対応する検証関係を通じてのみ、認証、アサーション、鍵合意、機能呼び出し、または委任に利用可能になります。
メソッドが運用ルールを提供します。DID Coreは技術に依存しません。メソッドはレジストリとのやり取り、認可、更新、非アクティブ化、およびメソッド固有の解決を定義します。
解決だけでは信頼は生まれません。実装者は、メソッドの結果を認証し、証明の目的を強制し、鍵と履歴を管理し、プライバシーを保護し、アプリケーションポリシーを適用する必要があります。

分散型識別子とは？

分散型識別子とは、すべての識別子を発行および維持するために単一の中央IDプロバイダーや認証局を必要とせずに、制御を確立できるように設計された識別子です。「分散型」という言葉は、単一の中央発行者から識別子の制御を分離するアーキテクチャの能力を説明しています。すべての実装が匿名、公開、不変、または分散型台帳に保存されることを意味するものではありません。

DIDは以下を識別できます。

個人
組織またはグループ
デバイスまたは物理オブジェクト
デジタルリソース
データモデル
抽象的な概念

識別されるエンティティはDID主体です。文字列だけでは主体の種類はわかりません。

DID構文

一般的な構文は次のとおりです。

did:<method-name>:<method-specific-id>

例：

did:example:123456789abcdefghi

didはURIスキームです。exampleはDIDメソッド名です。残りの文字列はメソッド固有の識別子です。メソッドの仕様は、その値が何を意味し、ソフトウェアがそれをどのように処理するかを定義します。

有効に見えるDIDが必ずしも使用可能であるとは限りません。メソッドが存在し、リゾルバーがそれをサポートしている必要があります。

DID URL：パス、クエリ、フラグメント

DID URLはDIDで始まり、パス、クエリ、またはフラグメントを追加できます。

did:example:123456789abcdefghi/path?service=messages#key-1

これらのコンポーネントは、以下を識別または選択するのに役立ちます。

DIDドキュメント内の検証メソッド
サービスエントリ
別のDIDドキュメントフラグメント
サービスを通じてアクセスされるリソース
バージョンまたはメソッド定義オプション

フラグメント#key-1は一般的に検証メソッドを識別します。これは秘密鍵がドキュメント内にあることを意味しません。DIDドキュメントは公開検証マテリアルまたは参照を公開します。秘密マテリアルは他の場所で保護される必要があります。

DIDアーキテクチャ

主要な概念は関連していますが、互換性はありません。

概念	役割
DID	DID構文に準拠するグローバルな一意の識別子
DID主体	識別される個人、組織、物、リソース、または概念
DIDコントローラー	DIDメソッドの下でDIDドキュメントを変更する権限を与えられたエンティティ
DIDドキュメント	許可された検証メソッドとサービスを含む、主体に関連付けられたデータ
DIDメソッド	メソッド固有の構文と操作に関する個別の仕様
検証可能なデータレジストリ	DIDの状態を生成、読み取り、更新、または非アクティブ化するためにメソッドが使用するインフラストラクチャ
DIDリゾルバー	サポートされているメソッドのDID解決を実行するソフトウェアまたはハードウェア
DID URL参照解除器	DID URLによって識別されるリソースを取得するソフトウェアまたはハードウェア

主体とコントローラー

主体とコントローラーは同じエンティティであることもありますが、そうである必要はありません。親が子のDIDを制御したり、組織がデバイスのDIDを制御したり、複数の受託者が回復アレンジメントを制御したりする場合があります。

最上位のcontrollerは1つ以上のDIDコントローラーを識別します。検証メソッドに必要なcontrollerは、そのメソッドを誰が制御するかを識別します。これは自動的に最上位のDIDコントローラーではありません。これらを混同すると、意図しない権限が付与される可能性があります。

DIDドキュメントとは？

DIDドキュメントは、DID Coreデータモデルの下でDID主体に関連付けられたデータです。そのルートのidはDIDです。オプションのコアプロパティは、コントローラー、代替識別子、検証メソッド、検証関係、およびサービスを記述できます。

この簡略化された例では、仕様の例スペースからの公開マテリアルを使用しています。

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/jws-2020/v1"
  ],
  "id": "did:example:123",
  "verificationMethod": [
    {
      "id": "did:example:123#key-1",
      "type": "JsonWebKey2020",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "OKP",
        "crv": "Ed25519",
        "x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ"
      }
    }
  ],
  "authentication": [
    "did:example:123#key-1"
  ],
  "assertionMethod": [
    "did:example:123#key-1"
  ]
}

did:exampleは例のために予約されています。本番システムでは、実際のメソッドとその現在の検証メソッドスイートの要件を使用する必要があります。上記のJSONは意図的に有効なJSONです。技術仕様内に印刷されている多くの例には、読みやすさのためにコメントや省略記号が含まれており、パーサーに直接コピーすべきではありません。

コアプロパティ

id: 主体のDID。ドキュメントルートに必須。
controller: メソッドに基づいて変更を行う権限を与えられた1つ以上のDID。
alsoKnownAs: 同じ主体を識別すると主張される他のURI。
verificationMethod: 明示的な関係によって参照される可能性のある公開検証メカニズム。
authentication: 主体として認証する権限を与えられたメソッド。
assertionMethod: クレデンシャルの発行など、主張を表現する権限を与えられたメソッド。
keyAgreement: 共有秘密情報を導出するためのメソッド。
capabilityInvocation: 機能を呼び出す権限を与えられたメソッド。
capabilityDelegation: 機能を委任する権限を与えられたメソッド。
service: 主体に関連付けられたエンドポイントまたは相互作用メカニズム。

alsoKnownAsは、2つの識別子が同等であるという暗号学的証明ではなく、主張です。アプリケーションは、信頼モデルに必要な関係を個別に検証する必要があります。

データモデルと表現

DID Coreは、抽象的なデータモデルと、表現を生成および消費するためのルールを定義します。データモデルは、1つのJSONシリアライゼーションと同一ではありません。

表現要件はバージョン固有です。

2022年のDID Core 1.0勧告は、application/did+jsonとapplication/did+ld+jsonを定義しています。そのJSON-LD表現は、基本コンテキストhttps://www.w3.org/ns/did/v1で始まります。
DID Core 1.1 Candidate Recommendationは、コアメディアタイプをapplication/didに統合しています。そのJSON-LD表現は、https://www.w3.org/ns/did/v1.1で始まります。

一方のバージョンからのメディアタイプまたは基本コンテキストを、もう一方の適合性の主張と混同しないでください。プロデューサーとコンシューマーが実装する仕様バージョンを固定してください。

実装者は、表現を明示的に交渉し、検証する必要があります。定義された正規化とセキュリティメカニズムなしに任意のシリアライズされたJSONバイトに署名することは、DIDデータモデルを正しく処理することとは異なります。

検証メソッドと検証関係

検証メソッドは、証明をどのようにチェックできるかを記述します。これには以下が必要です。

DID URLとして表現されるid
type
controller
そのタイプに適した検証マテリアル

公開マテリアルは、publicKeyJwkなどの定義されたプロパティ、または検証メソッドスイートによって許可される別の形式で表現できます。DIDドキュメント内のJWKには秘密鍵マテリアルを含めてはなりません。同じ検証マテリアルを、1つのメソッド内の複数のマテリアルプロパティで重複させてはなりません。

検証メソッドを定義しても、すべての目的に対してそれが承認されるわけではありません。承認は、5つの明示的な検証関係から得られます。

関係	意図された証明目的
`authentication`	チャレンジ＆レスポンスまたは他の受け入れられたメカニズムを通じてDID主体として認証する
`assertionMethod`	選択されたセキュリティメカニズムがそれを使用する場合、検証可能なクレデンシャルへの署名を含む、クレームを表明する
`keyAgreement`	共有暗号化マテリアルを確立する。多くの場合、暗号化用
`capabilityInvocation`	オブジェクト機能を呼び出す
`capabilityDelegation`	オブジェクト機能を委任する

検証者は、証明に必要な関係をチェックする必要があります。authenticationの下にのみリストされている鍵は、クレデンシャルアサーションや鍵合意に対して自動的に承認されません。

関係は、完全な検証メソッドを埋め込むことも、DID URLで参照することもできます。参照は再利用性を向上させますが、正しい参照解除と正確な識別子比較が必要です。

サービスとサービスエンドポイント

オプションのserviceプロパティは、DID主体と通信または相互作用する方法を広告できます。すべてのサービスエントリには以下が含まれます。

一意のid
type
serviceEndpoint

エンドポイントはURIまたは他の許可された構造である場合があります。サービス定義は拡張可能であるため、アプリケーションは選択されたタイプを理解する必要があります。

エンドポイントを公開しても、そのサーバー、オペレーター、トランスポート、コンテンツ、または宛先が信頼できることを証明するものではありません。

アプリケーションは、解決されたDIDの状態をメソッドを通じて認証し、サービスタイプを検証し、URLおよびネットワークセキュリティ制御を適用し、独自のセキュリティプロパティを持つアプリケーションプロトコルを使用する必要があります。

公開サービスエンドポイントも相関関係を生み出す可能性があります。ペアワイズDID間で1つのエンドポイントを再利用すると、個別の識別子のプライバシー上の利点が失われる可能性があります。

DIDメソッドが定義するもの

DID Coreは共通のアーキテクチャを提供します。適合するDIDメソッドは、それを実装するために必要なメソッド固有のルールを定義します。これには以下が含まれます。

メソッド名とメソッド固有の識別子構文
DIDと初期DIDドキュメントがどのように作成されるか
現在の状態がどのように読み取られるか
承認された更新がどのように提出され、検証されるか
DIDがどのように非アクティブ化されるか
解決がレジストリとどのように通信するか
結果の信頼性と完全性がどのように確立されるか
鍵のローテーション、回復、バージョン管理、履歴がどのように機能するか
メソッド固有のセキュリティとプライバシーに関する考慮事項

検証可能なデータレジストリは、分散型台帳、分散型ファイルシステム、ピアツーピアネットワーク、データベース、またはその他のシステムである可能性があります。アーキテクチャは、「分散型」という言葉ではなく、ガバナンス、可用性、認可、プライバシー、コスト、履歴、および攻撃耐性に基づいて評価されるべきです。

メソッド選択基準

メソッドを選択する前に、以下をテストしてください。

仕様の成熟度とガバナンス
リゾルバーとライブラリの相互運用性
更新と非アクティブ化の承認
鍵のローテーションと回復
履歴状態のサポート
プライバシーとメタデータの漏洩
レジストリの可用性と検閲リスク
トランザクションまたは運用コスト
暗号的俊敏性
移行とメソッドの障害

メソッドを変更することは、通常、新しい識別子と信頼できる移行パスを導入することを意味します。

DID解決とDID URL参照解除

DID解決は、DIDと解決オプションを受け取り、以下を返します。

DID解決メタデータ
DIDドキュメント、ドキュメントストリーム、またはドキュメントなし
DIDドキュメントメタデータ

リゾルバーは、メソッドによって定義された「読み取り」操作を使用します。DID Coreは抽象的なインターフェースと共通の結果概念を定義します。メソッド固有の通信と認証はメソッドに残ります。

DID URL参照解除は、完全なDID URLを受け取り、以下を返します。

参照解除メタデータ
識別されたリソース（利用可能な場合）
コンテンツメタデータ

参照解除は、まずベースDIDを解決し、次にフラグメント、サービス、または外部リソースを選択する場合があります。これは解決の同義語ではありません。

個別のW3C DID解決仕様は、詳細な解決および参照解除アルゴリズムを開発しています。その最新の公開は2026年7月24日付けのW3Cワーキングドラフトであり、DID URL参照解除はリスクのある機能としてマークされています。これは、2022年のDID Core 1.0勧告の一部ではなく、標準化トラック作業であるため、適合性を主張する前にドラフトを固定してください。

リゾルバーの信頼とキャッシング

リゾルバーはセキュリティとプライバシーの境界です。要求された識別子を認識し、古い状態や操作された状態を返す可能性があります。以下を評価してください。

メソッド結果の検証
トランスポートとリゾルバーの認証
キャッシュの鮮度と無効化
バージョンと時間のオプション
エラー処理とダウングレード動作
ルックアップによるプライバシー漏洩
レジストリまたはネットワーク障害時の動作

DIDと検証可能なクレデンシャル

DIDと検証可能なクレデンシャルは補完的な仕様であり、同じオブジェクトではありません。

ベースDIDは以下を識別できます。

クレデンシャル発行者
クレデンシャル主体
保有者

セキュリティメカニズムによって使用される検証メソッドは、代わりにDID URL（通常はDIDに#key-1などのフラグメントが続く）によって識別されます。

W3C検証可能なクレデンシャルデータモデル2.0は、クレデンシャル、プレゼンテーション、発行者、保有者、主体、有効性、ステータス、スキーマ、およびセキュリティメカニズムを定義します。すべての識別子がDIDであることを要求するものではありません。

発行者にDIDが使用される場合、検証者は発行者のDIDを解決し、証明の検証メソッドを見つけ、そのメソッドがassertionMethodの下で承認されていることを確認するかもしれません。その暗号学的検証は、以下のことをまだ確立しません。

すべてのクレデンシャルクレームが真実であること
発行者がそのクレームについて信頼されていること
クレデンシャルが最新であるか受け入れられること
そのステータス、スキーマ、または証拠がポリシーに適合していること
クレデンシャル主体がそれを提示している人物であること

これらのチェックは、セキュリティメカニズム、ステータスシステム、信頼フレームワーク、プレゼンテーションバインディング、および検証者ポリシーに属します。

プライバシーとセキュリティに関する考慮事項

公開ドキュメントでの個人データの回避

DIDドキュメントは広く複製される可能性があります。モデルが拡張可能だからといって、名前、政府識別子、生体認証、クレデンシャル、またはその他の個人データを公開しないでください。暗号化は、永続的に公開される暗号文に対する永続的な答えではありません。

相関関係の防止

ペアワイズまたはコンテキスト固有のDIDは、他のデータも分離されている場合にのみ相関関係を減らすことができます。再利用された鍵、サービスエンドポイント、ネットワーク識別子、クレデンシャル属性、タイミング、およびレジストリアクティビティは、個別のDIDであると見なされるものをリンクする可能性があります。

鍵のローテーションと回復

ローンチ前に侵害を計画してください。更新承認、回復コントローラー、しきい値ルール、ローテーション、古い鍵の処理、および非アクティブ化を定義してください。回復権限には分離と監査が必要です。

証明目的の検証

署名が検証されるだけでなく、検証メソッドが関連する時点で必要な関係に対して承認されていたことを確認してください。認証、アサーション、合意、および機能の使用間の置き換えを防いでください。

履歴の慎重な取り扱い

現在のDIDドキュメントには古い鍵が含まれていない場合があります。過去の証明を検証するには、メソッドでサポートされている過去のバージョンと、証明時間の信頼できる証拠が必要になる場合があります。「現在鍵が存在しない」と「証明は決して有効でなかった」は同等の結論ではありません。

一般的なDID実装の誤り

DID Coreをブロックチェーン仕様と呼ぶこと

DID Coreは技術中立です。ブロックチェーンは可能なレジストリアーキテクチャの1つです。

DIDを法的身元の証明として扱うこと

DIDは識別子の制御と暗号学的検証をサポートします。現実世界の身元バインディングには、別途の証拠、発行者の主張、または信頼フレームワークが必要です。

リストされている任意の鍵を任意の目的で使用すること

明示的な検証関係と証明目的を強制してください。

サービスエンドポイントを自動的に信頼すること

メソッドの状態を検証し、アプリケーション、トランスポート、URL、およびコンテンツのセキュリティを適用してください。

すべてのDIDがプライベートまたは匿名であると仮定すること

レジストリアクティビティ、解決、再利用されたマテリアル、およびサービスは、永続的な相関関係を露出させる可能性があります。

実装チェックリスト

本番稼働前に、以下を確認してください。

選択されたDID CoreバージョンとDIDメソッド仕様が固定されていること
識別子とDID URLの解析が標準準拠のURI処理を使用していること
受け入れられる表現とメディアタイプが明示されていること
すべての証明が意図された検証関係を強制していること
メソッドの結果が、任意のリゾルバーからの信頼ではなく、認証されていること
キャッシング、バージョン管理、履歴検証、および非アクティブ化がテストされていること
更新、ローテーション、侵害、回復、および移行の手順がリハーサルされていること
公開ドキュメントに不要な個人データや相関データが含まれていないこと
サービスエンドポイントが個別のアプリケーション層セキュリティレビューを受けていること
検証可能なクレデンシャルの信頼、ステータス、スキーマ、およびプレゼンテーションのチェックが分離されたままであること

DIDと本人確認の接点

DIDは主体と検証マテリアルを識別できますが、本人確認は行いません。再利用可能なIDシステムは、クレームを発行または受け入れる前に、信頼できる証拠と統制された決定を依然として必要とします。Diditの本人確認は、そのような決定のための身元証拠を提供でき、再利用可能なKYCは、参加サービス間で以前の検証を再利用することをサポートし、無料で提供されています。

この製品の隣接性は、すべてのDidit検証がDIDであること、またはDID解決がKYCに取って代わることを意味するものではありません。現在のモジュール料金は料金ページで確認できます。アーキテクチャは、識別子の制御、身元証拠、クレデンシャル発行、プレゼンテーション、および依存する当事者のポリシーを別々の信頼境界として維持する必要があります。

よくある質問

W3C DID仕様は何を定義していますか？

DIDとDID URLの構文、共通データモデル、コアDIDドキュメントプロパティ、表現、メソッド要件、および抽象的な解決と参照解除インターフェースを定義しています。

すべてのDIDはブロックチェーンを使用しますか？

いいえ。DIDメソッドは、台帳、データベース、ピアツーピアシステム、分散型ファイルシステム、または別のレジストリアーキテクチャを使用できます。

DIDとDIDドキュメントの違いは何ですか？

DIDは識別子です。DIDドキュメントは、コントローラー、検証メソッドとその目的、サービス、およびその他の定義されたプロパティを記述できる関連データです。

解決と参照解除の違いは何ですか？

解決は、DIDのDIDドキュメントとメタデータを取得します。参照解除は、完全なDID URLによって識別されるリソースを、そのベースDIDを解決した後に取得します。

DIDは検証可能なクレデンシャルと同じですか？

いいえ。DIDは識別子です。検証可能なクレデンシャルは、VCデータモデルとセキュリティメカニズムの下での、改ざん防止機能付きで機械で検証可能なクレームのセットです。VCはDIDを使用できますが、普遍的に必要とするわけではありません。

DIDを制御することで、その人物が誰であるかを証明できますか？

いいえ。DIDに関連付けられた暗号学的またはメソッド固有の権限の制御を証明できます。その制御を法的または現実世界の身元に結びつけるには、追加の証拠または信頼できる主張が必要です。

DIDドキュメントに秘密鍵を含めることはできますか？

いいえ。DIDドキュメントには公開検証マテリアルまたは参照が含まれます。秘密鍵マテリアルは表示されてはならず、コントローラーの鍵管理システムによって保護されたままでなければなりません。

主要参考文献

DID Coreは、その主張が正確である場合に最も役立ちます。識別子、ドキュメント、検証目的、サービス、およびメソッドインターフェースを標準化します。信頼は依然として、メソッドのガバナンス、認証された解決、保護された鍵、明示的な証明目的、プライバシーを意識した設計、およびアプリケーションがどのような証拠を受け入れるかという決定から生まれます。