分散型識別子解決（DID Resolution）v0.3

非規範的であると示された節に加えて、本仕様内のすべての作成ガイドライン、図、例、および注記は非規範的である。それ以外の本仕様内のすべては規範的である。

この文書におけるキーワードMAY、MUST、MUST NOT、NOT REQUIRED、OPTIONAL、RECOMMENDED、REQUIRED、およびSHOULDは、 ここに示すようにすべて大文字で現れる場合に限り、 BCP 14 [RFC2119] [RFC8174] で説明されているとおりに解釈される。

適合DIDリゾルバーとは、 4. DID 解決における 関連する規範的記述に準拠する、ソフトウェアおよび/またはハードウェアとして実現された任意の アルゴリズムである。

適合ネットワークベースDIDリゾルバー とは、適合DIDリゾルバーであって、さらに 12.1 HTTP(S)バインディングの 規範的記述にも準拠するものである。

適合DID URL参照解決器とは、 5. DID URL参照解決における 関連する規範的記述に準拠する、ソフトウェアおよび/またはハードウェアとして実現された任意の アルゴリズムである。

適合ネットワークベースDID URL参照解決器 とは、適合DID URL参照解決器であって、 さらに12.1 HTTP(S)バインディングの規範的記述に 準拠するものである。

本仕様内のすべての日時値は、 [VC-DATA-MODEL]のVerifiable Credentials Data Model v2.0で定義される有効なXML日時値である ASCII 文字列でなければMUSTならない。 さらに、DID解決で使用されるタイムスタンプは、 秒未満の小数精度を持たずにUTCへ調整されていなければMUSTならない。例: 2020-12-20T19:17:47Z

DID URLのクエリ文字列は、 解決パイプライン全体にわたる複数の独立したコンポーネント — たとえば、クライアント、キャッシュプロキシ、下流 リゾルバー、およびDIDメソッド固有リゾルバー（ 8.2 リゾルバー アーキテクチャを参照）— によって日常的に構築、解析、 ログ記録、キャッシュ、および比較される。これらのコンポーネント間で DID URLのクエリ文字列の 正規化が一貫しない場合、誤った解決結果、キャッシュポイズニング、または相互運用性の 破綻を静かに生じさせる可能性がある。この節では、実装者およびDID メソッド仕様の著者が明示的に対処することを推奨されるエッジケースを列挙する。

これは、DID解決プロセスの 入力オプションを含むメタデータ構造である。

この構造内で可能なプロパティおよびそれらの可能な値は、DID Resolution Extensions [DID-EXTENSIONS-RESOLUTION]に登録されるべき SHOULDである。 本仕様は次の共通入力オプションを定義する。

accept

呼び出し元が選好する DID文書の 表現のメディアタイプ。 その値は、HTTP Semanticsの 第12.5.1節で定義される Acceptヘッダー値に従って表現されなければ MUSTならない。DIDリゾルバー 実装は、そのような表現が対応され利用可能である場合、 返されるdidDocumentの表現を 決定するためにこの値を使用すべきSHOULDである。 このプロパティはOPTIONALである。

expandRelativeUrls

DIDリゾルバーに、 DID 文書内の 相対DID URLを、 DID URL構文に適合する 絶対DID URLへ展開するよう指示する真偽値フラグ。

versionId

定義については3. DIDパラメーターを参照。

versionTime

定義については3. DIDパラメーターを参照。

これは、DID 解決プロセスに関するメタデータを含む メタデータ構造である。

このメタデータは、解決プロセス自体に関するデータを表すため、 通常は DID解決 関数の呼び出しごとに変化する。

このメタデータのソースはDIDリゾルバーである。

DID解決メタデータの例には次が含まれる。

• 返されるコンテンツのメディアタイプ（contentType）。
• エラーオブジェクト（error）（11. エラーの節を参照）。
• 信頼された解決を確立するためなどに、 DIDリゾルバーによって生成される証明 （proof）。
• DID解決プロセスの所要時間。
• キャッシュ情報（13.2 キャッシュの節を参照）。
• DID解決プロセス中に使用された 検証可能データレジストリに関する URL、IPアドレス、および/またはその他のネットワーク情報。

この構造内で可能なプロパティおよびそれらの可能な値は、DID Resolution Extensions [DID-EXTENSIONS-RESOLUTION]に登録されるべき SHOULDである。 本仕様は次の共通メタデータプロパティを定義する。

contentType

返されるdidDocumentのメディアタイプ。この プロパティはOPTIONALである。存在する場合、このプロパティの値は、 適合する表現の メディアタイプである ASCII文字列でなければ MUSTならない。この場合、resolve関数の呼び出し元は、 didDocumentの解析および処理方法を決定する際にこの値を使用しなければ MUSTならない。

error

エラーデータ構造は[RFC9457]で定義される。本仕様で 定義されるエラーは、11. エラーの節に示されている。 追加のエラーはDID Resolution Extensions [DID-EXTENSIONS-RESOLUTION]に登録されるべき SHOULDである。

proof

一部のDID リゾルバーおよびDID URL参照解決器は、 DID解決またはDID URL参照解決 関数を実行する際に証明を使用する。詳細については 8.2 リゾルバーアーキテクチャを参照。

DID 解決メタデータはproofプロパティを含んでもMAYよい。 存在する場合、その値は 集合でなければMUSTならず、 各項目は証明を表すマップである。このプロパティの使用 および証明の型は、DIDメソッドに依存しない。

これは、DID 解決プロセスに関するメタデータを含む メタデータ構造である。

このメタデータは、DID文書に 関するデータを表すため、 DID解決 関数の呼び出し間では、DID文書 が変更されない限り、通常は変化しない。

このメタデータのソースは、DIDコントローラーおよび/または DIDメソッドである。DID コントローラーによって証明されたDID文書メタデータには、正確性についての固有の保証はない。 クライアントは、ビジネスロジックを判断するためにDID文書メタデータに依存する場合、 慎重に進めることが推奨される。

DID文書メタデータの例には次が含まれる。

• DIDおよび関連する DID文書 が作成または更新された時刻のタイムスタンプ（例: created、 updated、nextUpdate）。
• DID文書に関するバージョニング情報（例: versionId、 nextVersionId）。
• DIDコントローラーによって追加された証明、または DIDメソッドの 検証可能データ レジストリによって生成された証明。これは 制御権限を確立するため、または検証可能 解決 を可能にするために使用されることがある （例: proof）。
• コントローラー、能力、委任などに関するメタデータ。
• ブロックチェーンまたはその他の 検証可能データ レジストリ内のレコードのブロック番号、インデックス、トランザクションハッシュ、 確認数などのメソッド固有メタデータ。

この構造内で可能なプロパティおよびそれらの可能な値は、DID Document Properties Extensions [DID-EXTENSIONS-PROPERTIES]に登録されるべき SHOULDである。本仕様は次の共通 メタデータプロパティを定義する。

created

DID文書 メタデータは、Create操作の タイムスタンプを示すために、createdプロパティを含むべき SHOULDである。そのプロパティの値は 3.1 日時で定義される 日時形式で表現されなければMUSTならない。

updated

DID文書 メタデータは、解決された文書バージョンに対する最後の Update操作のタイムスタンプを示すために、 updatedプロパティを含むべき SHOULDである。そのプロパティの値は 3.1 日時で定義される日時形式で表現されなければ MUSTならない。 DID文書に対して Update操作が一度も実行されていない場合、updatedプロパティは省略される。 updatedプロパティが存在する場合、2つのタイムスタンプの差が1秒未満であれば、 それはcreatedプロパティと同じ値であってもよい。

deactivated

DIDが無効化されている場合、 DID文書 メタデータは、このプロパティを真偽値trueで含まなければ MUSTならない。DIDが無効化されていない場合、 このプロパティはOPTIONALであるが、含まれる場合は 真偽値falseを持たなければMUSTならない。

nextUpdate

解決された文書バージョンが文書の最新バージョンでない場合、 DID文書 メタデータは nextUpdateプロパティを含んでもMAYよい。 これは次のUpdate操作の タイムスタンプを示す。そのプロパティの値は 3.1 日時で定義される 日時形式で表現されなければMUSTならない。

versionId

DID文書 メタデータは、解決された文書バージョンに対する最後の Update操作のバージョンを示すために、 versionIdプロパティを含むべきSHOULDである。 そのプロパティの値は ASCII文字列でなければ MUSTならない。

nextVersionId

解決された文書バージョンが文書の最新バージョンでない場合、 DID文書 メタデータは nextVersionIdプロパティを含んでもMAYよい。 これは次のUpdate操作の バージョンを示す。そのプロパティの値はASCII文字列でなければ MUSTならない。

equivalentId

DIDメソッドは、 論理的に等価であるDIDの 異なる形式を定義できる。例として、DIDが 検証可能データ レジストリへの登録前にある形式を取り、 登録後に別の形式を取る場合がある。この場合、 DIDメソッド 仕様は、解決されたDIDと 論理的に等価な1つ以上のDIDを、 DID 文書のプロパティとして表現する必要がある場合がある。これが equivalentId プロパティの目的である。

DID 文書メタデータは equivalentIdプロパティを含んでもMAYよい。存在する場合、その値は、 各項目が 文字列であり、かつ Decentralized Identifiers (DIDs) v1.0の節の規則に適合する 集合でなければMUSTならない。 その関係は、各 equivalentId 値がidプロパティ値と論理的に 等価であり、したがって同じDID 主体を参照するという 記述である。各 equivalentId DID値は、idプロパティ値と同じ DIDメソッドによって 生成され、その形式でなければMUSTならない。 （例: did:example:abc == did:example:ABC）

適合するDID メソッド仕様は、各 equivalentId 値がidプロパティ値と論理的に 等価であることを保証しなければMUSTならない。

要求側は、 idおよび equivalentId プロパティの値を保持し、それらに含まれるいずれかの値との後続のやり取りが 論理的に等価なものとして正しく処理されるようにすることが期待される （例: すべてのバリアントをデータベースに保持し、いずれか1つとのやり取りが 同じ基礎アカウントにマッピングされるようにする）。

注記: より強い等価性

equivalentId は alsoKnownAsよりも はるかに強い形式の等価性である。なぜなら、その等価性は統括するDID メソッドによって保証されなければ MUSTならないからである。 equivalentId の使用は、同じDID文書が、 equivalentId DIDと idプロパティのDIDの 両方を記述することを意味する。

要求側がidおよび equivalentId プロパティの値を保持せず、 それらに含まれるいずれかの値との後続のやり取りが 論理的に等価なものとして正しく処理されるようにしない場合、 否定的または予期しない問題が発生する可能性がある。実装者は、 このメタデータプロパティに関連する指示を遵守することを 強く推奨される。

canonicalId

canonicalId プロパティは、 equivalentId プロパティと同一であるが、次の点を除く。a) 集合ではなく単一の値に関連付けられること、b) DIDが、 それを含むDID 文書の範囲内で、 DID 主体の正準IDとして定義されることである。

DID 文書メタデータはcanonicalId プロパティを含んでもMAYよい。 存在する場合、その値は 文字列であり、 Decentralized Identifiers (DIDs) v1.0の節の規則に 適合しなければMUSTならない。 その関係は、 canonicalId 値がidプロパティ値と論理的に等価であり、かつ canonicalId 値がDIDメソッドによって、 それを含むDID 文書の範囲内で DID主体の正準IDとして 定義されるという記述である。 canonicalId 値は、idプロパティ値と同じDIDメソッドによって 生成され、その形式でなければMUSTならない。 （例: did:example:abc == did:example:ABC）。

適合するDID メソッド仕様は、 canonicalId 値が idプロパティ値と論理的に等価であることを保証しなければ MUSTならない。

要求側は、 canonicalId 値を DID主体の主要な ID値として使用し、他のすべての等価な値を二次的な別名として扱うことが期待される （例: 新しい正準ID指示を反映するように、システム内の対応する主要参照を更新する）。

注記: 正準等価性

canonicalId は equivalentId と同じ等価性の記述であるが、 DID主体について、 DID 文書の範囲内で正準であると定義される 単一の値に制約される点が異なる。 equivalentIdと同様に、 canonicalId の使用は、同じDID文書が、 canonicalId DIDと idプロパティのDIDの 両方を記述することを意味する。

解決側が canonicalId 値をDID主体の主要な ID値として使用せず、他のすべての等価な値を 二次的な別名として扱わない場合、ユーザー体験に関連して 否定的または予期しない問題が発生する可能性がある。実装者は、 このメタデータプロパティに関連する指示を遵守することを強く 推奨される。

proof

多くのDID メソッドは、 メソッド操作を実行する際に証明を使用する。詳細については 8.1 メソッド アーキテクチャを参照。

DID 文書メタデータは proofプロパティを含んでもMAYよい。存在する場合、その値は 集合でなければMUSTならず、 各項目は証明を表す マップである。このプロパティの使用 および証明の型は DID メソッド固有である。

DIDリゾルバーは、 次の DID解決 アルゴリズムを実装する。

1. 入力DIDが DID構文のdid規則に適合することを検証する。 適合しない場合、DID リゾルバーは次の結果を返さなければ MUSTならない。
   1. didResolutionMetadata: 型が https://www.w3.org/ns/did#INVALID_DIDに設定された エラーオブジェクト
   2. didDocument: null
   3. didDocumentMetadata: «[ ]»
2. 入力DIDの DIDメソッドが、 このアルゴリズムを実装する DIDリゾルバー によってサポートされているかどうかを判定する。 サポートされていない場合、DID リゾルバーは次の 結果を返さなければMUSTならない。
   1. didResolutionMetadata: 型が https://www.w3.org/ns/did#METHOD_NOT_SUPPORTEDに設定された エラーオブジェクト
   2. didDocument: null
   3. didDocumentMetadata: «[ ]»
3. 入力DID解決オプション が、このアルゴリズムを実装する DIDリゾルバーによって サポートされているかどうかを判定する。サポートされていない場合、 DIDリゾルバーは 次の結果を返さなければMUSTならない。
   1. didResolutionMetadata: 型が https://www.w3.org/ns/did#FEATURE_NOT_SUPPORTEDに設定された エラーオブジェクト
   2. didDocument: null
   3. didDocumentMetadata: «[ ]»
4. 入力DID解決オプション が有効かどうかを判定する。有効でない場合、 DIDリゾルバーは 次の結果を返さなければMUSTならない。
   1. didResolutionMetadata: 型が https://www.w3.org/ns/did#INVALID_OPTIONSに設定された エラーオブジェクト
   2. didDocument: null
   3. didDocumentMetadata: «[ ]»
5. 入力DIDの DID 文書を、 入力DIDメソッドによって 定義される Resolve 操作を実行することで取得する。
   1. 入力DID が存在しない場合、次の結果を返す。
      1. didResolutionMetadata: 型が https://www.w3.org/ns/did#NOT_FOUNDに設定された エラーオブジェクト
      2. didDocument: null
      3. didDocumentMetadata: «[ ]»
   2. 入力DID が無効化されている場合、次の結果を返す。
      1. didResolutionMetadata: «[ ... ]»
      2. didDocument: null
      3. didDocumentMetadata: «[ "deactivated" → true, ... ]»
   3. それ以外の場合、Resolve 操作の結果を出力DID文書と呼ぶ。 この結果は 適合表現で表現されなければ MUSTならない。
6. 入力DID解決オプション が、値trueのexpandRelativeUrlsオプションを含む場合:
   1. 出力DID文書内の すべてのサービス、 検証メソッド、 検証 関係 および拡張定義プロパティを反復処理する。
   2. 各項目について、その項目がオブジェクトであり、 idプロパティの値が相対DID URLである場合、 または検証 関係が 相対DID URLである場合:
      1. Decentralized Identifiers (DIDs) v1.0の 相対DID URLの節の規則に従い、 相対DID URLを、 DID URL構文に適合する 絶対DID URLへ解決する。
   3. 出力DID文書を更新し、 相対DID URLを、解決された 絶対DID URLに置き換える。
7. 次の結果を返す。
   1. didResolutionMetadata: «[ ... ]»
   2. didDocument: 出力DID文書
   3. didDocumentMetadata: «[ "contentType" → 出力DID文書メディア タイプ, ... ]»

DIDリゾルバーが DID解決アルゴリズムの実行中に 予期しないエラーに遭遇した場合、次の結果を返さなければ MUSTならない。

1. didResolutionMetadata: 型が https://www.w3.org/ns/did#INTERNAL_ERRORに設定された エラーオブジェクト
2. didDocument: null
3. didDocumentMetadata: «[ ]»

これは、 DID URL 参照解決プロセスの入力オプションを含む メタデータ構造である。

この構造内で可能なプロパティおよびそれらの可能な値は、DID Resolution Extensions [DID-EXTENSIONS-RESOLUTION]に登録されるべき SHOULDである。 本仕様は次の共通入力オプションを定義する。

accept

呼び出し元がcontentStreamについて選好する メディアタイプ。その値は、 HTTP Semanticsの 第12.5.1節で定義される Acceptヘッダー値に従って表現されなければ MUSTならない。DID URL 参照解決器 実装は、そのような表現が対応され利用可能である場合、 返される値に含まれる 表現の contentTypeを決定するために、この値を使用すべき SHOULDである。

verificationRelationship

呼び出し元が、DID URLから参照解決されたverificationMethodについて 認可されていることを期待するverificationRelationship。存在する場合、関連値は ASCII文字列でなければ MUSTならない。DID URLが verificationMethodへ参照解決されない場合、またはDID文書が指定された verificationRelationshipについてverificationMethodを認可しない場合、エラーを 発生させなければMUSTならない。

これは、DID URL参照解決プロセスに 関するメタデータを含む メタデータ構造である。

このメタデータは、参照解決プロセス自体に関するデータを表すため、 通常は DID URL 参照解決関数の呼び出しごとに変化する。

このメタデータのソースはDID URL参照解決器である。

この構造内で可能なプロパティおよびそれらの可能な値は、DID Resolution Extensions [DID-EXTENSIONS-RESOLUTION]に登録されるべき SHOULDである。 本仕様は次の共通メタデータプロパティを定義する。

contentType

参照解決が成功した場合、返されるcontentStreamのメディアタイプは、 このプロパティを使用して表現されるべきSHOULDである。 メディアタイプ値は ASCII文字列として表現されなければ MUSTならない。

error

[RFC9457]で定義されるエラーデータ構造。 このプロパティは、参照解決プロセスでエラーが発生した場合に REQUIREDである。本仕様で定義されるエラーは 11. エラーの節に示されている。 追加のエラーはDID Resolution Extensions [DID-EXTENSIONS-RESOLUTION]に登録されるべき SHOULDである。

proof

一部のDID リゾルバーおよび DID URL 参照解決器は、 DID 解決またはDID URL参照解決 関数を実行する際に証明を使用する。詳細については 8.2 リゾルバーアーキテクチャを参照。

DID URL 参照解決メタデータは proofプロパティを含んでもMAYよい。 存在する場合、その値は 集合でなければMUSTならず、 各項目は証明を表す マップである。このプロパティの使用 および証明の型は DID メソッドに依存しない。

これは、DID URL参照解決プロセスに 関するメタデータを含む メタデータ構造である。

このメタデータは、コンテンツに関するデータを表すため、 コンテンツが変更されない限り、通常は DID URL 参照解決関数の呼び出し間では変化しない。

このメタデータのソースは、DIDコントローラーおよび/または DIDメソッドである。

この構造内で可能なプロパティおよびそれらの可能な値は、DID Resolution Extensions [DID-EXTENSIONS-RESOLUTION]に登録されるべき SHOULDである。 本仕様は共通プロパティを定義しない。

DID URL 参照解決器は、次の DID URL 参照解決アルゴリズムを実装する。 [RFC3986]に従い、 これは次の3つのステップで構成される。DIDの解決、 リソースの参照解決、およびフラグメントの参照解決（ 入力DID URLが DIDフラグメントを含む場合のみ）。

DID解決 アルゴリズムは、 Resolve操作を、 DIDに対して、 そのDID メソッドに従って実行することを含む（ 4. DID解決を参照）。

すべてのDIDメソッドは、このメソッド操作、すなわち DIDリゾルバーが DIDからDID文書をどのように取得できるかを定義する。 基礎となるデータ形式、プロトコル、技術インフラストラクチャ、およびプロセスは、 DIDメソッド間で かなり異なる場合がある。

DIDメソッドに関する考慮事項の例には次が含まれる。

• DIDメソッドは、（その一部としての） 検証可能データ レジストリとして、不変ブロックチェーン、分散台帳、分散ファイルシステム、 ピアツーピアネットワーク、またはその他の分散型インフラストラクチャを 使用することがある。
• DIDメソッドは、（その一部としての） 検証可能データ レジストリとして、DNS、HTTP、またはWebサーバーを使用することがある。
• DIDメソッドは、上記の技術インフラストラクチャの任意の組み合わせを使用することがある。
• DIDメソッドは、実際のDID文書を平文形式で 検証可能データレジストリに 保存し、"Resolve"操作中にその文書を単純に取得することがある。
• DIDメソッドは、その"Resolve"操作をより複雑な方法で定義することがある。 それには、中間的、部分的、または一時的な DID文書が 関与する可能性があり、 DID文書を "その場で"構築する多段階プロセスを使用することがある。
• DIDメソッドは、"Resolve"操作の実行中にリモートサーバーまたはネットワークとの やり取りを必要とすることがある。
• DIDメソッドは、リモートサーバーまたはネットワークとのやり取りを一切必要としない、 完全にローカルな方法で"Resolve"操作を実行することがある。たとえば、 [DID-KEY]メソッドでは、DID自体が公開鍵を包み、 "Resolve"操作は単なる自明なローカル変換プロセスである。

上記の考慮事項と DIDメソッドの "Resolve"操作の性質を組み合わせると、 DIDリゾルバーと 検証可能データレジストリ との相互作用は、 検証可能解決または 検証不能解決のいずれかと見なされ得る。

検証可能解決は、適用される DID メソッドの下で可能な範囲において、 "Resolve"操作の結果の完全性および正確性に対する信頼を最大化する。 これは、次のようないくつかの方法で達成できる。

• 検証可能解決は、 検証可能データレジストリへの アクセスがローカルで信頼されたネットワーク環境内で可能である場合に達成できる。
  • たとえば、ブロックチェーンベースのDIDメソッドでは、 ブロックチェーンのフルノードがローカルサーバーにデプロイされていれば、 検証可能解決を達成できることがある。
• 検証可能データレジストリへの アクセスがリモートサーバーを介して行われる場合でも、そのリモートサーバーが 信頼され、安全なチャネルを介してアクセスできるなら、 検証可能解決を達成できることがある。
• 検証可能データレジストリへの アクセスがリモートサーバーを介して行われる場合でも、 DIDリゾルバーが、 DIDメソッドから返されたDID 文書および DID文書メタデータを検証する何らかの方法を持っていれば、 検証可能解決を 達成できることがある。
  • たとえば、ブロックチェーンベースの DID メソッドでは、ブロックチェーンのフルノードへの直接アクセスが利用できない場合でも、 メタデータを処理してデータを検証するライトクライアントを使用することで、 検証可能解決がなお可能な場合がある。

検証不能解決にはそのような保証がなく、 したがって、たとえば次のように望ましさは低い。

• 検証不能解決は、 検証可能データレジストリへの アクセスが、信頼されていないリモートの仲介者を介して行われる場合に発生する。
  • たとえば、ブロックチェーンベースの DID メソッドの場合、第三者が運用するリモートのブロックチェーンエクスプローラー APIを使用して、ブロックチェーンからデータを検索することがある。

検証可能解決を可能にするために、多くのDIDメソッドは デジタル署名、状態証明、Merkle木への包含証明、暗号学的イベントログ、またはその他の 種類の証明を使用する。DIDメソッドが そのような証明を使用する場合、そのDIDメソッド仕様において、それらが "Resolve"操作の結果の正確性を検証するためにどのように使用されるかを指定しなければ MUSTならない。

DIDメソッドは、 そのような証明を DID文書 自体に含めても、または DID文書メタデータのproofプロパティに含めても MAYよい。 これにより、クライアントは、 DID解決 プロセスの結果を、DIDリゾルバーを信頼していない場合でも、 独立して検証できる可能性がある。

DIDメソッド由来の証明は DIDメソッド固有であり、 適用されるDIDメソッドの技術の範囲内で 理解されなければならないことに注意すること。 DID文書 またはDID文書メタデータ上の単純な署名は、 必ずしもDIDの制御を証明するものでも、 DID文書が そのDIDに 対して正しいものであることを保証するものでもない。 これらの証明は、 DID解決プロセスの結果の完全性および 真正性を、DIDメソッド 自体に関する限りで検証する助けとなる。しかし、 クライアントと DIDリゾルバーとの間の バインディングが 安全であることは保証しない。8.2 リゾルバー アーキテクチャも参照。

DID 解決および DID URL 参照解決のアルゴリズムは、抽象関数として定義される（ 4. DID解決および5. DID URL参照解決を参照）。

これらのアルゴリズムは、DIDリゾルバーおよび DID URL 参照解決器によって実装され、 クライアントから バインディングを介して呼び出される。 バインディングは、抽象関数に具体的なプログラミングインターフェイスまたは 通信インターフェイスを使用してアクセスする方法を定義する。

バインディングの例には次が含まれる。

• DIDリゾルバーは、 ソフトウェアライブラリまたはSDKを呼び出すことにより、アプリケーション内で 呼び出されることがある。
• DIDリゾルバーは、 コマンドラインツールとして呼び出されることがある。
• DIDリゾルバーは、 HTTP(S) APIまたはその他のネットワークプロトコルを介して呼び出されることがある。 たとえば12.1 HTTP(S)バインディングを参照。

上記の考慮事項とバインディングの性質を組み合わせると、 クライアントと DIDリゾルバーまたはDID URL 参照解決器との相互作用は、 ローカルバインディングまたは リモートバインディングのいずれかと見なされ得る。

可能な場合は常に、ローカルバインディングが望ましい。これは、 第三者および仲介者への依存を最小化し、セキュリティリスクを低減し、 DID 解決およびDID URL参照解決 関数の結果の完全性および正確性への信頼を最大化するためである。

場合によっては、 ローカルバインディングを使用できないことがある。 たとえば、制約のあるIoT（Internet of Things）環境、または DIDメソッドが複雑な インフラストラクチャを必要とする場合、または多くの異なる DIDメソッドに 対応する必要がある場合である。

クライアントが リモートバインディングを使用する場合、 次の考慮事項が適用される。

• リモートバインディングは、 信頼されたDIDリゾルバーの インスタンスを使用すべきSHOULDであり、 理想的にはクライアント 自身の管理下にあるもの（例: セルフホスト）である。
• リモートバインディングは、VPN および/または相互認証付きTLSなどの安全なチャネルを使用すべき SHOULDである。
• クライアントは、 リモートバインディングを介して複数の DIDリゾルバーに 問い合わせ、結果を比較できる。

DIDリゾルバーは、 DID解決メタデータの proofプロパティに証明を含めてもMAYよい。

DIDリゾルバー由来の証明は、 DID メソッドに依存せず、すべてのDIDメソッドにわたって DIDリゾルバーにより 普遍的に適用できることに注意すること。これらの証明は、 DID解決 プロセスの結果の完全性および真正性を、 DIDリゾルバー自体に 関する限りで検証する助けとなる。しかし、適用される DIDメソッドの "Resolve"操作から得られる結果自体が正しいことは保証しない。 8.1 メソッドアーキテクチャも参照。

8.2.1 複数のメソッド

DIDリゾルバーは、 複数の DIDメソッドについて DID解決 アルゴリズムに対応することがある。

この場合、 8.1 メソッドアーキテクチャにおける 検証可能解決および検証不能解決 実装に関する上記の考慮事項は、対応する各 DIDメソッドに 個別に適用される。

8.2.2 プロキシされた解決

DIDリゾルバーは、 4. DID 解決で定義される DID解決 アルゴリズムを実行するプロキシとして機能する、別の DIDリゾルバーを 呼び出してもMAYよい。

その場合、最初のDID リゾルバーは クライアントとして 振る舞い、2番目の DIDリゾルバーを 呼び出すために適切な バインディングを選択する。 たとえば、DID リゾルバーは ローカルバインディング（コマンドライン ツールなど）を介して呼び出され、そのDIDリゾルバーがさらに リモートバインディング（ HTTP(S)バインディングなど）を介して別の DIDリゾルバーを 呼び出すことがある。

プロキシされた解決を使用する場合、"下流"リゾルバーは、 "上流"リゾルバーからのすべての DID解決メタデータおよび DID文書メタデータを、存在する可能性のある証明を含め、 透明な方法で保持すべきSHOULDである。このプロセスにおいて、 "下流"リゾルバーは、プロキシされた解決プロセス自体に関する任意のメタデータを含む、 独自のDID解決メタデータを追加しても MAYよい。

注記: DNSとの比較

これは、DNSアーキテクチャにおいて"スタブリゾルバー"が"再帰リゾルバー"を 呼び出すことに類似している。ただし、概念は完全に比較可能ではない （DNS Resolutionは単一の具体的なプロトコルを使用するのに対し、 DID解決は異なるDIDメソッドおよび異なる バインディングによって実現される抽象関数である）。

DID URL did:xyz:1234#keys-1が与えられた場合、 リソースの参照解決 （すなわちDID 文書）のために、 DIDリゾルバーが ローカルバインディングを介して呼び出され、 クライアントが フラグメントの参照解決 （すなわちDID文書の一部）によって DID URL 参照解決アルゴリズムを完了できる。

DID URL did:xyz:1234?service=agent&relativeRef=%2Fsome%2Fpath%3Fquery#fragが与えられた場合、 リソースの参照解決 （すなわちDID サービスエンドポイントURL）のために、 DIDリゾルバーが 呼び出され、 クライアントが フラグメントの参照解決 （すなわちフラグメントを持つDID サービスエンドポイントURL）によって DID URL 参照解決アルゴリズムを完了できる。

DID URL did:xyz:1234#keys-1が与えられた場合、 DIDリゾルバーが ローカルバインディングを介して呼び出され、 それがさらにリモートバインディングを介して別の DID リゾルバーを呼び出して リソースの参照解決 （すなわちDID 文書）を行い、 クライアントが フラグメントの参照解決 （すなわちDID文書の一部）によって DID URL 参照解決アルゴリズムを完了できる。

この節では、 DIDリゾルバー バインディングを 定義する。このバインディングは、 DID解決 および/またはDID URL 参照解決関数 （すべての解決/参照解決オプションおよびメタデータを含む）を、HTTP(S) エンドポイントを介して公開する。8.2 リゾルバー アーキテクチャを参照。

HTTP(S)バインディングは、 DIDリゾルバーを 呼び出すことができる既知のHTTP(S) URLを必要とする。このURLは DIDリゾルバー HTTP(S)エンドポイントと呼ばれる。

このバインディングは一般に リモートバインディングと見なされるが、HTTP(S)エンドポイントが localhost上などのローカル環境で実行される場合には、 ローカルバインディングでもあり得る。

すべての適合DIDリゾルバーは、 HTTPS バインディングのGET版を実装しなければMUSTならず、 POST版を実装してもMAYよい。すべてのHTTPS バインディングはTLSを使用しなければMUSTならない。 証明書でDNS名を使用することはNOT REQUIREDであり、 リゾルバーはIPアドレスに対して発行されたTLS証明書を使用してもMAYよい。

このバインディングを使用して、 DID解決関数（ 4. DID解決を参照）および/または DID URL 参照解決関数 （5. DID URL参照解決を参照）は、 次のように実行できる。

1. 要求HTTP(S) URLを DID リゾルバーHTTP(S)エンドポイントで初期化する。
   例 23

   https://resolver.example/1.0/identifiers/

2. DID 解決関数について:
   1. 入力DIDを 要求HTTP(S) URLに追加する。
      例 24

      https://resolver.example/1.0/identifiers/did:example:1234

   2. 完全な 9. DID解決 結果を要求するために、 AcceptHTTP要求ヘッダーを application/did-resolutionに設定する、または
   3. 結果のdidDocument値のみを要求するために、 AcceptHTTP要求ヘッダーを accept解決オプションの値に設定する。
3. DID URL参照解決関数について:
   1. 入力DID URLを 要求HTTP(S) URLに追加する。
      例 25

      https://resolver.example/1.0/identifiers/did:example:1234?service=files&relativeRef=/resume.pdf

   2. 完全な 10. DID URL 参照解決結果を要求するために、 AcceptHTTP要求ヘッダーを application/did-url-dereferencingに設定する、または
   3. 結果の contentStream値のみを要求するために、 AcceptHTTP要求ヘッダーを accept 参照解決オプションの値に設定する。
4. HTTP(S) GETバインディングについて:
   1. accept以外の解決オプションまたは 参照解決オプションが提供されている場合:
      1. 入力DIDは、 （RFC3986第2.1節で 指定されるように）URLエンコードされなければ MUSTならない。
      2. acceptを除くすべての解決オプションを、 要求HTTP(S) URL内のクエリパラメーターとしてエンコードする。
   2. 要求HTTP(S) URLに対してHTTP GET要求を実行する。 これは、リモート DID リゾルバーにおける DID 解決または DID URL参照解決関数を呼び出す。
      例 26

      GET https://resolver.example/1.0/identifiers/did%3Aexample%3A1234?option1=value1&option2=value2 HTTP/1.1
      Accept: application/did-resolution

      例 27

      GET https://resolver.example/1.0/identifiers/did%3Aexample%3A1234%3Fservice%3Dfiles%26relativeRef%3D%2Fresume.pdf?option1=value1&option2=value2 HTTP/1.1
      Accept: application/did-url-dereferencing

5. HTTP(S) POSTバインディングについて:
   1. accept以外の解決オプションまたは 参照解決オプションが提供されている場合:
      1. acceptを除くすべての解決オプションを、 HTTP要求のPOST本文内のJSON構造としてエンコードする。
   2. 要求HTTP(S) URLに対してHTTP POST要求を実行する。 これは、リモート DID リゾルバーにおける DID 解決または DID URL参照解決関数を呼び出す。
      例 28

      POST https://resolver.example/1.0/identifiers/did:example:1234 HTTP/1.1
      Accept: application/did-resolution
      
      {
      "option1": "value1",
      "option2": "value2"
      }

      例 29

      POST https://resolver.example/1.0/identifiers/did:example:1234?service=files&relativeRef=/resume.pdf HTTP/1.1
      Accept: application/did-url-dereferencing
      
      {
      "option1": "value1",
      "option2": "value2"
      }

6. DID 解決または DID URL 参照解決関数が、 didResolutionMetadataまたはdereferencingMetadata内で errorメタデータプロパティを返す場合、 HTTP応答ステータスコードは、次の表に従って エラーオブジェクトのtypeプロパティに対応しなければ MUSTならない。

   error type URI	HTTPステータスコード
   https://www.w3.org/ns/did#INVALID_DID	400
   https://www.w3.org/ns/did#INVALID_DID_URL	400
   https://www.w3.org/ns/did#INVALID_OPTIONS	400
   https://www.w3.org/ns/did#NOT_FOUND	404
   https://www.w3.org/ns/did#REPRESENTATION_NOT_SUPPORTED	406
   https://www.w3.org/ns/did#INVALID_DID_DOCUMENT	500
   https://www.w3.org/ns/did#METHOD_NOT_SUPPORTED	501
   https://www.w3.org/ns/did#FEATURE_NOT_SUPPORTED	501
   https://www.w3.org/ns/did#INTERNAL_ERROR	500
   （その他の任意のエラーURI）	500

7. DID 解決または DID URL 参照解決関数が、 didDocumentMetadataまたは contentMetadata内で、値 trueを持つ deactivatedメタデータプロパティを返す場合:
   1. HTTP応答ステータスコードは410でなければMUSTならない。
8. DID 解決関数について:
   1. Content-Type HTTP応答ヘッダーの値がapplication/did-resolutionである場合:
      1. HTTP本文は、 DID解決結果（ 9. DID 解決結果を参照）であって、 DID解決 関数の結果であるものを含まなければ MUSTならない。
   2. 関数が成功し、didDocumentを返す場合:
      1. HTTP応答ステータスコードは200でなければMUSTならない。
      2. HTTP応答はContent-Type HTTP応答ヘッダーを含まなければMUSTならない。 その値は、 didResolutionMetadata内の contentTypeメタデータプロパティの値でなければ MUSTならない（ 4.2 DID 解決メタデータを参照）。
      3. HTTP応答本文は、 DID解決 関数の結果である didDocumentを、 Content-TypeHTTP応答ヘッダーに対応する 表現で含まなければMUSTならない。
9. DID URL参照解決関数について:
   1. Content-TypeHTTP応答ヘッダーの値が application/did-url-dereferencingである場合:
      1. HTTP本文は、 DID URL参照解決結果 （10. DID URL参照解決結果を参照）であって、 DID URL 参照解決関数の結果であるものを含まなければ MUSTならない。
   2. 関数が成功し、 contentStreamと、値text/uri-listを持つ contentTypeメタデータプロパティを dereferencingMetadata内に返す場合:
      1. HTTP応答ステータスコードは303でなければMUSTならない。
      2. HTTP応答は Locationヘッダーを含まなければMUSTならない。 このヘッダーの値は、選択済みDIDサービス エンドポイントURLでなければMUSTならない。
      3. HTTP応答本文は空でなければMUSTならない。
   3. 関数が成功し、その他の任意のcontentTypeを持つ contentStreamを返す場合:
      1. HTTP応答ステータスコードは200でなければMUSTならない。
      2. HTTP応答はContent-Type HTTP応答ヘッダーを含まなければMUSTならない。 その値は、 dereferencingMetadata内の contentTypeメタデータプロパティの値でなければ MUSTならない（ 5.2 DID URL参照解決メタデータを参照）。
      3. HTTP応答本文は、 DID URL 参照解決関数の結果である contentStreamを、 Content-TypeHTTP応答ヘッダーに対応する 表現で含まなければMUSTならない。

次の DIDリゾルバー HTTP(S)エンドポイントが与えられた場合:

https://resolver.example/1.0/identifiers/

そして次の 入力DIDが 与えられた場合:

did:example:123

その場合、要求HTTP(S) URLは次のとおりである。

https://resolver.example/1.0/identifiers/did:example:123

GET https://resolver.example/1.0/identifiers/did:example:123 HTTP/1.1
Accept: application/did-resolution

HTTP 200 OK
Content-Type: application/did-resolution

{
	"didDocument": {
		"@context": [ "https://www.w3.org/ns/did/v1.1" ],
		"id": "did:example:123",
		"verificationMethod": [{
			...
		}],
		"service": [{
			...
		}]
	},
	"didResolutionMetadata": {
		"contentType": "application/did"
	},
	"didDocumentMetadata": {
		...
	}
}

GET https://resolver.example/1.0/identifiers/did:example:123 HTTP/1.1
Accept: application/did

HTTP 200 OK
Content-Type: application/did

{
	"@context": [ "https://www.w3.org/ns/did/v1.1" ],
	"id": "did:example:123",
	"verificationMethod": [{
		...
	}],
	"service": [{
		...
	}]
}

DID解決および DID URL 参照解決には、 認証または認可機能は含まれない。DNS解決と同様に、誰でも資格情報や非公開の知識を 必要とせずにこのプロセスを実行できる。

DIDリゾルバーは、 DID文書の 汎用キャッシュを保持することがある。また、特定の DIDメソッドに 固有のキャッシュを保持することもある。

noCache解決オプションは、特定の種類のキャッシュ動作を要求するために 使用できる。

この解決オプションはOPTIONALである。

このプロパティの可能な値は次のとおりである。

• "false"（既定値）: DID文書のキャッシュが許可される。
• "true": キャッシュを無効化し、新鮮な DID文書を 検証可能データ レジストリから取得するよう要求する。

キャッシュ動作は、 DIDリゾルバーの 設定、noCache解決オプション、またはDID 文書の内容（例: cacheMaxTtlフィールド）、あるいはこれらの プロパティの組み合わせによって制御できる。

noCacheを実装するリゾルバーは、悪意あるクライアントがキャッシュを迂回して 高コストのネットワーク要求およびリソース消費を強制できるため、サービス拒否攻撃に対して より脆弱になる可能性がある。noCacheを用いて解決を要求するクライアントは、 一部のリゾルバーがキャッシュを迂回する解決要求を拒否することを想定する。 キャッシュなしの解決を拒否するリゾルバーは、キャッシュの迂回が許可されなかったことを 明確に示すFEATURE_NOT_SUPPORTEDエラーで応答しなければ MUSTならない。これにより、クライアントはnoCacheを使用せずに 解決を試みることができる。

JSON-LD Context ファイルがリモートの場所から取得される場合、攻撃者がコンテキスト ファイルを改変する可能性がある（たとえば、サーバーを侵害すること、または 中間者攻撃により要求を傍受することによって）。

したがって、JSON-LD Context URLのリモート取得を実行する DID リゾルバーは、エンドツーエンドのセキュリティを確保する助けとして、 コンテキストファイルおよび対応するハッシュのレジストリ（または機能的に同等の仕組み）を 使用することが強く推奨される。実装は、リソースの暗号学的ハッシュ値が 期待されるハッシュ値と一致しない場合、エラーを投げることが期待される。

versionIdまたは versionTimeDID パラメーターが提供された場合、DID解決アルゴリズムは、 DID文書の特定のバージョンを返す。

DIDパラメーターversionIdおよび versionTimeは相互に排他的である。

versionId DIDパラメーターの使用は、DIDメソッドに固有である。 その可能な値には、連番、ランダムUUID、コンテンツハッシュなどが含まれ得る。

DID文書メタデータは、DID文書に対して実行される各 Update 操作ごとに変化するversionIdプロパティを含んでも MAYよい。

分散システム（分散台帳など）をVDR（検証可能データレジストリ）として 使用するDIDメソッドは、 ネットワークフォークが発生する可能性を管理する必要がある。したがって、 分散システムをVDRとして使用する DIDメソッドの仕様は、 使用しているVDRをそのようなフォークから曖昧さなく識別する手段を指定すべき SHOULDである。

DID URL 参照解決器クライアントが、 DID文書内の識別子およびリンクされた リソース、特にverificationMethod、controller、 またはalsoKnownAsなどのフィールドを参照解決する場合、 参照解決の循環に遭遇することがある。 これは、DID文書が 別のDID（またはURL）を参照し、それが最終的に以前に参照解決された識別子に 戻ってループを形成する場合に発生することがある。 DID URL参照解決器は、 DIDサービスエンドポイントを 参照するDID URLを 参照解決する場合にも、そのような状況に遭遇することがある。

did:example:alice
	└── verificationMethod.controller → did:example:bob
		└── verificationMethod.controller → did:example:alice

再帰的な参照解決を実行するDID URL 参照解決器およびそのクライアントは、 そのような循環を想定し、検出し、処理することが期待される。

セキュリティおよび性能上のリスク: 循環が検出されず緩和されない場合、 再帰的な参照解決は次につながる可能性がある。

• ソフトウェア内の無限ループまたは スタックオーバーフロー。
• リソース枯渇（例: メモリ、ネットワーク、または CPU）。
• クライアントまたは仲介者における サービス拒否（DoS）脆弱性。

緩和の指針: 外部のDID 文書参照を再帰的にたどるコンポーネントは、 すでに参照解決された識別子を追跡し、循環が発生したときに検出して 適切な処置を取ることが推奨される。さらに、開発者は潜在的な攻撃対象領域を減らすために、 再帰の深さまたは幅を制限したい場合がある。

DIDリゾルバーおよび DID URL 参照解決器は、 解決および参照解決のための自サービスへの要求をログに記録できる。 時間の経過とともに、これらのログは、それらのサービスに要求を行うクライアントを 追跡およびプロファイリングするために使用される可能性がある。このプライバシーリスクを 緩和するため、クライアントは、たとえば既存のビジネス関係がある、またはそのサービスが 自身の管理下にあるインフラストラクチャ上で実行されているなどの理由で、 信頼するサービスにそのような要求を行うべきである。

クライアントは、相関およびプロファイリングの可能性を低減するために、 サービスへの要求を難読化する手段を取ることもできる。難読化の技術には、 Oblivious HTTP、信頼されたプロキシを使用して解決要求を実行すること、および 信頼されたキャッシュを使用することが含まれる。

DIDメソッドごとに、設計上の判断およびそのメソッドの基礎となるVDRに応じて、 異なる追加のプライバシー上の含意および考慮事項がある。実装者は、 サポートしようとする特定のDIDメソッドのプライバシー上の考慮事項を確認することが 推奨される。DIDメソッドの設計者には、 実装者がそのメソッド設計のプライバシー上の含意を理解する助けとなる脅威モデルを作成するため、 W3C Threat Modeling Guideに従うことが 推奨される。