分散型識別子（DID）v1.1

概要

分散型識別子（DID）は、検証可能で分散型のデジタル・アイデンティティを可能にする新しい種類の識別子である。DIDは、 DIDのコントローラによって決定される任意の主体（例：人、組織、物、データモデル、抽象的実体など）を参照する。典型的な連合型識別子とは対照的に、 DIDは、中央集権的なレジストリ、アイデンティティ・プロバイダ、および認証局から切り離せるように設計されている。具体的には、 DIDに関連する情報の発見を可能にするために他の当事者が利用される場合がある一方で、この設計は DIDのコントローラが、他のいかなる当事者からの許可も必要とせずに、そのDIDに対する制御を証明できるようにする。 DIDは、 URI であり、DID主体をDID文書と関連付け、その主体に関連する信頼可能なやり取りを可能にする。

各DID文書は、暗号材料、検証メソッド、またはサービスを表現でき、それらは DIDコントローラがDIDの制御を証明できるようにする一連の機構を提供する。サービスは、 DID主体に関連する信頼できるやり取りを可能にする。DIDは、 DID主体がデータモデルなどの情報資源である場合、 DID主体そのものを返す手段を提供することがある。

この文書は、DID構文、共通データモデル、中核プロパティ、シリアライズされた表現、DID操作、および DIDをそれらが表す資源へ解決するプロセスの説明を規定する。

この節は非規範的である。

個人としても組織としても、私たちの多くは、非常に幅広い文脈でグローバルに一意な識別子を使用している。それらは、通信アドレス（電話番号、メールアドレス、ソーシャルメディア上のユーザー名）、ID番号（パスポート、運転免許証、納税者番号、健康保険）、および製品識別子（シリアル番号、バーコード、RFID）として機能する。URI（Uniform Resource Identifiers）は Web上の資源に使用され、ブラウザで閲覧する各Webページには、グローバルに一意な URL（Uniform Resource Locator）がある。

これらのグローバルに一意な識別子の大多数は、私たちの制御下にはない。それらは、それが誰または何を参照するのか、いつ失効させられるのかを決定する外部機関によって発行される。それらは特定の文脈でのみ有用であり、私たちが選んだわけではない特定の団体によってのみ認識される。組織の破綻によって、それらは消滅したり有効でなくなったりする可能性がある。それらは個人情報を不必要に明らかにする可能性がある。多くの場合、それらは悪意のある第三者によって不正に複製され主張される可能性があり、これは一般に「アイデンティティ窃盗」として知られている。

この仕様で定義される分散型識別子（DID）は、新しい種類のグローバルに一意な識別子である。それらは、個人および組織が、自分たちが信頼するシステムを使用して独自の識別子を生成できるように設計されている。これらの新しい識別子は、デジタル署名などの暗号学的証明を用いて認証することにより、エンティティがそれらに対する制御を証明できるようにする。

分散型識別子の生成および主張はエンティティによって制御されるため、各エンティティは、アイデンティティ、ペルソナ、およびやり取りの望ましい分離を維持するために必要な数だけ DIDを持つことができる。これらの識別子の使用は、異なる文脈に応じて適切にスコープ化できる。それらは、エンティティが自分自身、または自分が制御する物を識別する必要がある他の人々、機関、またはシステムとのやり取りをサポートし、識別子の継続的な存在を保証する中央機関に依存することなく、どれだけの個人データまたは私的データを明らかにすべきかを制御できるようにする。これらの考え方は、DIDユースケース文書 [DID-USE-CASES] で検討されている。

この仕様は、DIDの生成、永続性、解決、または解釈を支える特定の技術または暗号方式を前提としない。たとえば、実装者は、連合型または中央集権型のアイデンティティ管理システムに登録された識別子に基づいて分散型識別子を作成できる。実際、ほぼすべての種類の識別子システムは DIDのサポートを追加できる。これにより、中央集権型、連合型、および分散型の識別子の世界の間に相互運用性の橋渡しが作られる。また、実装者は、分散台帳、分散型ファイルシステム、分散データベース、ピアツーピア・ネットワークなど、自分たちが信頼する計算インフラストラクチャで動作する特定の種類のDIDを設計できるようになる。

この仕様は、次の人々のためのものである:

分散型識別子の基盤となる中核的なアーキテクチャ原則を理解したい人。
分散型識別子およびそれらに関連するデータ形式を生成および消費したいソフトウェア開発者。
自分たちのソフトウェアおよびハードウェアシステムで分散型識別子をどのように使用するかを理解したいシステムインテグレータ。
この文書で説明されるエコシステムに適合するDIDメソッドとして知られる新しいDIDインフラストラクチャを作成したい仕様作成者。

この仕様に加えて、読者は分散型識別子のユースケースと要件 [DID-USE-CASES] 文書も有用だと考えるかもしれない。

この節は非規範的である。

DIDは、3つの部分からなる単純なテキスト文字列である: 1) did URIスキーム識別子、2) DIDメソッドの識別子、 3) DIDメソッド固有の識別子。

DIDの各部分を示す図。最も左の文字は青色で「did」と綴られており、
上から水平の括弧で囲まれ、その括弧の上に「scheme」と書かれたラベルがある。
「did」の文字の後には灰色のコロンが続く。中央の文字はマゼンタ色で
「example」と綴られており、下から水平の括弧で囲まれ、その括弧の下に
「DID Method」と書かれたラベルがある。DID Methodの後には灰色のコロンが続く。
最後の末尾の文字は緑色で「123456789abcdefghi」と書かれており、下から水平の括弧で囲まれ、
その括弧の下に「DID Method Specific String」と書かれたラベルがある。 — 図 1 分散型識別子（DID）の単純な例

上の例のDIDは、DID文書へ解決される。DID文書には、 DIDに関連する情報、たとえば DIDコントローラを暗号学的に認証する方法などが含まれる。

例 1: 単純なDID文書

{
  "@context": "https://www.w3.org/ns/did/v1.1",
  "id": "did:example:123456789abcdefghi",
  "authentication": [{
    // did:...fghi として認証するために使用される
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Multikey",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
  }]
}

この節は非規範的である。

分散型識別子は、 Verifiable Credentialsエコシステム [VC-DATA-MODEL] などのより大きなシステムの構成要素であり、これはこの仕様の設計目標に影響を与えた。分散型識別子の設計目標をここに要約する。

目標	説明
分散化	グローバルに一意な識別子、公開検証鍵、サービス、およびその他の情報の登録を含む、識別子管理における中央集権的な機関または単一障害点の要件を排除する。
制御	人間および非人間の双方のエンティティに、外部機関に依存する必要なく、自らのデジタル識別子を直接制御する能力を与える。
プライバシー	属性またはその他のデータの最小限の開示、選択的開示、段階的開示を含め、エンティティが自分の情報のプライバシーを制御できるようにする。
セキュリティ	要求者が、必要な保証レベルに応じてDID文書に依拠できるだけの十分なセキュリティを可能にする。
証明ベース	DIDコントローラが、他のエンティティとやり取りする際に暗号学的証明を提供できるようにする。
発見可能性	エンティティが、他のエンティティについてさらに知ったり、またはそれらとやり取りしたりするために、他のエンティティのDIDを発見できるようにする。
相互運用性	DIDインフラストラクチャが、相互運用性のために設計された既存のツールおよびソフトウェアライブラリを利用できるように、相互運用可能な標準を使用する。
移植性	システムおよびネットワークから独立しており、エンティティがDIDおよびDIDメソッドをサポートする任意のシステムで自分のデジタル識別子を使用できるようにする。
単純性	技術を理解、実装、展開しやすくするため、簡潔な機能の縮小された集合を優先する。
拡張性	可能な場合には、相互運用性、移植性、または単純性を大きく妨げない限り、拡張性を可能にする。

この節は非規範的である。

この節は、分散型識別子アーキテクチャの主要な構成要素の基本的な概要を示す。

DIDとDID文書は検証可能データレジストリに記録される。DIDはDID文書へ解決される。
DIDはDID主体を参照する。DIDコントローラはDID文書を制御する。
DID URLはDIDを含む。DID URLはDID文書の断片または外部資源へ参照解除される。 — 図 2 DIDアーキテクチャと基本構成要素の関係の概要。関連項目: 説明的な記述。

図には、内部ラベル付きの6つの形状が現れ、それらの間にラベル付きの矢印がある。それらは次のとおりである。図の中央にはDID URLとラベル付けされた長方形があり、その中に小さな等幅テキストで「did:example:123/path/to/rsrc」と書かれている。図の中央上部には「DID」とラベル付けされた長方形があり、小さな等幅テキストで「did:example:123」と書かれている。図の左上には「DID Subject」とラベル付けされた楕円がある。下部中央には「DID document」とラベル付けされた長方形がある。左下には「DID Controller」とラベル付けされた楕円がある。図の中央右には、「Verifiable Data Registry」とラベル付けされた円柱の二次元表現がある。

「DID URL」長方形の上部から「contains」とラベル付けされた矢印が上方に伸び、「DID」長方形を指している。「DID URL」長方形の下部からは、「refers, and dereferences, to」とラベル付けされた矢印が下方に伸び、「DID document」長方形を指している。「DID」長方形からは「resolves to」とラベル付けされた矢印が下方に向かい、「DID document」長方形を指している。「DID」長方形からは「refers to」とラベル付けされた矢印が左に向かい、「DID subject」楕円を指している。「DID controller」楕円からは「controls」とラベル付けされた矢印が右に向かい、「DID document」長方形を指している。「DID」長方形からは「recorded on」とラベル付けされた矢印が右下方向に向かい、「Verifiable Data Registry」円柱を指している。「DID document」長方形からは、「recorded on」とラベル付けされた矢印が右上方向に向かい、「Verifiable Data Registry」円柱を指している。

DIDとDID URL: 分散型識別子、すなわちDIDは、3つの部分で構成される URIである: スキームdid:、メソッド識別子、およびDIDメソッドにより指定される一意でメソッド固有の識別子。DIDは、 DID文書へ解決可能である。 DID URLは、特定の資源、たとえばDID文書内の暗号学的公開鍵、または DID文書の外部にある資源を位置付けるために、path、query、fragmentなどの他の標準的な URI構成要素を組み込むよう、基本的な DIDの構文を拡張する。これらの概念は、3.1 DID構文および 3.2 DID URL構文で詳述される。
DID主体: DIDの主体とは、定義上、そのDIDによって識別されるエンティティである。 DID主体は、 DIDコントローラでもあり得る。何であってもDIDの主体になり得る: 人、グループ、組織、物、または概念である。これは5.1.1 DID 主体でさらに定義される。
DIDコントローラ: コントローラとは、 DIDについて、 DIDメソッドにより定義されるとおり、DID文書に変更を加える能力を持つエンティティ（人、組織、または自律的ソフトウェア）である。この能力は、通常、コントローラの代理として動作するソフトウェアによって使用される暗号鍵の集合の制御によって主張されるが、他の機構によって主張されることもある。DIDは複数のコントローラを持つ場合があり、 DID主体はDID コントローラ、またはその1つであり得ることに注意。この概念は5.1.2 DID コントローラで文書化されている。
検証可能データレジストリ: DID文書へ解決可能であるために、 DIDは通常、何らかの基盤となるシステムまたはネットワークに記録される。使用される具体的な技術にかかわらず、DIDの記録、およびDID 文書を生成するために必要なデータの返却をサポートするそのようなシステムは、検証可能データレジストリと呼ばれる。例には、分散台帳、分散型ファイルシステム、あらゆる種類のデータベース、ピアツーピア・ネットワーク、およびその他の形式の信頼できるデータストレージが含まれる。この概念は 7. メソッドでさらに詳述される。
DID文書: DID文書には、DIDに関連する情報が含まれる。それらは通常、暗号学的公開鍵などの検証メソッド、および DID主体とのやり取りに関連するサービスを表現する。 DID文書でサポートされる汎用プロパティは、 5. 中核プロパティで規定される。DID文書はバイトストリームへシリアライズできる（6. 表現を参照）。DID文書に存在するプロパティは、 7. メソッドで概説される適用可能な操作に従って更新できる。
DIDメソッド: DIDメソッドは、特定の種類の DIDおよびそれに関連する DID文書が作成、解決、更新、および無効化される機構である。 DIDメソッドは、7. メソッドで定義されるとおり、別個の DIDメソッド仕様を使用して定義される。
DIDリゾルバとDID解決: DIDリゾルバは、DIDを入力として受け取り、適合する DID文書を出力として生成するシステム構成要素である。このプロセスは DID解決と呼ばれる。特定の種類の DIDを解決する手順は、関連するDIDメソッド仕様によって定義される。 DID解決のプロセスは、[DID-RESOLUTION] で詳述される。
DID URL参照解除器とDID URL参照解除: DID URL参照解除器は、 DID URLを入力として受け取り、資源を出力として生成するシステム構成要素である。このプロセスはDID URL参照解除と呼ばれる。 DID URL参照解除のプロセスは、 [DID-RESOLUTION] で詳述される。

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

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

この文書には、JSONおよびJSON-LDコンテンツを含む例が含まれている。これらの例の一部には、インラインコメント（//）や、例にほとんど価値を加えない情報を示すための省略記号（...）の使用など、無効な文字が含まれている。実装者は、その情報を有効なJSONまたはJSON-LDとして使用したい場合には、この内容を削除するよう注意されたい。

一部の例には、この仕様で定義されていない用語、すなわちプロパティ名および値の両方が含まれている。これらはコメント（// external (property name|value)）で示される。そのような用語は、DID文書で使用される場合、正式な定義とJSON-LDコンテキストの両方へのリンクとともに、DID拡張のリポジトリ [DID-EXTENSIONS] に登録されることが期待される。

DIDおよびDID文書の実装の相互運用性は、この仕様に適合するDIDおよびDID文書を作成および解析する実装の能力を評価することによってテストされる。DIDおよびDID文書の生成者と消費者の相互運用性は、 DIDおよびDID文書が適合することを保証することで提供される。 DIDメソッド仕様の相互運用性は、各DIDメソッド仕様内の詳細によって提供される。Webブラウザが既知のすべてのURIスキームを実装する必要がないのと同じように、 DIDを扱う適合ソフトウェアも、既知のすべてのDIDメソッドを実装する必要はないと理解される。ただし、あるDIDメソッドのすべての実装は、そのメソッドについて相互運用可能であることが期待される。

適合DIDとは、3. 識別子で規定される規則の任意の具体的表現であり、その節の関連する規範的記述に準拠するものである。

適合 DID文書とは、この仕様で説明されるデータモデルの任意の具体的表現であり、 4. データモデルおよび5. 中核プロパティの関連する規範的記述に準拠するものである。適合文書のシリアライズ形式は、 6. 表現で説明されるように、決定的で、双方向で、損失がない。

適合生成者とは、ソフトウェアおよび/またはハードウェアとして実現され、適合DIDまたは適合DID文書を生成し、 6. 表現の関連する規範的記述に準拠する任意のアルゴリズムである。

適合消費者とは、ソフトウェアおよび/またはハードウェアとして実現され、適合DIDまたは適合DID文書を消費し、 6. 表現の関連する規範的記述に準拠する任意のアルゴリズムである。

適合DIDメソッドとは、 7. メソッドの関連する規範的記述に準拠する任意の仕様である。

この節は非規範的である。

この仕様には2つの主要な想定読者がいる。適合DIDメソッドの実装者、およびDIDとやり取りしインターフェイスしたいシステムおよびサービスの実装者である。想定読者には、ソフトウェアアーキテクト、データモデラー、アプリケーション開発者、サービス開発者、テスター、運用者、およびユーザー体験（UX）専門家が含まれるが、これらに限定されない。分散型アイデンティティ、Verifiable Credentials、およびセキュアストレージに関連する幅広い標準化活動に関わる他の人々も、この仕様を読むことに関心を持つかもしれない。

この節は非規範的である。

この節は、この仕様および分散型識別子インフラストラクチャ全体で使用される用語を定義する。これらの用語へのリンクは、この仕様内でそれらが現れるたびに含まれる。

増幅攻撃: 攻撃者が、小さく有効な入力をシステムに与えることにより、対象システムのCPU、ストレージ、ネットワーク、またはその他の資源を枯渇させようとする攻撃の分類。その入力は、入力自体よりも指数関数的に処理コストの高い有害な影響を生じさせる。
分散型識別子（DID）: 中央集権的な登録機関を必要とせず、多くの場合、暗号学的に生成および/または登録される、グローバルに一意で永続的な識別子。DIDの汎用形式は3.1 DID構文で定義される。特定のDIDスキームは、 DID メソッド仕様で定義される。多くのDIDメソッドは、すべてではないが、分散台帳技術（DLT）またはその他の形態の分散型ネットワークを利用する。
DID コントローラ: DID文書に変更を加える能力を持つエンティティ。 DIDは複数のDIDコントローラを持つことがある。 DIDコントローラは、 DID文書の最上位にある任意のcontrollerプロパティで示すことができる。 DIDコントローラはDID 主体であり得ることに注意。
DID委任先: DIDコントローラが、検証メソッドを使用する許可を与えたエンティティ。この検証メソッドは、DIDに関連付けられ、DID文書を介する。たとえば、子どものDID文書を制御する親が、子どもに認証のために個人用デバイスを使用することを許可する場合がある。この場合、その子どもがDID委任先である。子どもの個人用デバイスには、その子どもが認証するために必要な秘密の暗号材料が含まれ、 DIDを使用できるようにする。ただし、その子どもは親の許可なく他の個人用デバイスを追加することは許可されない場合がある。
DID文書: DID主体との暗号学的に検証可能なやり取りを可能にするデータの集合。これには、暗号学的公開鍵など、DID主体またはDID委任先が自らを認証し、 DIDとの関連を証明するために使用できる機構が含まれる。 DID文書は、表現を1つ以上持つことがあり、それらは6. 表現または W3C 分散型識別子拡張で定義される。
DIDフラグメント: DID URLのうち、最初の #文字（U+0023 NUMBER SIGN）に続く部分。DIDフラグメント構文は URIフラグメント構文と同一である。
DIDメソッド: 特定のDIDメソッドスキームがどのように実装されるかの定義。 DIDメソッドはDIDメソッド仕様によって定義され、その仕様は、 DIDおよびDID文書が作成、解決、更新、および無効化される正確な操作を規定する。7. メソッドを参照。
DIDパス: DID URLのうち、最初の /文字（U+002F SOLIDUS）で始まり、それを含み、 ?文字（U+003F QUESTION MARK）、 #文字（U+0023 NUMBER SIGN）、またはDID URLの終端のいずれかの前で終わるが、それらを含まない部分。 DIDパス構文はURIパス構文と同一である。パスを参照。
DIDクエリ: DID URLのうち、最初の ?文字（U+003F QUESTION MARK）に続き、それを含む部分。 DIDクエリ構文はURIクエリ構文と同一である。クエリを参照。
DID解決: DIDと解決オプションの集合を入力として受け取り、適合する表現のDID文書に加えて、追加メタデータを返すプロセス。このプロセスは、適用されるDIDメソッドの「Read」操作に依存する。このプロセスの入力と出力は、[DID-RESOLUTION]で定義される。
DIDリゾルバ: DIDリゾルバは、 DIDを入力として受け取り、適合する DID文書を出力として生成することにより、 DID解決機能を実行するソフトウェアおよび/またはハードウェア構成要素である。
DIDスキーム: 分散型識別子の正式な構文。汎用DIDスキームは、3.1 DID構文で定義されるように、接頭辞did:で始まる。各DIDメソッド仕様は、その特定のDIDメソッドで機能する特定のDIDメソッドスキームを定義する。特定のDID メソッドスキームでは、DIDメソッド名は最初のコロンに続き、2番目のコロンで終了する。例: did:example:
DID主体: DIDによって識別され、 DID文書によって記述されるエンティティ。 DID主体には何でもなり得る。人、グループ、組織、物理的な物、デジタルの物、論理的な物などである。
DID URL: DIDに加えて、 3.2 DID URL構文の定義に適合する任意の追加の構文要素。これには、先頭の /文字（U+002F SOLIDUS）を伴う任意のDID パス、先頭の ?文字（U+003F QUESTION MARK）を伴う任意のDIDクエリ、および先頭の #文字（U+0023 NUMBER SIGN）を伴う任意のDIDフラグメントが含まれる。
DID URL参照解除: DID URLと入力メタデータの集合を入力として受け取り、資源を返すプロセス。この資源は、追加メタデータを伴う DID 文書、DID文書内に含まれる二次資源、または DID文書の完全に外部にある資源であり得る。このプロセスは、 DID URL内に含まれる DIDによって示される DID文書を取得するために DID解決を使用する。その後、参照解除プロセスは DID文書に追加処理を行い、 DID URLによって示される参照解除された資源を返すことができる。このプロセスの入力と出力は、 [DID-RESOLUTION]で定義される。
DID URL 参照解除器: 指定されたDID URLまたはDID文書について、 DID URL参照解除機能を実行するソフトウェアおよび/またはハードウェアシステム。
分散台帳（DLT）: イベントを記録するための非中央集権型システム。これらのシステムは、参加者が他者によって記録されたデータに依拠して運用上の判断を行うために十分な信頼を確立する。通常は、異なるノードがコンセンサスプロトコルを使用して、暗号学的に署名されたトランザクションの順序を確認する分散データベースを使用する。デジタル署名されたトランザクションが時間とともに連結されることで、台帳の履歴は事実上不変になることが多い。
資源: [RFC3986]で定義されるように、 URIによって識別されるもの。同様に、任意の資源は、 DIDによって識別される DID主体として機能し得る。
表現: [RFC9110]で定義される、資源の具体的表現: 「指定された資源の過去、現在、または望まれる状態を反映することを意図した情報であり、プロトコルを介して容易に伝達できる形式のもの。表現は、表現メタデータの集合と、潜在的に無制限の表現データのストリームからなる。」DID文書は、 DID主体との暗号学的に検証可能なやり取りを可能にする情報の表現である。 6. 表現を参照。
表現固有エントリ: DID文書内のエントリで、その意味が特定の表現に固有のもの。 4. データモデルおよび 6. 表現で定義される。
サービス: 1つ以上のサービスエンドポイントを介して、 DID主体または関連エンティティと通信またはやり取りするための手段。例には、発見サービス、エージェントサービス、ソーシャルネットワーキングサービス、ファイルストレージサービス、および検証可能クレデンシャル・リポジトリサービスが含まれる。
DIDサービスエンドポイント: HTTP URLなど、サービスが DID主体の代理として動作するネットワークアドレス。
統一資源識別子（URI）: [RFC3986]で定義される、 World Wide Web上のすべての資源の標準識別子形式。DIDはURIスキームの一種である。
検証可能データレジストリ: 分散型識別子および DID文書の作成、検証、更新、および/または無効化を容易にするシステム。検証可能データレジストリは、検証可能クレデンシャルなど、その他の暗号学的に検証可能なデータ構造にも使用されることがある。詳細については、W3C Verifiable Credentials仕様 [VC-DATA-MODEL]を参照。
検証可能タイムスタンプ: 検証可能タイムスタンプにより、第三者は、データオブジェクトが特定の時点に存在していたこと、およびその時点以降に変更または破損されていないことを検証できる。その時点以降にデータ完全性が合理的に変更または破損され得た場合、そのタイムスタンプは検証可能ではない。

上記の用語に加えて、この仕様では、データモデルを形式的に定義するために、[INFRA]仕様の用語も使用する。[INFRA]の用語が使用される場合、たとえば文字列、集合、およびマップなどは、その仕様へ直接リンクされる。

この節は、DIDおよびDID URLの正式な構文を説明する。「汎用」という用語は、ここで定義される構文を、それぞれの仕様で特定の DIDメソッドによって定義される構文と区別するために使用される。 DIDおよび DID URLの作成プロセスとそのタイミングは、7.2 メソッド操作および B.2 DIDの作成で説明される。

汎用DIDスキームは、[RFC3986]に適合する URIスキームである。ABNF 定義を以下に示す。これは [RFC5234]の構文と、対応する ALPHAおよび DIGITの定義を使用する。以下のABNFで定義されていないその他すべての規則名は、 [RFC3986]で定義される。すべてのDIDは、DID構文ABNF規則に MUST適合しなければならない。

DID構文ABNF規則
did = "did:" method-name ":" method-specific-id method-name = 1method-char method-char = %x61-7A / DIGIT method-specific-id = ( idchar ":" ) 1idchar idchar = ALPHA / DIGIT / "." / "-" / "_" / pct-encoded pct-encoded = "%" HEXDIG HEXDIG

DID構文ABNF規則

did                = "did:" method-name ":" method-specific-id
method-name        = 1*method-char
method-char        = %x61-7A / DIGIT
method-specific-id = *( *idchar ":" ) 1*idchar
idchar             = ALPHA / DIGIT / "." / "-" / "_" / pct-encoded
pct-encoded        = "%" HEXDIG HEXDIG

DID構文に関係する DIDメソッドの要件については、 7.1 メソッド構文節を参照。

DID URLは、特定の資源のネットワーク位置識別子である。これは、 DID主体の表現、検証メソッド、サービス、 DID文書の特定の部分、またはその他の資源などを取得するために使用できる。

以下は、[RFC5234]の構文を使用したABNF定義である。これは、3.1 DID構文で定義されるdidスキームの上に構築される。 path-abempty、query、およびfragment構成要素は、 [RFC3986]で定義される。すべてのDID URLは、DID URL構文ABNF規則に MUST適合しなければならない。DIDメソッドは、7.1 メソッド構文で説明されるように、これらの規則をさらに制限できる。

DID URL構文ABNF規則
did-url = did path-abempty [ "?" query ] [ "#" fragment ]

注記: セミコロン文字は将来の使用のために予約されている

セミコロン（;）文字は DID URL構文の規則に従って使用できるが、この仕様の将来の版では、 [MATRIX-URIS]で説明されるように、パラメータのサブ区切り文字として使用される可能性がある。将来の衝突を避けるため、開発者はこれを使用しないことが望ましい。

DIDパスは、汎用URIパスと同一であり、 RFC 3986、第3.3節の path-abempty ABNF規則に適合する。 URIと同様に、パスの意味論は DIDメソッドによって指定でき、さらにそれによって DIDコントローラがそれらの意味論をさらに特殊化できる場合がある。

例 2

did:example:123456/path

DIDクエリは、汎用URIクエリと同一であり、 RFC 3986、第3.4節の query ABNF規則に適合する。

例 3

did:example:123456?versionId=1

注記: 複数のクエリパラメータを含む DID URLの比較を避けること

実装者は、その目的のために特別に設計された仕様がない場合、複数のクエリパラメータを持つDID URLの同等性を比較することを避けるよう強く求められる。この仕様はクエリパラメータの正規化規則を定義せず、 DIDメソッド仕様またはアプリケーション層で定義される任意のクエリパラメータ正規化規則も、普遍的に認識される規則ではない。

DIDフラグメントの構文および意味論は、汎用URI フラグメントと同一であり、RFC 3986、第3.5節の fragment ABNF規則に適合する。

DIDフラグメントは、 DID文書または外部資源へのメソッド非依存の参照として使用される。 DIDフラグメント識別子の例を以下に示す。

例 4: DID文書内の一意な検証メソッド

did:example:123#public-key-1

例 5: DID文書内の一意なサービス

did:example:123#service-5

注記: 表現をまたぐフラグメントの意味論

相互運用性を最大化するため、実装者は DIDフラグメントが表現をまたいで同じ方法で解釈されるようにすることが強く求められる（6. 表現を参照）。たとえば、 JSON Pointer [RFC6901]は DIDフラグメントで使用できるが、非JSONの表現をまたいで同じ方法で解釈されるわけではない。

この節の意味論と互換性があり、その上に重ねられるフラグメント識別子の追加の意味論は、メディアタイプ記述で規定される（E.1 application/did節を参照）。 DIDフラグメントを参照解除する方法については、分散型識別子解決（DID Resolution）v0.3仕様を参照。

相対DID URLとは、DID文書内のURL値であり、 did:<method-name>:<method-specific-id>で始まらないものをいう。より具体的には、 3.1 DID構文で定義されるABNFで始まらない任意のURL値である。このURLは、同じDID 文書内の資源を参照することが期待される。相対DID URLは、相対パス構成要素、クエリパラメータ、およびフラグメント識別子を含んでもMAYよい。

相対DID URL参照を解決する場合、 RFC3986 Section 5: Reference Resolution で規定されるアルゴリズムを使用MUSTしなければならない。 base URI値は、DID主体に関連付けられたDIDである。 5.1.1 DID 主体を参照。schemeはdidである。 authorityは<method-name>:<method-specific-id>の組み合わせであり、 path、query、およびfragment の値は、それぞれパス、クエリ、およびフラグメントで定義される値である。

相対DID URLは、絶対 URLを使用する必要なしに、検証メソッドおよびサービスをDID文書内で参照するためによく使用される。ストレージサイズが考慮事項となる DIDメソッドは、 DID 文書のストレージサイズを削減するために相対URLを使用する場合がある。

例 6: 相対DID URLの例

{
  "@context": "https://www.w3.org/ns/did/v1.1",
  "id": "did:example:123456789abcdefghi",
  "verificationMethod": [{
    "id": "did:example:123456789abcdefghi#key-1",
    "type": "Multikey", // external (property value)
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
  }, ...],
  "authentication": [
    // 上記の検証メソッドを参照するために使用される相対DID URL
    "#key-1"
  ]
}

上記の例では、相対DID URL値は、絶対DID URL値 did:example:123456789abcdefghi#key-1へ変換される。

データ型	考慮事項
マップ	Infra標準で規定される、キーが2回現れない有限の順序付きキー/値ペア列。マップは、 Infra 標準では順序付きマップと呼ばれることもある。
リスト	Infra標準で規定される、アイテムの有限の順序付き列。
集合	Infra標準で規定される、同じアイテムを2回含まないアイテムの有限の順序付き列。集合は、 Infra 標準では順序付き集合と呼ばれることもある。
日時	[XMLSCHEMA11-2] で規定されるdateTimeで表現可能なすべての値を損失なく表現できる日付および時刻の値。
文字列	Infra標準で規定される、人間が読める言語を表すためによく使用されるコード単位の列。
整数	[XMLSCHEMA11-2] で規定される小数部を持たない実数。相互運用性を最大化するため、実装者は RFC8259、第6節: Numbersにおける整数に関する助言に注意することが強く求められる。
倍精度数	[XMLSCHEMA11-2] で規定される、任意の実数を近似するためによく使用される小数部を持つ実数。相互運用性を最大化するため、実装者は RFC8259、第6節: Numbersにおける倍精度数に関する助言に注意することが強く求められる。
真偽値	Infra標準で定義される、 trueまたはfalseのいずれかの値。
null	Infra 標準で定義される、値の欠如を示すために使用される値。

DIDは、 DID文書に関連付けられる。これは、 Controlled Identifiers v1.0で定義される制御識別子文書の拡張である。 DID文書は、データモデルを使用して表現され、表現へシリアライズできる。以下の節では、DID文書内のプロパティを定義する。これには、それらのプロパティが必須であるか任意であるかも含まれる。これらのプロパティは、DID主体とプロパティの値との間の関係を記述する。

以下の表は、この仕様で定義される中核プロパティについて、期待される値、およびそれらが必須かどうかを含む参考情報の参照を含む。表内のプロパティ名は、各プロパティの規範的定義およびより詳細な説明へリンクされている。

注記: 異なる型のマップで使用されるプロパティ名

プロパティ名id、type、および controllerは、制約に違いがあり得る異なる型のマップに存在できる。たとえば、DID文書の最上位にあるidはDIDであることが要求される一方で、 serviceマップ内の idはURLであり得る。

プロパティ	必須?	値の制約	定義
`id`	はい	文字列であり、 3.1 DID構文節で定義される規則に適合するもの。	5.1.1 DID主体節。
`controller`	いいえ	文字列、または集合の文字列であり、それぞれが 3.1 DID構文節で定義される規則に適合するもの。	5.1.2 DIDコントローラ節。
`alsoKnownAs`	いいえ	集合の文字列であり、それぞれがURL構文または 3.1 DID構文節に適合するもの。	Controlled Identifiers v1.0仕様の第2.1.3節: Also Known As。
`service`	いいえ	集合のサービスマップ。	Controlled Identifiers v1.0仕様の第2.1.4節: Services。
`verificationMethod`	いいえ	集合の検証メソッドマップ。	5.2 検証メソッド節。
`authentication`	いいえ	データの集合であり、各要素は文字列で 3.1 DID構文節で定義される規則に適合するもの、またはマップで検証メソッドについて 5.2 検証メソッド節で定義される規則に適合するもののいずれかである。	Controlled Identifiers v1.0仕様の第2.3.1節: Authenticationおよび 5.2 検証メソッド節。
`assertionMethod`	いいえ	データの集合であり、各要素は文字列で 3.1 DID構文節で定義される規則に適合するもの、またはマップで検証メソッドについて 5.2 検証メソッド節で定義される規則に適合するもののいずれかである。	Controlled Identifiers v1.0仕様の第2.3.2節: Assertionおよび 5.2 検証メソッド節。
`keyAgreement`	いいえ	データの集合であり、各要素は文字列で 3.1 DID構文節で定義される規則に適合するもの、またはマップで検証メソッドについて 5.2 検証メソッド節で定義される規則に適合するもののいずれかである。	Controlled Identifiers v1.0仕様の第2.3.3節: Key Agreementおよび 5.2 検証メソッド節。
`capabilityInvocation`	いいえ	データの集合であり、各要素は文字列で 3.1 DID構文節で定義される規則に適合するもの、またはマップで検証メソッドについて 5.2 検証メソッド節で定義される規則に適合するもののいずれかである。	Controlled Identifiers v1.0仕様の第2.3.4節: Capability Invocationおよび 5.2 検証メソッド節。
`capabilityDelegation`	いいえ	データの集合であり、各要素は文字列で 3.1 DID構文節で定義される規則に適合するもの、またはマップで検証メソッドについて 5.2 検証メソッド節で定義される規則に適合するもののいずれかである。	Controlled Identifiers v1.0仕様の第2.3.5節: Capability Delegationおよび 5.2 検証メソッド節。

プロパティ	必須?	値の制約	定義
`id`	はい	文字列であり、 3.2 DID URL構文の規則に適合するもの。	Controlled Identifiers v1.0 仕様の第2.1.1節: Subjectsおよび 5.1 識別子節。
`type`	はい	文字列。	Controlled Identifiers v1.0 仕様の第2.2節: Verification Methods。
`controller`	はい	文字列であり、 3.1 DID構文の規則に適合するもの。	Controlled Identifiers v1.0 仕様の第2.2節: Verification Methods。
`publicKeyMultibase`	いいえ	Multibaseエンコードされた公開鍵に適合する文字列。	Controlled Identifiers v1.0 仕様の第2.2.2節: Multikey。
`publicKeyJwk`	いいえ	JSON Web Keyを表すマップ。	Controlled Identifiers v1.0 仕様の第2.2.3節: JsonWebKey。

プロパティ	必須?	値の制約	定義
`id`	はい	URL Standard標準、または3.1 DID 構文節のいずれかの規則に適合する文字列。	Controlled Identifiers v1.0 仕様の第2.1.1節: Subjects。
`type`	はい	文字列または集合の文字列。	Controlled Identifiers v1.0 仕様の第2.1.4節: Services。
`serviceEndpoint`	はい	単一の文字列、単一のマップ、または 1つ以上の文字列および/またはマップで構成される集合。各文字列値は、URL Standardに適合する有効なURLでMUSTなければならない。	Controlled Identifiers v1.0 仕様の第2.1.4節: Services。

この節は、DID文書が DID主体およびDID コントローラの識別子を含める機構を説明する。

特定のDID主体のDIDは、 DID文書内の idプロパティを使用して表現される。このプロパティは、 Controlled Identifiers v1.0仕様の第2.1.1節: Subjectsで定義され、この仕様により、 3.1 DID構文節で定義される分散型識別子を含むように拡張される。

例 7

{
  "id": "did:example:123456789abcdefghijk"
}

注記: 中間表現

DIDメソッド仕様は、たとえば分散型識別子が検証可能データレジストリに登録されている場合、またはDIDリゾルバがDID解決を実行している場合などに、 DID文書の中間表現を作成できる。これらの中間表現にはid値が含まれない場合があり、または特定のidプロパティに暫定値が含まれる場合がある。 DID文書が完全に解決されると、最終的な id値が決定され、 DID文書全体で暫定値の代わりに配置される。

DIDコントローラとは、 DID文書に変更を加える権限を与えられたエンティティである。このプロパティは、 Controlled Identifiers v1.0仕様の第2.1.2節: Controllersで定義され、この仕様により、3.1 DID構文節で定義されるDIDを含むように拡張される。 DIDコントローラを認可するプロセスは、 DIDメソッドによって定義される。

例 8: controllerプロパティを持つDID文書

{
  "@context": "https://www.w3.org/ns/did/v1.1",
  "id": "did:example:123456789abcdefghi",
  "controller": "did:example:bcehfew7h32f32h7af3"
}

DID文書内で DID主体またはDID コントローラを識別するために使用される識別子は、クエリパラメータまたはフラグメント識別子を使用できない。実装者は、 3.1 DID構文節にある許可文字一覧に特に注意することが強く求められる。この一覧はこの要件を明確にしており、構文には?文字も#文字も含まれない。これは、 DID文書内で検証メソッドまたはサービスを識別するために使用される識別子とは対照的である。それらは3.2 DID URL構文節の構文規則に従い、クエリパラメータおよびフラグメント識別子の使用を許可する。それでも、 DIDエコシステム向けに作られる長期的な正準識別子でクエリパラメータを使用することは推奨されない。これは、DID解決ソフトウェアの複雑性を増し、より大きなセキュリティ攻撃面につながる可能性があるためである。フラグメント識別子も、特定のDID文書内で一意であることが期待され、実装者は、同じDID文書内の2つの異なる検証メソッドなど、時間の経過とともに異なる資源を参照するためにそれらを再利用しないことが推奨される。

DID文書は、 Controlled Identifiers v1.0の第2.2節: Verification Methodsで定義される検証メソッドを表現できる。ただし、追加の制約として、(a) id値は 3.2 DID URL構文節または3.2.1 相対 DID URL節にMUST適合しなければならず、(b) controller値は3.1 DID構文節に MUST適合しなければならない。検証メソッドの説明については、 Controlled Identifiers v1.0仕様の第2.2節: Verification Methodsを参照。

DID文書は、 Controlled Identifiers v1.0仕様の第2.3節: Verification Relationshipsで定義される検証関係を表現できる。検証メソッドの説明については、 Controlled Identifiers v1.0仕様の第2.3節: Verification Relationshipsを参照。

DID文書は、 Controlled Identifiers v1.0 仕様の第2.1.4節: Servicesで定義されるサービスを表現できる。サービスで使用される識別子は、 3.1 DID構文節、または 3.2 DID URL構文節に従って表現できる。サービスの説明については、 Controlled Identifiers v1.0 仕様の第2.1.4節: Servicesを参照。

この仕様におけるDID文書の具体的なシリアライズは、表現と呼ばれる。表現は、生成と呼ばれるプロセスを通じてデータモデルをシリアライズすることで作成される。表現は、消費と呼ばれるプロセスを通じてデータモデルへ変換される。生成および消費プロセスは、ある表現から別の表現への情報の変換を可能にする。この仕様はJSON用に単一の表現を定義し、これは JSON-LD処理を行うプロセッサとも互換性がある。以下の節では、生成および消費の一般規則、ならびにJSON表現を定義する。

この仕様で定義される表現に加えて、実装者はその他の表現を使用できる。ただし、それぞれの表現が適切に規定されていることを条件とする（DID拡張 [DID-EXTENSIONS] のリポジトリに記載されていないプロパティの相互運用可能な扱いに関する規則を含む）。詳細については、4.1 拡張性を参照。

すべての表現に対する要件は次のとおりである:

表現は、4. データモデルで規定されるすべてのデータ型について、決定的な生成規則および消費規則を定義MUSTしなければならない。
表現は、IANAに登録されたメディアタイプと一意に関連付けられていMUSTなければならない。
表現は、そのメディアタイプについて、フラグメントで定義されるフラグメント処理規則に適合するフラグメント処理規則を定義MUSTしなければならない。
表現は、データモデルのデータ型の字句表現を使用するSHOULDである。たとえば、JSONおよび JSON-LDは、日時を表すためにXML Schema dateTimeの字句シリアライズを使用する。表現は、消費プロセスによるデータモデルへの復元が損失なしである限り、異なる字句シリアライズを使用してデータモデルのデータ型をシリアライズすることを選択してもMAYよい。たとえば、一部のCBORベースの表現は、Unixエポックからの秒数を表す整数を使用して日時値を表現する。
表現は、表現固有エントリを定義しても MAYよい。これらは、生成および消費プロセス中に使用するために、表現固有エントリマップに格納される。これらのエントリは、損失のない変換を確保する助けとして、消費または生成時に使用される。
相互運用性を最大化するため、表現仕様の著者は、自身の表現を DID拡張 [DID-EXTENSIONS] のリポジトリに登録するSHOULDである。

すべての適合生成者に対する要件は次のとおりである:

適合生成者は、 DID文書データモデルおよび表現固有エントリマップを、生成プロセスへの入力として受け取ら MUSTなければならない。適合生成者は、生成プロセスへの入力として追加オプションを受け取ってもMAYよい。
適合生成者は、生成される表現について明示的な処理規則を持たない DID文書データモデル内のすべてのエントリ、および表現固有エントリマップを、その表現のデータ型処理規則のみを使用してシリアライズし、生成プロセスの完了後にそのシリアライズを返さMUSTなければならない。
適合生成者は、生成プロセスの完了後に、表現に関連付けられたメディアタイプの文字列を返さ MUSTなければならない。
適合生成者は、非適合のDIDまたはDID 文書を生成してはMUST NOTならない。

すべての適合消費者に対する要件は次のとおりである:

適合消費者は、表現およびメディアタイプ文字列を、消費プロセスへの入力として受け取ら MUSTなければならない。適合消費者は、消費プロセスへの入力として追加オプションを受け取ってもMAYよい。
適合消費者は、メディアタイプ入力文字列を使用して、 DID文書の表現を判定MUSTしなければならない。
適合消費者は、既知のすべての表現にわたって任意の表現固有エントリを検出し、そのエントリを表現固有エントリマップへ配置しなければならない。このマップは消費プロセスの完了後に返される。既知のすべての表現固有エントリの一覧は、 DID拡張 [DID-EXTENSIONS] のリポジトリで利用できる。
適合消費者は、消費される表現について明示的な処理規則を持たないすべての非表現固有エントリを、その表現のデータ型処理規則のみを使用して、 DID文書データモデルに追加し、消費プロセスの完了後に DID文書データモデルを返さ MUSTなければならない。
適合消費者は、非適合の DIDまたはDID 文書を消費するとき、エラーを生成MUSTしなければならない。

データモデルの表現が、JSONおよびJSON-LDを含めて、どのように生成され
消費されるかを示す図。 — 図 3 表現の生成と消費。関連項目: 説明的な記述。

図の左上の象限には、灰色の破線の輪郭を持つ長方形があり、その中に青い輪郭の長方形が上下に2つ含まれている。上側の大きい長方形は、青色で「Core Properties」とラベル付けされ、次のINFRA表記を含む:

«[
  "id" → "example:123",
  "verificationMethod" → « «[
    "id": "did:example:123#keys-1",
    "controller": "did:example:123",
    "type": "Multikey",
    "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
    ]» »,
  "authentication" → «
    "did:example:123#keys-1"
  »
]»

下側の小さい長方形は、青色で「Core Representation-specific Entries (JSON-LD)」とラベル付けされ、次の等幅のINFRA表記を含む:

«[ "@context" → "https://www.w3.org/ns/did/v1.1" ]»

灰色の輪郭の長方形から、3組の矢印が3つの異なる黒い輪郭の長方形へ伸びている。それぞれは、図の右上、右下、左下に1つずつ配置されている。各矢印の組は、灰色の輪郭の長方形から対応する黒い輪郭の長方形へ向かう「produce」とラベル付けされた青い矢印と、逆方向を指す「consume」とラベル付けされた赤い矢印で構成される。右上の黒い輪郭の長方形は「application/did+cbor」とラベル付けされ、16進データを含む。右下の長方形は「application/did」とラベル付けされ、次のJSONデータを含む:

{
  "id": "did:example:123",
  "verificationMethod": [{
    "id": "did:example:123#keys-1",
    "controller": "did:example:123",
    "type": "Multikey",
    "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
  }],
  "authentication": [
    "did:example:123#keys-1"
  ]
}

左下の長方形は「application/did」とラベル付けされ、次のJSON-LDデータを含む:

{
  "@context": "https://www.w3.org/ns/did/v1.1",
  "id": "did:example:123",
  "verificationMethod": [{
    "id": "did:example:123#keys-1",
    "controller": "did:example:123",
    "type": "Multikey",
    "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
  }],
  "authentication": [
    "did:example:123#keys-1"
  ]
}

注記: 表現間の変換

実装は、元の表現に対して消費規則を使用してデータモデルを得たうえで、生成規則を使用してデータモデルを対象表現へシリアライズすること、または同じ対象表現をもたらすその他の機構により、表現間を変換することが期待される。

この節は、JSON表現の生成規則および消費規則を定義する。

DID文書、DID文書データ構造、および表現固有エントリマップは、次の生成規則に従ってJSON 表現へシリアライズされMUSTなければならない:

データ型	JSON表現型
マップ	JSONオブジェクト。各エントリは、エントリキーをJSON文字列のメンバー名とし、エントリ値をこの表で定義されるその型に従って、JSONオブジェクトのメンバーとしてシリアライズされる。
リスト	JSON配列。リストの各要素は、この表で定義されるその型に従って、順序どおりに配列の値としてシリアライズされる。
集合	JSON配列。集合の各要素は、この表で定義されるその型に従って、順序どおりに配列の値として追加される。
日時	UTC 00:00:00に正規化され、小数秒の精度を持たない XML DatetimeとしてシリアライズされたJSON文字列。例: `2020-12-20T19:17:47Z`。
文字列	JSON文字列。
整数	小数または小数部を持たないJSON数値。
倍精度数	小数および小数部を持つJSON数値。
真偽値	JSON真偽値。
null	JSON nullリテラル。

JSON 表現を生成する適合生成者を作成するすべての実装者は、自身のアルゴリズムが [INFRA] 仕様の JSON シリアライズ規則および JSON [RFC8259] 仕様の数値に関する精度の助言に合致することを確保するよう助言される。

DID文書のすべてのエントリは、ルートJSONオブジェクトに含まれMUSTなければならない。エントリは、上の一覧の値表現規則に従う追加のデータ部分構造を含んでもMAYよい。 DID文書をシリアライズする場合、適合生成者は、下流のアプリケーションに対して application/didのメディアタイプを指定しMUSTなければならない。

例 9: JSON表現のDID文書の例

{
  "@context": "https://www.w3.org/ns/did/v1.1",
  "id": "did:example:123456789abcdefghi",
  "authentication": [{
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Multikey",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
  }]
}

DID文書およびDID文書データ構造のJSON 表現は、次の消費規則に従ってデータモデルへデシリアライズされMUSTなければならない:

JSON表現型	データ型
JSONオブジェクト	マップ。JSONオブジェクトの各メンバーは、マップへエントリとして追加される。各エントリキーはJSONオブジェクトのメンバー名として設定される。各エントリ値は、この表で定義されるJSON表現型に従ってJSONオブジェクトのメンバー値を変換することで設定される。JSONオブジェクトでは順序が規定されないため、挿入順序は保証されない。
JSON配列で、データモデルのエントリ値がリストまたは未知である場合	リスト。JSON配列の各値は、この表で定義される配列値のJSON表現型に基づいて変換され、順序どおりにリストへ追加される。
JSON配列で、データモデルのエントリ値が集合である場合	集合。JSON配列の各値は、この表で定義される配列値のJSON表現型に基づいて変換され、順序どおりに集合へ追加される。
JSON文字列で、データモデルのエントリ値が日時である場合	日時。
JSON文字列で、データモデルのエントリ値型が文字列または未知である場合	文字列。
小数または小数部を持たない JSON数値	整数。
小数および小数部を持つJSON数値、または小数部の有無にかかわらずエントリ値が倍精度数である場合	倍精度数。
JSON真偽値	真偽値。
JSON nullリテラル	null値。

適合生成者または適合消費者を作成するすべての実装者は、自身のアルゴリズムが [INFRA] 仕様の JSON 変換規則および JSON [RFC8259] 仕様の数値に関する精度の助言に合致することを確保するよう助言される。

メディアタイプ情報が適合消費者に利用可能であり、メディアタイプ値がapplication/didである場合、消費されるデータ構造は DID文書であり、ルート要素はオブジェクトのすべてのメンバーがDID文書のエントリである JSON オブジェクトでMUSTなければならない。JSON 表現の適合消費者が、ルート要素が JSONオブジェクトではない DID文書を消費する場合、エラーを報告 MUSTしなければならない。

JSON-LDは、Linked Dataをシリアライズするために使用されるJSONベースの形式である。一部の実装は、標準の JSON-LD処理アルゴリズムを使用してDID 文書を処理することが期待される。相互運用性を最大化するため、実装者は標準準拠のライブラリを用いたJSON-LD処理が妨げられないようにすることを強く助言される。 DID文書の意味論は、標準準拠のライブラリを用いたJSON-LD処理が実行されるかどうかにかかわらず同じである。意味論に差異がある場合、それは実装またはDIDメソッド仕様のいずれかにおける誤りである。

JSON-LD処理が行われるためには、JSON-LD 1.1仕様で規定される規則に従って、@contextプロパティが指定されMUSTなければならない。

@context: JSON-LDコンテキストは、文字列、または文字列および/または順序付きマップの任意の組み合わせを含むリストのいずれかである。

DID文書、DID文書データ構造、および表現固有エントリマップは、6.2 JSONで定義されるJSON 表現生成規則に従って、 JSON表現へシリアライズされMUSTなければならない。

JSON表現生成規則の使用に加えて、生成は @contextエントリを含めMUSTなければならない。 @contextのシリアライズされた値は、 JSON 文字列https://www.w3.org/ns/did/v1.1、または最初のアイテムが JSON文字列 https://www.w3.org/ns/did/v1.1であり、後続のアイテムがJSON 生成規則に従ってシリアライズされるJSON配列で MUSTなければならない。

例 10: 単純な@contextエントリの有効なシリアライズ

{
  "@context": "https://www.w3.org/ns/did/v1.1",
  ...
}

例 11: 階層化された@contextエントリの有効なシリアライズ

{
  "@context": [
    "https://www.w3.org/ns/did/v1.1",
    "https://did-method-extension.example/v1"
  ],
  ...
}

JSON-LDとして処理されることを意図した表現を生成または消費する適合消費者を作成するすべての実装者は、自身のアルゴリズムが有効なJSON-LD文書を生成することを確保するよう助言される。無効なJSON-LD文書は、JSON-LDプロセッサを停止させ、エラーを報告させる。

異なる表現間の相互運用性を実現するため、すべてのJSON-LDコンテキストおよびその用語は、分散型識別子拡張のリポジトリに登録されるSHOULDである。

JSON-LD表現を生成する適合生成者は、 @contextを介して定義されていない用語を含む DID文書を生成するSHOULD NOTである。これは、適合消費者が未知の用語を削除することが期待されるためである。DID 文書のJSON-LD表現をシリアライズする場合、適合生成者は、下流のアプリケーションに対してapplication/didのメディアタイプを指定 MUSTしなければならない。

JSON-LD表現を処理する適合消費者は、 @contextを介して定義されていないすべての用語を DID文書から削除する SHOULDである。

実装は、https://www.w3.org/ns/did/v1.1に配置されているベースコンテキスト値を、すでに取得済みとして扱わ MUSTなければならない。次の値は、ベースコンテキストファイルの16進数でエンコードされたSHA2-256ダイジェスト値である: ea216ecc1cb02cd39b693dba2250141e270ba0bf95890be107dd9a9e8e43de85。現代的なUnixコマンドラインインターフェイスから次のコマンドを実行することで、上記の暗号学的ダイジェストを確認できる: curl -s https://www.w3.org/ns/did/v1.1 | openssl dgst -sha256。

実装者は、URLを介してリンクされる資源など、 DID文書内から参照されるその他のデータが、既定では暗号学的に保護されないことに警告される。永続的にキャッシュされたファイルおよび/または暗号学的ハッシュの使用を通じて、 DID文書のセキュリティに重要な任意のURLに対して同種の保護が提供されることを確保するのがベストプラクティスとみなされる。最終的に、リンクされた外部コンテンツの暗号学的ダイジェストを知ることで、アプリケーションは、そのコンテンツがDID コントローラが意図したものと同じであることを確認できる。

注記: ハッシュ値の変更が検出された場合は正誤表を参照

この仕様で暗号学的ハッシュ値が関連付けられているファイルが変更される可能性は極めて低い。しかし、仕様に重大な正誤が見つかり、エコシステムの安定性を確保するために修正が必要となる場合、暗号学的ハッシュ値が変更される可能性がある。そのため、ファイルのHTTPキャッシュ時間は無限には設定されておらず、実装者は、暗号学的ハッシュ値の変更が検出された場合には正誤表を確認するよう助言される。

[RFC6838]で定義されるメディアタイプは、DID文書を表現するために使用される構文、およびその他の有用な処理指針を識別する。

この仕様のデータモデルを表現するために使用される構文は、メディアタイプによって識別される SHOULDであり、DID文書でメディアタイプを定義または使用する場合には、この節で概説される慣例に従う SHOULDである。

中核データモデルに関連付けられたメディアタイプは1つあり、 E. IANAに関する考慮事項節に記載されている: application/did。

この節は非規範的である。

開発者またはシステムは、DID文書を伝達するために、低精度のメディアタイプを使用することがある。低精度のメディアタイプが使用される理由には、次のようなものがある:

Webサーバーが、ファイル拡張子が利用できずメディアタイプを判定できない場合に、既定でtext/plainまたはapplication/octet-streamを使用する。
開発者が、ファイルの内容よりも具体性の低いメディアタイプにつながるファイル拡張子を追加する。たとえば、.jsonはapplication/jsonというメディアタイプになり、.jsonldは application/ld+jsonというメディアタイプになる場合がある。
プロトコルが特定のトランザクションに対して、より低精度のメディアタイプを要求する。たとえば、application/didではなくapplication/jsonである。

使用されたメディアタイプが当該プロトコルで許容される場合、ペイロードから意図されたメディアタイプを判定できるなら、実装者はエラーを発生させないことが推奨される。たとえば、アプリケーションがapplication/didメディアタイプに関連付けられた規則に適合するペイロードのみを受け入れるが、ペイロードがより低精度の application/jsonまたはapplication/ld+jsonでタグ付けされている場合、アプリケーションは、ペイロードがより高精度のメディアタイプにも適合するかどうかを判定するために、次の手順を実行することがある:

ペイロードをJSON文書として解析する。
@contextプロパティの最初の要素が https://www.w3.org/ns/did/v1.1に一致することを確認する。
JSON文書が、3.1 DID構文節の規則に適合する識別子を含む最上位の idプロパティを含む場合、application/didメディアタイプを仮定する。

可能な限り、実装者はこの仕様で定義されるすべてのペイロードについて、最も精密な（最高精度の）メディアタイプを使用することが助言される。また、低精度のメディアタイプでタグ付けされたペイロードが、高精度の型でタグ付けするために必要な規則を満たしていないことを意味するわけではないことを認識するよう助言される。同様に、高精度のメディアタイプでタグ付けされたペイロードが、そのメディアタイプに関連付けられた要件を満たすことを意味するわけではない。ペイロードの受信者は、関連付けられたメディアタイプにかかわらず、ペイロードが特定のシステムでの使用要件に適合することを確保するため、適切な検査を行うことが期待される。

HTTPクライアントおよびサーバーは、DID 文書に関連付けられたメディアタイプを、 Accept:ヘッダーおよびコンテンツタイプを示す際に使用する。実装者は、 HTTPサーバーがAccept:ヘッダーを無視して別のコンテンツタイプを返したり、 415 Unsupported Media Typeなどのエラーコードを返したりする可能性があることに警告される。

適合DIDメソッドは、実装者がこの仕様で説明される機能をどのように実現できるかを定義する。DIDメソッドは、多くの場合、特定の検証可能データレジストリに関連付けられる。新しいDIDメソッドは、同一の DIDメソッドの異なる実装間の相互運用性を可能にするため、それぞれ独自の仕様で定義される。

概念的には、この仕様とDIDメソッド仕様との関係は、IETFの汎用 URI 仕様 [RFC3986] と、http スキーム [RFC9110] などの特定のURI スキーム [IANA-URI-SCHEMES] との関係に似ている。特定のDIDスキームを定義することに加えて、DIDメソッド仕様は、特定の種類の検証可能データレジストリを用いて、DIDおよびDID文書を作成、解決、更新、および無効化するための機構も定義する。また、DIDに関連するすべての実装上の考慮事項、ならびにセキュリティおよびプライバシーに関する考慮事項も文書化する。

この節は、DIDメソッド仕様を作成するための要件を規定する。

メソッド固有のDID構文を定義する際の、すべてのDIDメソッド仕様に対する要件は次のとおりである:

DIDメソッド仕様は、3.1 DID構文の method-name規則で規定される、正確に1つのメソッド名によって識別される、正確に1つのメソッド固有のDIDスキームを定義 MUSTしなければならない。
DIDメソッド仕様は、DIDの method-specific-id構成要素を生成する方法を規定 MUSTしなければならない。
DIDメソッド仕様は、 method-specific-idの値の大文字小文字の扱いおよび正規化を定義 MUSTしなければならない。
method-specific-id値は、DIDメソッド内で一意で MUSTなければならない。method-specific-id値自体がグローバルに一意である場合もある。
DIDメソッドによって生成される任意のDIDは、グローバルに一意で MUSTなければならない。
method-nameの衝突の可能性を減らすため、DIDメソッド仕様はDID拡張 [DID-EXTENSIONS] のリポジトリに登録される SHOULDである。
DIDメソッドは、複数の method-specific-id形式を定義してもMAYよい。
method-specific-id形式はコロンを含んでもMAYよい。コロンの使用は、構文上、method-specific-id ABNF規則に準拠 MUSTしなければならない。
DIDメソッド仕様は、パスにおける汎用規則よりも制限的なDIDパスのABNF規則を規定してもMAYよい。
DIDメソッド仕様は、この節における汎用規則よりも制限的な DIDクエリのABNF規則を規定してもMAYよい。
DIDメソッド仕様は、この節における汎用規則よりも制限的な DIDフラグメントのABNF規則を規定してもMAYよい。

注記: method-specific-id内のコロン

method-specific-id内のコロンの意味は完全にメソッド固有である。コロンは、DIDメソッドによって、階層的に分割された名前空間の確立、検証可能データレジストリの特定のインスタンスまたは部分の識別、またはその他の目的のために使用されることがある。実装者は、すべてのDIDメソッドに汎用的に適用可能な、コロンに関連する意味や振る舞いを仮定しないよう助言される。

メソッド操作を定義する際の、すべてのDIDメソッド仕様に対する要件は次のとおりである:

DIDメソッド仕様は、必要な暗号学的プロセスを含むすべての操作を実行するために認可がどのように行われるかを定義 MUSTしなければならない。
DIDメソッド仕様は、DIDコントローラが DIDおよびそれに関連付けられたDID文書をどのように作成するかを規定 MUSTしなければならない。
DIDメソッド仕様は、DIDリゾルバが DIDを使用してDID文書を解決する方法を規定 MUSTしなければならない。これには、DIDリゾルバが応答の真正性を検証できる方法も含まれる。
DIDメソッド仕様は、 DID文書の更新を構成するもの、およびDID コントローラがDID文書を更新できる方法を規定 MUSTしなければならない。または、更新が不可能であることを述べなければならない。
DIDメソッド仕様は、DIDコントローラが DIDを無効化できる方法を規定MUSTしなければならない。または、無効化が不可能であることを述べなければならない。

操作を実行するための認可を行う当事者の権限は、DIDメソッドに固有である。たとえば、DIDメソッドは —

controllerプロパティを使用する場合がある。
authenticationの下に列挙された検証メソッドを使用する場合がある。
capabilityInvocation 検証関係を介して指定される検証メソッドなど、DID文書内の他の構成要素を使用する場合がある。
この判断にDID文書をまったく使用せず、代わりに帯域外の機構に依存する場合がある。

メソッド操作を実行する場合、DIDメソッドは、必要とする任意のデータ構造を使用できる。これには、中間的、部分的、または一時的なDID文書が含まれるが、それらがDIDメソッドの内部に保持され、メソッド操作によって返されるDID文書が 1.4 適合性で定義されるように完全に適合している限りにおいてである。

Security Considerations節を作成する際の、すべてのDIDメソッド仕様に対する要件は次のとおりである:

DIDメソッド仕様は、DIDメソッド仕様で定義されるDID操作について、 RFC3552: Writing Security Considerations Sectionsで提供されるすべての指針および規範的文言に従わ MUSTなければならない。
Security Considerations節は、DIDメソッド仕様で定義される DID操作について、次の攻撃形態を文書化MUSTしなければならない: 盗聴、リプレイ、メッセージ挿入、削除、改ざん、サービス拒否、増幅、および中間者攻撃。その他の既知の攻撃形態も文書化するSHOULDである。
Security Considerations節は、脅威緩和策が展開された後における、関連プロトコルの侵害、不正確な実装、または暗号から生じるリスクなどの残余リスクを論じ MUSTなければならない。
Security Considerations節は、7.2 メソッド操作で要求されるすべての操作について、完全性保護および更新認証を提供 MUSTしなければならない。
認証が関与する場合、特にユーザー・ホスト認証の場合には、その認証方式のセキュリティ特性が明確に文書化されMUSTなければならない。
Security Considerations節は、DIDが一意に割り当てられていることを証明するポリシー機構を論じMUSTなければならない。
メソッド固有のエンドポイント認証は論じられMUSTなければならない。DIDメソッドが、必要な計算資源を減らすために light nodeまたは thin client 実装として提供されることもある、さまざまなネットワークトポロジを持つ DLTを使用する場合、そのDIDメソッドの実装で利用可能なトポロジのセキュリティ上の前提を論じMUSTなければならない。
プロトコルが暗号学的保護機構を組み込む場合、DIDメソッド仕様は、データのどの部分がどの保護によって保護されるかを明確に示しMUSTなければならず、その暗号学的保護が影響を受けやすい攻撃の種類を示す SHOULDである。例には、完全性のみ、機密性、およびエンドポイント認証がある。
秘密に保持されるべきデータ（鍵材料、乱数シードなど）は、明確にラベル付けされるSHOULDである。
DIDメソッド仕様は、該当する場合、DID文書への署名の実装を説明および規定する SHOULDである。
既知のすべてのDLTの場合など、 DIDメソッドがピアツーピア計算資源を使用する場合、それらの資源に期待される負荷は、サービス拒否との関係で論じられる SHOULDである。
5.4 サービスで説明されるように、新しい認証サービスタイプを導入するDIDメソッドは、サポートされる認証プロトコルのセキュリティ要件を考慮するSHOULDである。

Privacy Considerations節を作成する際の、すべてのDIDメソッド仕様に対する要件は次のとおりである:

DIDメソッド仕様のPrivacy Considerations節は、メソッド固有の形で適用され得る [RFC6973] の第5節の任意の小節について論じMUSTなければならない。考慮すべき小節は、監視、保存データの侵害、望まれないトラフィック、誤帰属、相関、識別、二次利用、開示、および排除である。

この節は非規範的である。

この節には、分散型識別子を使用する人々が、この技術を本番環境に展開する前に検討することを助言される、さまざまなセキュリティ上の考慮事項が含まれている。読者は、この節を読む前に、 Controlled Identifiers v1.0仕様の Security Considerations節を読むことが強く求められる。DIDは、多くのIETF標準で使用され、 [RFC3552] に文書化されている脅威モデルの下で動作するよう設計されている。この節は、 [RFC3552] における多くの考慮事項に加え、 DIDアーキテクチャに固有のその他の考慮事項について詳述する。

DID拡張 [DID-EXTENSIONS] のリポジトリには、 DIDメソッド名と、それに対応するDIDメソッド仕様の参考情報一覧が含まれている。実装者は、特定のDIDメソッド名とともにどの DIDメソッド仕様を使用すべきかを命じる中央機関が存在しないことに留意する必要がある。特定のDIDリゾルバがDIDメソッドを正しく実装しているかどうかに疑問がある場合、DID Specification Registriesを使用して登録済み仕様を調べ、どのDIDリゾルバ実装を使用するかについて十分な情報に基づく判断を行うことができる。

DIDおよびDID文書更新の否認防止は、次の場合にサポートされる:

検証可能データレジストリが検証可能タイムスタンプをサポートする場合。 DID解決プロセス中に使用できる有用なタイムスタンプの詳細については、 [DID-RESOLUTION] の "DID Document Metadata"を参照。
主体が、DIDメソッドの認可機構に従って、悪意のある更新を差し戻す十分な機会を持っていた場合。

トラストレスシステムとは、すべての信頼が暗号学的に証明可能な主張から導出され、より具体的には、暗号システムの外部のメタデータが、そのシステムにおける信頼の判断に組み込まれないシステムである。トラストレスシステムで失効済みの検証メソッドに対する証明の署名を検証するためには、DIDメソッドは、 versionIdまたはversionTimeのいずれか、またはその両方に加えて、 updatedおよび nextUpdateの両方のDID文書メタデータプロパティをサポートする必要がある。検証者は、次のすべてが真である場合に限り、失効した鍵の署名または証明を検証できる:

証明または署名が、その署名または証明が作成された時点で使用された DID文書のversionIdまたは versionTimeを含む。
検証者が、その署名または証明が作成された時点を判断できる。たとえば、それがブロックチェーン上にアンカーされていた場合などである。
解決されたDID文書メタデータにおいて、updatedタイムスタンプが署名または証明が作成された時点より前であり、nextUpdateタイムスタンプがその時点より後である。

暗号学的入力を構成するものを超えるメタデータを受け入れる意思のあるシステムでも、同様の信頼を達成できる場合がある。しかしこれは常に、署名イベントの瞬間に DID文書の内容が期待される内容を含んでいたかどうかについて、慎重な判断を必要とする。

復旧とは、デバイスの喪失などによりDID操作を実行する能力を失ったコントローラが、 DID操作を実行する能力を取り戻せるようにする、事後対応型のセキュリティ対策である。

DID復旧の使用を検討する際には、次の考慮事項が有用である可能性がある:

低頻度ではあるが定期的に、先回りして復旧を実行することは、制御の喪失を防ぐ助けになる。
復旧に関連付けられた暗号材料を他の目的で再利用しないことは、ベストプラクティスとみなされる。
復旧は通常、検証メソッドローテーションおよび検証メソッド失効と組み合わせて実行される。
7.2 メソッド操作で説明されるように、コントローラまたはその代理として動作することを信頼されたサービスが、DID操作を実行する排他的な能力をもはや持たない場合には、復旧が助言される。
DIDメソッド仕様は、復旧を容易にするために、信頼された当事者のクォーラムのサポートを可能にすることを選択する場合がある。そのための機能の一部は、5.1.2 DIDコントローラで示唆されている。
すべてのDIDメソッド仕様が、他の DIDメソッドを使用して登録された DIDからの制御を認識するわけではなく、第三者による制御を同じメソッドを使用するDIDに制限する場合がある。
DIDメソッド仕様におけるアクセス制御および復旧は、復旧のための第二の制御系統を維持することで鍵侵害から保護するタイムロック機能も含めることができる。
現在、すべてのDIDメソッドに適用される共通の復旧機構は存在しない。

DIDは、中央登録機関を必要とせずにグローバルな一意性を達成する。これは、人間にとっての記憶しやすさを犠牲にしている。グローバルに曖昧さのない識別子を生成できるアルゴリズムは、人間にとって意味を持たないランダムな文字列を生成する。このトレードオフはしばしば Zookoの三角形と呼ばれる。

人間に分かりやすい識別子から出発してDIDを発見することが望ましいユースケースがある。たとえば、自然言語の名前、ドメイン名、または携帯電話番号、メールアドレス、ソーシャルメディアのユーザー名、ブログURLなどの、DID コントローラの従来型のアドレスである。しかし、人間に分かりやすい識別子を DIDへマッピングし、それを検証可能かつ信頼できる方法で行う問題は、この仕様の範囲外である。

この問題に対する解決策は、この仕様を参照する [DNS-DID] などの別個の仕様で定義される。そのような仕様は、次の事項を慎重に考慮することが強く推奨される:

対象エンティティの真の人間に分かりやすい識別子についてユーザーを欺くことに基づく、数多くのセキュリティ攻撃。
本質的に相関可能な人間に分かりやすい識別子を使用することのプライバシー上の帰結。特に、それらがグローバルに一意である場合。

DIDコントローラが望む場合、DIDまたはDID URLは、永続的で場所に依存しない資源識別子として機能できる。この種の識別子はUniform Resource Names（URN）に分類され、[RFC8141] で定義される。 DIDは、デジタル資源に対して暗号学的に安全で場所に依存しない識別子を提供しつつ、取得を可能にするメタデータも提供する、URNの拡張形である。 DID文書とDID自体との間に間接参照があるため、 DIDコントローラは、DIDを変更することなく、資源の実際の場所を調整すること、または資源を直接提供することさえできる。この種類のDIDは、取得された資源が実際に識別された資源であることを決定的に検証できる。

この目的でDIDを使用する意図のあるDIDコントローラは、 [RFC8141] のセキュリティに関する考慮事項に従うよう助言される。特に:

DIDコントローラは、コントローラの永続性に関する要件をサポートするDIDメソッドを選択することが期待される。 Decentralized Characteristics Rubric [DID-RUBRIC] は、実装者が最も適切なDIDメソッドを決定するのに役立つ利用可能なツールの1つである。
DIDコントローラは、自身の運用ポリシーを公開し、要求当事者が、そのDIDコントローラによって制御されるDIDの永続性にどの程度依拠できるかを判断できるようにすることが期待される。そのようなポリシーがない場合、要求当事者は、DIDが同一の DID主体に対する永続識別子であるかどうかについて、いかなる仮定も行うことは期待されない。

多くのサイバーセキュリティ上の悪用は、現実と、合理的で善意の行為者の仮定との間のすき間を悪用することに依存している。DID文書の不変性は、一定のセキュリティ上の利益を提供し得る。個々のDIDメソッドは、不要な振る舞いや意味論を排除する制約を検討すべきである。同じ機能集合を提供しつつ、 DIDメソッドがより固定化されているほど、悪意のある行為者によって操作されにくくなる。

例として、DID文書に 1回編集を加えるだけで、その文書のルートidプロパティ以外は何でも変更できると考えてみる。しかし、サービスが定義後に typeを変更できることは実際に望ましいのだろうか。あるいは鍵がその値を変更できることは望ましいのだろうか。それとも、オブジェクトの特定の根本的なプロパティが変化した場合には、新しいidを要求する方がよいのだろうか。Webサイトの悪意ある乗っ取りは、サイトがホスト名識別子を保持したまま、その下層が微妙に変更される結果を狙うことが多い。 IPアドレスに関連付けられたASNなど、サイトの特定のプロパティが仕様によって不変であることを要求されていれば、異常検知は容易になり、攻撃の実行ははるかに難しく、費用も高くなる。

真実のグローバルな情報源に結び付けられたDIDメソッドでは、DID文書の最新バージョンを直接かつジャストインタイムに検索することが常に可能である。しかし、最終的には DIDリゾルバとその真実の情報源との間にキャッシュ層が置かれる可能性が高い。その場合、DID文書内のオブジェクトの属性が実際には微妙に異なる状態であるにもかかわらず、ある状態であると信じることは、悪用を招く可能性がある。これは、一部の検索が完全なDID文書に対するものであり、他の検索が、より大きな文脈が仮定される部分データに対するものである場合に特に当てはまる。

暗号化アルゴリズムは、暗号技術および計算能力の進歩により破られることが知られている。実装者は、DID文書内に置かれた任意の暗号化データが、最終的にはその暗号化データを利用できる同じ対象者に対して平文で利用可能になる可能性があると仮定することが助言される。これは、DID文書が公開されている場合に特に重要である。

DID文書の全部または一部を暗号化することは、長期的にデータを保護するための適切な手段ではない。同様に、暗号化データをDID文書に置くことは、個人データを保護するための適切な手段ではない。

上記の注意点を踏まえ、暗号化データがDID文書に含まれる場合、実装者は、その暗号化データと関連当事者との関係を推測するために使用され得る相関可能な情報を関連付けないよう助言される。相関可能な情報の例には、受信側当事者の公開鍵、受信側当事者の制御下にあることが知られているデジタル資産への識別子、または受信側当事者の人間が読める説明が含まれる。

equivalentIdおよびcanonicalId プロパティはDIDメソッド自身によって生成されるため、 DID文書の idフィールドに存在する解決済みのDIDに適用されるものと同じセキュリティおよび正確性の保証が、これらのプロパティにも適用される。 alsoKnownAsプロパティは、同等性を正確に述べるものとは保証されず、 DID文書の解決を超える検証手順を実行せずに依拠すべきではない。

equivalentIdおよびcanonicalId プロパティは、同じDIDメソッドによって生成された単一のDIDの変種に対する同等性主張を表し、要求当事者がそのDIDメソッドならびに適合生成者およびリゾルバを信頼する範囲で信頼できる。

alsoKnownAsプロパティは、同じDIDメソッドによって管理されていない URIに対する同等性主張を許可し、管理するDIDメソッドの外部で検証手順を実行しない限り信頼できない。追加の指針については、 Controlled Identifiers v1.0仕様の第2.1.3節: Also Known Asを参照。

DID文書内の他のセキュリティ関連プロパティと同様に、DID文書内の任意の同等性記述に依拠する当事者は、適切な検証が実行された後に、これらのプロパティの値が攻撃者によって置換されることを防御すべきである。検証が実行された後、メモリまたはディスクに保存された DID文書への任意の書き込みアクセスは、 DID文書が再検証されない限り、検証を回避し得る攻撃ベクトルである。

DIDは、コントローラが自身の識別子を維持するために、単一の信頼された第三者または管理者に依存する必要がないよう、永続的であるように設計されている。理想的な場合、管理者はコントローラから制御を奪うことも、認証、認可、証明などの特定の目的のための識別子の使用を妨げることもできない。第三者は、コントローラの代理として、そのコントローラの同意なしにエンティティの識別子を削除したり使用不能にしたりすることはできない。

しかし、暗号学的な制御証明を可能にするすべてのDIDメソッドでは、秘密の暗号材料を移転することによって、制御を証明する手段を常に別の当事者へ移転できることに注意することが重要である。したがって、識別子の長期的な永続性に依拠するシステムは、その識別子が実際に意図された当事者の制御下にまだあることを確認するため、定期的にチェックすることが不可欠である。

残念ながら、特定の検証メソッドに関連付けられた秘密の暗号材料が侵害されたかどうかを、暗号だけから判断することは不可能である。期待されるコントローラが依然として秘密の暗号材料へアクセスでき、そのため検証プロセスの一部として制御証明を実行できる一方で、同時に悪意ある行為者も同じ鍵またはそのコピーにアクセスできる、ということは十分にあり得る。

そのため、暗号学的な制御証明は、重要度の高いシナリオで必要とされる身元保証レベルを評価する際の 1つの要素としてのみ使用されることが期待される。DIDベースの認証は、暗号学的秘密をシステム間で送信せずにその秘密に対する制御を判断できる能力のおかげで、ユーザー名とパスワードよりもはるかに高い保証を提供する。しかし、それは完全ではない。機微性が高い、高価値である、または生命に関わる操作を含むシナリオでは、必要に応じて追加要素を使用することが期待される。

異なるコントローラによる使用から生じる潜在的な曖昧さに加え、一般に、特定のDIDが任意の時点で同じ主体を参照して使用されていることを保証することは不可能である。コントローラがDIDを異なる主体に再利用することは技術的に可能であり、より微妙には、主体の正確な定義が時間とともに変化したり、誤解されたりすることも可能である。

たとえば、個人事業のために使用され、金融取引に使用されるさまざまなクレデンシャルを受け取る DIDを考える。コントローラにとって、その識別子はその事業を参照していた。事業が成長するにつれて、最終的に有限責任会社として法人化される。コントローラは同じDIDを使い続ける。なぜならその人にとって、そのDIDは事業を指すからである。しかし州、税務当局、および地方自治体にとって、そのDIDはもはや同じエンティティを指していない。この意味の微妙な変化が信用供与者または供給者にとって重要かどうかは、必然的にそれらの判断に委ねられる。多くの場合、請求が支払われ、回収が執行できる限り、その変化は重要ではない。

これらの潜在的な曖昧さのため、DIDは絶対的ではなく 文脈的に有効であるとみなされるべきである。その永続性は、それらがまったく同じ主体を参照することを意味せず、同じコントローラの制御下にあることも意味しない。代わりに、DIDが作成された文脈、それがどのように使用されるかを理解し、意味の変化の可能性を考慮し、潜在的かつ不可避な意味論上の漂流に対処するための手順およびポリシーを採用する必要がある。

この節は非規範的である。

この仕様は、特定の種類の検証可能データレジストリの使用を要求または提案しない。異なるユースケースは異なる要件をもたらす可能性がある。異なる要件は、異なるトレードオフを伴う異なる考慮事項を示唆する可能性がある。たとえば、計算（エネルギー使用）、信頼（権威への依拠）、調整（ネットワーク帯域幅）、またはメモリ（物理ストレージ）の間のトレードオフは、特定のユースケースに適切な場合もあればそうでない場合もある。他のユースケースは同じトレードオフを行わない場合がある。自らのユースケースについて異なる基準を検討する必要がある者は、 DID Method Rubricを参照されたい。これは、特定の DIDメソッドが自らのユースケースに適しているかどうかを意思決定者が判断するのに役立つ評価基準を提供する。

この節は非規範的である。

任意の拡張およびその他の検証メソッド型については、 Verification Method Types [DID-EXTENSIONS] を参照。

注記

これらの例は情報提供のみを目的としている。複数の目的に同じ検証メソッドを使用しないことが、ベストプラクティスとみなされる。

例 12: 1つの検証メソッド型を持つDID文書

  {
    "@context": "https://www.w3.org/ns/did/v1.1",
    "id": "did:example:123",
    "authentication": [
      {
        "id": "did:example:123#z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu",
        "type": "Multikey", // external (property value)
        "controller": "did:example:123",
        "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
      }
    ],
    "capabilityInvocation": [
      {
        "id": "did:example:123#z6Mkvtac9bidSz9bBttzn7Yg3oCDHvMY2FtkFLs6SXRQGdQR",
        "type": "Multikey", // external (property value)
        "controller": "did:example:123",
        "publicKeyMultibase": "z6Mkvtac9bidSz9bBttzn7Yg3oCDHvMY2FtkFLs6SXRQGdQR"
      }
    ],
    "capabilityDelegation": [
      {
        "id": "did:example:123#z6MknxsdF4CGVxhRNsx6TvXPFczaHEkajKBBwu75uwBmgpom",
        "type": "Multikey", // external (property value)
        "controller": "did:example:123",
        "publicKeyMultibase": "z6MknxsdF4CGVxhRNsx6TvXPFczaHEkajKBBwu75uwBmgpom"
      }
    ],
    "assertionMethod": [
      {
        "id": "did:example:123#z6MkgYhVuWq4hyc7ZKBGhsY7pb5Bc8V6VPXGPG3EPja8JBFR",
        "type": "Multikey", // external (property value)
        "controller": "did:example:123",
        "publicKeyMultibase": "z6MkgYhVuWq4hyc7ZKBGhsY7pb5Bc8V6VPXGPG3EPja8JBFR"
      }
    ]
}

例 13: 多くの異なる鍵型を持つDID文書

{
  "@context": "https://www.w3.org/ns/did/v1.1",
  "id": "did:example:123",
  "verificationMethod": [
    {
      "id": "did:example:123#key-0",
      "type": "JsonWebKey",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "OKP", // external (property name)
        "crv": "Ed25519", // external (property name)
        "x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ" // external (property name)
      }
    },
    {
      "id": "did:example:123#key-1",
      "type": "JsonWebKey",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "OKP", // external (property name)
        "crv": "X25519", // external (property name)
        "x": "pE_mG098rdQjY3MKK2D5SUQ6ZOEW3a6Z6T7Z4SgnzCE" // external (property name)
      }
    },
    {
      "id": "did:example:123#key-2",
      "type": "JsonWebKey",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "EC", // external (property name)
        "crv": "secp256k1", // external (property name)
        "x": "Z4Y3NNOxv0J6tCgqOBFnHnaZhJF6LdulT7z8A-2D5_8", // external (property name)
        "y": "i5a2NtJoUKXkLm6q8nOEu9WOkso1Ag6FTUT6k_LMnGk" // external (property name)
      }
    },
    {
      "id": "did:example:123#key-3",
      "type": "JsonWebKey",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "EC", // external (property name)
        "crv": "secp256k1", // external (property name)
        "x": "U1V4TVZVMUpUa0ZVU1NBcU9CRm5IbmFaaEpGNkxkdWx", // external (property name)
        "y": "i5a2NtJoUKXkLm6q8nOEu9WOkso1Ag6FTUT6k_LMnGk" // external (property name)
      }
    },
    {
      "id": "did:example:123#key-4",
      "type": "JsonWebKey",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "EC", // external (property name)
        "crv": "P-256", // external (property name)
        "x": "Ums5WVgwRkRTVVFnU3k5c2xvZllMbEcwM3NPRW91ZzN", // external (property name)
        "y": "nDQW6XZ7b_u2Sy9slofYLlG03sOEoug3I0aAPQ0exs4" // external (property name)
      }
    },
    {
      "id": "did:example:123#key-5",
      "type": "JsonWebKey",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "EC", // external (property name)
        "crv": "P-384", // external (property name)
        "x": "VUZKSlUwMGdpSXplekRwODhzX2N4U1BYdHVYWUZsaXVDR25kZ1U0UXA4bDkxeHpE", // external (property name)
        "y": "jq4QoAHKiIzezDp88s_cxSPXtuXYFliuCGndgU4Qp8l91xzD1spCmFIzQgVjqvcP" // external (property name)
      }
    },
    {
      "id": "did:example:123#key-6",
      "type": "JsonWebKey",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "EC", // external (property name)
        "crv": "P-521", // external (property name)
        "x": "VTI5c1lYSmZWMmx1WkhNZ0dQTXhaYkhtSnBEU3UtSXZwdUtpZ0VOMnB6Z1d0U28tLVJ3ZC1uNzhuclduWnplRGMx", // external (property name)
        "y": "UW5WNVgwSnBkR052YVc0Z1VqY1B6LVpoZWNaRnliT3FMSUpqVk9sTEVUSDd1UGx5RzBnRW9NV25JWlhoUVZ5cFB5" // external (property name)
      }
    },
    {
      "id": "did:example:123#key-7",
      "type": "JsonWebKey",
      "controller": "did:example:123",
      "publicKeyJwk": {
        "kty": "RSA", // external (property name)
        "e": "AQAB", // external (property name)
        "n": "UkhWaGJGOUZRMTlFVWtKSElBdENGV2hlU1F2djFNRXh1NVJMQ01UNGpWazlraEpLdjhKZU1YV2UzYldIYXRqUHNrZGYyZGxhR2tXNVFqdE9uVUtMNzQybXZyNHRDbGRLUzNVTElhVDFoSkluTUhIeGoyZ2N1Yk82ZUVlZ0FDUTRRU3U5TE8wSC1MTV9MM0RzUkFCQjdRamE4SGVjcHl1c3BXMVR1X0RicXhjU253ZW5kYW13TDUyVjE3ZUtobE80dVh3djJIRmx4dWZGSE0wS21DSnVqSUt5QXhqRF9tM3FfX0lpSFVWSEQxdERJRXZMUGhHOUF6c24zajk1ZC1zYU" // external (property name)
      }
    }
  ]
}

例 14: 異なる検証メソッド型を持つDID文書

{
  "@context": "https://www.w3.org/ns/did/v1.1",
  "id": "did:example:123",
  "verificationMethod": [{
    "id": "did:example:123#key-0",
    "type": "Multikey",
    "controller": "did:example:123",
    "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
  }, {
    "id": "did:example:123#key-1",
    "type": "Multikey",
    "controller": "did:example:123",
    "publicKeyMultibase": "z6MtTjFFxQ4sQKS2wmozFAn5cxukmM46WR7e2vxfqZQsv4eh"
  }, {
    "id": "did:example:123#key-2",
    "type": "EcdsaSecp256k1VerificationKey2019",
    "controller": "did:example:123",
    "publicKeyMultibase": "zns2aFDq25fEV1NUd3wZ65sgtht4j5QjFW8JCAHdUJfLwfodt"
  }, {
    "id": "did:example:123#key-3",
    "type": "JsonWebKey",
    "controller": "did:example:123",
    "publicKeyJwk": {
      "kty": "EC", // external (property name)
      "crv": "P-256", // external (property name)
      "x": "Er6KSSnAjI70ObRWhlaMgqyIOQYrDJTE94ej5hybQ2M",
      "y": "pPVzCOTJwgikPjuUE6UebfZySqEJ0ZtsWFpj7YSPGEk"
    }
  }]
}

例 15: 相対DID URLを使用するDID文書

  {
    "@context": "https://www.w3.org/ns/did/v1.1",
    "id": "did:example:123",
    "verificationMethod": [
      {
        // 絶対DID URL値 did:example:123#key-1 に変換される相対DID URL
        "id": "#key-1",
        "type": "Ed25519VerificationKey2020",
        "controller": "did:example:123",
        "publicKeyMultibase": "z6MkmM42vxfqZQsv4ehtTjFFxQ4sQKS2w6WR7emozFAn5cxu"
      }
    ],
    "authentication": [
      "#key-1"
    ],
    "capabilityInvocation": [
      "#key-1"
    ],
    "capabilityDelegation": [
      "#key-1"
    ],
    "assertionMethod": [
      // 相対DID URL #key-1 の使用は、絶対DID URL値 did:example:123#key-1 の使用と同等である
      "did:example:123#key-1"
    ]
}

この節は非規範的である。

注記

これらの例は情報提供のみを目的としている。追加の例については、Verifiable Credentials Data Model v2.0を参照。

例 16: Multikey型の検証メソッドにリンクされた検証可能クレデンシャル

{
  // external (all terms in this example)
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/citizenship/v4rc1"
  ],
  "type": [
    "VerifiableCredential",
    "PermanentResidentCardCredential"
  ],
  "issuer": {
    "id": "did:key:zDnaeYGXycLmAn5m9akGtdL6rqBspGQPM7QZXW2CvJ3k9c2Bz",
    "image": "data:image/png;base64,iVBORw0KGgo...5CYII="
  },
  "name": "Permanent Resident Card",
  "description": "Government of Utopia Permanent Resident Card.",
  "credentialSubject": {
    "type": [
      "PermanentResident",
      "Person"
    ],
    "givenName": "JANE",
    "familyName": "SMITH",
    "gender": "Female",
    "image": "data:image/png;base64,iVBORw0KGgoAA...kJggg==",
    "residentSince": "2015-01-01",
    "commuterClassification": "C1",
    "birthCountry": "Arcadia",
    "birthDate": "1978-07-17",
    "permanentResidentCard": {
      "type": "PermanentResidentCard",
      "identifier": "83627465",
      "lprCategory": "C09",
      "lprNumber": "999-999-999"
    }
  },
  "validFrom": "2025-01-04T00:00:00Z",
  "validUntil": "2026-01-04T23:59:59Z",
  "proof": {
    "type": "DataIntegrityProof",
    "created": "2025-01-04T15:02:36Z",
    "verificationMethod": "did:key:zDnaeYGXycLmAn5m9akGtdL6rqBspGQPM7QZXW2CvJ3k9c2Bz#zDnaeYGXycLmAn5m9akGtdL6rqBspGQPM7QZXW2CvJ3k9c2Bz",
    "cryptosuite": "ecdsa-rdfc-2019",
    "proofPurpose": "assertionMethod",
    "proofValue": "z5CK4DPN7...Jpqwp"
  }
}

例 17: JsonWebKey型の検証メソッドにリンクされた検証可能クレデンシャル

{  // external (all terms in this example)
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/citizenship/v4rc1"
  ],
  "type": [
    "VerifiableCredential",
    "PermanentResidentCardCredential"
  ],
  "issuer": {
    "id": "did:example:123#key-1",
    "image": "data:image/png;base64,iVBORw0KGgo...5CYII="
  },
  "name": "Permanent Resident Card",
  "description": "Government of Utopia Permanent Resident Card.",
  "credentialSubject": {
    "type": [
      "PermanentResident",
      "Person"
    ],
    "givenName": "JANE",
    "familyName": "SMITH",
    "gender": "Female",
    "image": "data:image/png;base64,iVBORw0KGgoAA...kJggg==",
    "residentSince": "2015-01-01",
    "commuterClassification": "C1",
    "birthCountry": "Arcadia",
    "birthDate": "1978-07-17",
    "permanentResidentCard": {
      "type": "PermanentResidentCard",
      "identifier": "83627465",
      "lprCategory": "C09",
      "lprNumber": "999-999-999"
    }
  },
  "validFrom": "2025-01-04T00:00:00Z",
  "validUntil": "2026-01-04T23:59:59Z",
  "proof": {
    "type": "DataIntegrityProof",
    "created": "2025-01-04T15:02:36Z",
    "verificationMethod": "did:example:123#key-1",
    "cryptosuite": "ecdsa-jcs-2019",
    "proofPurpose": "assertionMethod",
    "proofValue": "z5m9akGtdL...6rqBspGQP"
  }
}

例 18: bls12381検証メソッドにリンクされた検証可能クレデンシャル

{  // external (all terms in this example)
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/citizenship/v4rc1"
  ],
  "type": [
    "VerifiableCredential",
    "PermanentResidentCardCredential"
  ],
  "issuer": {
    "id": "did:key:zUC7DojAAkoD8WpSS87KG6iuMSBd4wH1fZzmcwmakx4JfaXN7RLSES4wNCfWboHvULxGxRwiSsj6UYSgq1dWGusdwrrJsjUQQEb1oid3igF4hbSFzFjf9aWTJSphhu63vHGoAVE",
    "image": "data:image/png;base64,iVBORw0KGgoAA...CYII="
  },
  "name": "Permanent Resident Card",
  "description": "Government of Utopia Permanent Resident Card.",
  "credentialSubject": {
    "type": [
      "PermanentResident",
      "Person"
    ],
    "givenName": "JANE",
    "familyName": "SMITH",
    "gender": "Female",
    "image": "data:image/png;base64,iVBORw0KGgoAAA...3dgg==",
    "residentSince": "2015-01-01",
    "commuterClassification": "C1",
    "birthCountry": "Arcadia",
    "birthDate": "1978-07-17",
    "permanentResidentCard": {
      "type": "PermanentResidentCard",
      "identifier": "83627465",
      "lprCategory": "C09",
      "lprNumber": "999-999-999"
    }
  },
  "validFrom": "2025-01-04T00:00:00Z",
  "validUntil": "2026-01-04T23:59:59Z",
  "proof": {
    "type": "DataIntegrityProof",
    "verificationMethod": "did:key:zUC7DojAAkoD8WpSS87KG6iuMSBd4wH1fZzmcwmakx4JfaXN7RLSES4wNCfWboHvULxGxRwiSsj6UYSgq1dWGusdwrrJsjUQQEb1oid3igF4hbSFzFjf9aWTJSphhu63vHGoAVE#zUC7DojAAkoD8WpSS87KG6iuMSBd4wH1fZzmcwmakx4JfaXN7RLSES4wNCfWboHvULxGxRwiSsj6UYSgq1dWGusdwrrJsjUQQEb1oid3igF4hbSFzFjf9aWTJSphhu63vHGoAVE",
    "cryptosuite": "bbs-2023",
    "proofPurpose": "assertionMethod",
    "proofValue": "u2V0ChVhQik2d4...pc3N1ZXI"
  }
}

例 19: bls12381検証メソッドにリンクされた、検証可能クレデンシャルの選択的開示ゼロ知識証明

{
  // external (all terms in this example)
  "@context": "https://www.w3.org/ns/credentials/v2",
  "type": "VerifiablePresentation",
  // holder did:keyは相関を避けるためドメインごとにペアワイズである
  "holder": "did:key:z6MkveKdpgkQ1pwNktQ5Lc19epBrzFjMUeNMUZGFvezFF2dX",
  "verifiableCredential": {
    "@context": [
      "https://www.w3.org/ns/credentials/v2",
      "https://w3id.org/citizenship/v4rc1"
    ],
    "type": [
      "VerifiableCredential",
      "PermanentResidentCardCredential"
    ],
    "issuer": {
      "id": "did:web:unlinkable.example",
      "image": "data:image/png;base64,iVBORw0KGgoAA...CYII="
    },
    "credentialSubject": {
      "type": ["PermanentResident", "Person"],
      // countryのみが選択的に開示される
      "birthCountry": "Arcadia"
    },
    "proof": {
      "type": "DataIntegrityProof",
      "verificationMethod": "did:web:vcplayground.org#zUC7EwMqo9vCjFmj7ArU2SivcbeccAY6hd4nw5fVD6xD4W2vm9eVy6VqVnciAZRmPLXnuxuka5JTJVmgz66CxDno6eqZmvUViCckCcKg8A4s1R4i2JjyzrdTQs5zrfY4jJCHFCp",
      "cryptosuite": "bbs-2023",
      "proofPurpose": "assertionMethod",
      "proofValue": "u2V0DhV...3JnIn0"
    }
  },
  "proof": {
    "type": "DataIntegrityProof",
    "created": "2025-01-04T15:10:39Z",
    "verificationMethod": "did:key:z6MkveKdpgkQ1pwNktQ5Lc19epBrzFjMUeNMUZGFvezFF2dX#z6MkveKdpgkQ1pwNktQ5Lc19epBrzFjMUeNMUZGFvezFF2dX",
    "proofPurpose": "authentication",
    "challenge": "QZVVFcXlMPStFmpXTSktv",
    "domain": "https://unlinkable.example",
    "proofValue": "z5tXmHk...x2GvTt3bF"
  }
}

例 20: デコードされたJWTとしての検証可能クレデンシャル

{ // external (all terms in this example)
  "protected": {
    "kid": "did:example:123#_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A",
    "alg": "EdDSA"
  },
  "payload": {
    "@context": [
      "https://www.w3.org/ns/credentials/v2",
      "https://w3id.org/citizenship/v4rc1"
    ],
    "type": [
      "VerifiableCredential",
      "PermanentResidentCardCredential"
    ],
    "issuer": {
      "id": "did:key:zUC7Do...oAVE",
      "image": "data:image/png;base64,iVBORw0KGgoAA...CYII="
    },
    "name": "Permanent Resident Card",
    "description": "Government of Utopia Permanent Resident Card.",
    "credentialSubject": {
      "type": [
        "PermanentResident",
        "Person"
      ],
      "givenName": "JANE",
      "familyName": "SMITH",
      "gender": "Female",
      "image": "data:image/png;base64,iVBORw0KGgoAAA...3dgg==",
      "residentSince": "2015-01-01",
      "commuterClassification": "C1",
      "birthCountry": "Arcadia",
      "birthDate": "1978-07-17",
      "permanentResidentCard": {
        "type": "PermanentResidentCard",
        "identifier": "83627465",
        "lprCategory": "C09",
        "lprNumber": "999-999-999"
      }
    },
    "validFrom": "2025-01-04T00:00:00Z",
    "validUntil": "2026-01-04T23:59:59Z",
  },
  "signature": "qSv6d...bJRAw"
}

この節は非規範的である。

注記

これらの例は情報提供のみを目的としている。JWEヘッダーで不要な情報を開示しないことが、ベストプラクティスとみなされる。

例 21: kidを介して検証メソッドにリンクされたJWE

{ // external (all terms in this example)
  "ciphertext": "3SHQQJajNH6q0fyAHmw...",
  "iv": "QldSPLVnFf2-VXcNLza6mbylYwphW57Q",
  "protected": "eyJlbmMiOiJYQzIwUCJ9",
  "recipients": [
    {
      "encrypted_key": "BMJ19zK12YHftJ4sr6Pz1rX1HtYni_L9DZvO1cEZfRWDN2vXeOYlwA",
      "header": {
        "alg": "ECDH-ES+A256KW",
        "apu": "Tx9qG69ZfodhRos-8qfhTPc6ZFnNUcgNDVdHqX1UR3s",
        "apv": "ZGlkOmVsZW06cm9wc3RlbjpFa...",
        "epk": {
          "crv": "X25519",
          "kty": "OKP",
          "x": "Tx9qG69ZfodhRos-8qfhTPc6ZFnNUcgNDVdHqX1UR3s"
        },
        "kid": "did:example:123#zC1Rnuvw9rVa6E5TKF4uQVRuQuaCpVgB81Um2u17Fu7UK"
      }
    }
  ],
  "tag": "xbfwwDkzOAJfSVem0jr1bA"
}

この節は非規範的である。

以下は、4. データモデル、 5. 中核プロパティ、7. メソッド、および [DID-RESOLUTION] の関係を示す図である。

DIDおよびDID文書は検証可能データレジストリに記録される。DIDはDID文書へ解決される。
DIDはDID主体を参照する。DIDコントローラはDID文書を制御する。
DID URLはDIDを含む。DID URLはDID文書フラグメントまたは外部資源へ
間接参照される。DIDリゾルバはresolve関数を実装する。DID URLデリファレンサは
dereferencing関数を実装する。DIDメソッドは検証可能データレジストリを操作する。
DIDリゾルバおよびDID URLデリファレンサはDIDメソッドに指示する。 — 図 4 DIDアーキテクチャおよび基本構成要素の関係の詳細な概要。

この節は非規範的である。

DIDの作成は、各DIDメソッドによって定義されるプロセスである。 did:keyなど、一部のDIDメソッドは純粋に生成的であり、単一の暗号材料を適合する表現へ変換することで、DIDおよびDID文書が生成されるようなものである。その他のDIDメソッドでは、検証可能データレジストリの使用が必要になる場合があり、それぞれのDIDメソッドによって定義されるように、登録が完了した場合にのみ、第三者によってDIDおよびDID文書が存在すると認識される。その他のプロセスが、それぞれのDIDメソッドによって定義される場合もある。

この節は非規範的である。

DIDはURI（Uniform Resource Identifier）の特定の種類であるため、 DIDは任意の資源を参照できる。 [RFC3986] によれば:

「resource」という用語は、URIによって識別され得るものすべてについて一般的な意味で使用される。 [...] 資源は必ずしもインターネット経由でアクセス可能である必要はない。

資源はデジタルでも物理的でも、抽象的でも具体的でもあり得る。URIを割り当てられる任意の資源には、 DIDを割り当てることができる。 DIDが参照する資源が DID主体である。

DIDコントローラは、DID主体を決定する。 DID主体を DID自体を見ることで判断できるとは期待されない。なぜなら、DIDは一般に、人間ではなく機械にとってのみ意味を持つためである。DIDが DID主体に関する情報を含む可能性は低い。そのため、DID主体に関する追加情報は、DIDを DID文書へ解決すること、DIDに関する検証可能クレデンシャルを取得すること、またはDIDのその他の記述を通じてのみ発見できる。

取得されたDID文書内のidプロパティの値は、解決されるDIDと常に一致しなければならないが、 DIDが参照する実際の資源が時間とともに変化できるかどうかは、DIDメソッドに依存する。たとえば、DIDメソッドがDID主体の変更を許可する場合、特定の役割の現在の就任者—たとえば会社のCEO—のためのDIDを生成するために使用でき、その役割を占める実際の人物は、そのDIDが解決される時点によって異なり得る。

この節は非規範的である。

DIDは、DID主体を参照し、（DIDメソッドによって指定されるプロトコルに従って） DID文書へ解決される。 DID文書は、 DID主体とは別個の資源ではなく、 DIDとは別のURI を持たない。むしろ、DID文書は、DID主体との暗号学的に検証可能な相互作用を可能にする目的で、 DIDコントローラによって制御される DID解決の成果物である。

この区別は、下に示すグラフモデルによって例示される。

DIDコントローラがDID主体を参照するためにDIDを割り当て、
DID主体を記述するDID文書へ解決する方法のグラフモデルを示す図。 — 図 5 DIDは、DIDコントローラによって、DID主体を参照し、 DID文書へ解決されるように割り当てられる識別子であり、そのDID文書は DID主体を記述する。DID 文書はDID 解決の成果物であり、DID主体とは別個の資源ではない。関連項目: 説明的な記述。

図の上部には、塗りつぶされた黒い円が2つあり、左側の1つは "DID Controller"、右側の1つは"DID Subject"とラベル付けされている。下部には、右下の角が内側に折れ曲がって小さな三角形を形成する長方形があり、 "DID Document"というラベルが含まれている。矢印はこれら3つの項目の間を次のように結んでいる。赤い実線の矢印は、DID Controllerの円から右方向にDID Subjectの円へ直接向かい、上に大きなフォントで"DID"、下に小さな斜体フォントで"Identifies"とラベル付けされている。他の矢印ラベルも小さな斜体フォントである。"Resolves to"とラベル付けされた赤い点線の矢印は、 DID Controllerから始まり、最初の矢印と同じ線から下へ曲がってDID Documentの長方形を指す。 "Controls"とラベル付けされた緑の矢印は、DID ControllerからDID Documentへ直接向かう。 "Controller"とラベル付けされた緑の矢印は反対方向、DID DocumentからDID Controllerへ向かい、図の左側へ外向きの弧を描く。"Describes"とラベル付けされた青い矢印は、DID Documentから DID Subjectへ直接向かう。

この節は非規範的である。

DID文書内の各プロパティは、 DIDコントローラによる記述であり、次のものを記述する:

DID主体の識別子を定義する文字列（例: idおよびalsoKnownAs プロパティ）
DID主体と相互作用する方法（例: verificationMethodおよびservice プロパティ）。
DID 文書の特定の表現を解釈する方法（例: JSON-LD表現の@contextプロパティ）。

DID文書で唯一必須のプロパティは idであるため、これはDID文書内に存在することが保証される唯一の記述である。この記述は、図 5で、DIDとDID主体との直接リンクとして示されている。

この節は非規範的である。

DID主体についての追加情報を発見するための選択肢は、DID文書内に存在するプロパティに依存する。 serviceプロパティが存在する場合、サービスエンドポイントから追加情報を要求できる。たとえば、DID主体を記述する1つ以上の主張（属性）について、検証可能クレデンシャルをサポートするサービスエンドポイントに問い合わせることによってである。

もう1つの選択肢は、DID文書内に存在する場合、alsoKnownAs プロパティを使用することである。DID コントローラは、それを使用して、同じDID主体を参照するその他のURI（他のDIDを含む）の一覧を提供できる。これらのURIを解決または間接参照すると、下の図に示すように、DID主体のその他の記述または表現が得られる場合がある。

別の資源を表す別ノードへの弧を持つalsoKnownAsプロパティを含み、
その別資源がDID主体の別の記述へ間接参照されるグラフモデルを示す図。 — 図 6 DID文書は、alsoKnownAsプロパティを使用して、別のURI（他のDIDを含むが、必ずしもそれに限らない）が同じDID主体を参照することを主張できる。関連項目: 説明的な記述。

図には、塗りつぶされた小さな黒い円が3つ、角が折れた長方形が2つ、それらの間の矢印、およびラベルが次のように含まれる。左上には"DID Controller"とラベル付けされた円がある。右上には"DID Subject"とラベル付けされた円がある。右下中央にはラベルのない円がある。右下には"Description"とラベル付けされた長方形がある。図の中央には"DID Document"とラベル付けされた長方形がある。DID Documentの長方形内では、そのラベルの下に 2行のコード、"alsoKnownAs: ["と"URI]"がある。黒い矢印は2行目から右へ伸び、長方形の境界を横切って、図の右側にあるラベルのない円を指す。この矢印は上に大きなフォントで "URI"、下に斜体で"Identifies"とラベル付けされている。黒い矢印はラベルのない円から下方向に Descriptionの長方形へ向かい、"Dereferences to"とラベル付けされている。"Describes"とラベル付けされた青い矢印は、Descriptionから右側に弧を描いてDID Subjectへ上向きに指す。同じく"Describes"とラベル付けされた青い矢印は、図の中央の"DID Document"とラベル付けされた長方形から右上のDID Subjectの円へ直接向かう。"alsoKnownAs"とラベル付けされた赤い矢印は、 DID Subjectからラベルのない円へ下向きに指す。上部には、赤い矢印が左から右へ、 DID ControllerからDID Subjectへ向かい、上に大きなフォントで"DID"、下に斜体で "Identifies"とラベル付けされている。赤い点線は同じ場所から始まるが分岐して下方へ曲がり、図中央のDID Documentの長方形を指す。"Controls"とラベル付けされた緑の矢印は、 DID ControllerからDID Documentへ直接向かう。別の緑の矢印は反対方向を指し、"Controller"とラベル付けされ、図の左側へ外向きに曲がってDID DocumentからDID Controllerへ向かう。

この節は非規範的である。

DID主体がインターネットから取得可能なデジタル資源である場合、 DIDメソッドは、DID URLを構築して、 DID主体自体の表現を返すことを選択できる。たとえば、永続的で暗号学的に検証可能な識別子を必要とするデータスキーマに DIDを割り当て、指定されたパスまたはクエリを渡すことを、そのスキーマの表現を取得する標準的な方法として使用できる。

同様に、DIDは、（画像などの）デジタル資源を参照するために使用でき、その機能が該当するDIDメソッドでサポートされている場合、そのデジタル資源は検証可能データレジストリから直接返され得る。

この節は非規範的である。

Webページまたはその他のWeb資源のコントローラが、それに永続的で暗号学的に検証可能な識別子を割り当てたい場合、そのコントローラはそれにDIDを与えることができる。たとえば、ブログホスティング会社（そのホスティング会社のドメイン配下）でホストされるブログの著者は、そのブログのためのDIDを作成できる。DID文書で、著者はブログの現在のURLを指す alsoKnownAsプロパティを含めることができる。例:


        "alsoKnownAs": ["https://myblog.blogging-host.example/home"]

その後、著者がブログを別のホスティング会社（または著者自身のドメイン）へ移動した場合、著者はDID文書を更新して、ブログの新しいURLを指すようにできる。例:


        "alsoKnownAs": ["https://myblog.example/"]

DIDは、事実上ブログURLに対する間接参照の層を追加する。この間接参照の層は、ブログホスティング会社などの外部の管理権限ではなく、著者の制御下にある。これにより、DIDは、ネットワーク上の場所が時間とともに変化し得る情報資源の永続識別子である、拡張された URN（Uniform Resource Name）として効果的に機能できる。

この節は非規範的である。

混乱を避けるため、DID主体を、DIDコントローラとの関係に基づいて、互いに素な2つの集合に分類すると有用である。

この節は非規範的である。

図 7に示される最初のケースは、 DID主体がDIDコントローラでもある一般的なシナリオである。これは、個人または組織が自己識別のためにDIDを作成する場合に該当する。

DID主体からDIDコントローラへの同等性の弧を持つグラフモデルを示す図。 — 図 7 DID主体は、DIDコントローラと同じエンティティである。関連項目: 説明的な記述。

図には小さな黒い円が2つあり、左上の1つは"DID Controller"、右上の1つは"DID Subject"とラベル付けされている。赤い実線の矢印は、DID Controllerの円からDID Subjectの円へ伸び、矢印の上に大きな太字で"DID"、下に小さな斜体で"Identifies"とラベル付けされている。 "Equivalence"とラベル付けされた赤い点線の両向き矢印は、2つの円の間および上方の空間で弧を描いて伸びている。図の下部には、角の折れた黒い輪郭の長方形があり、 "DID Document"というラベルを含む。このDID Document長方形とDID ControllerおよびDID Subjectを表す小さな黒い円との間には、斜体ラベル付きの矢印が次のように向かう。青い矢印はDID DocumentからDID Subjectへ向かい、"Describes"とラベル付けされている。緑の矢印はDID ControllerからDID Documentへ向かい、"Controls"とラベル付けされている。緑の矢印はDID DocumentからDID Controllerへ向かい、外向きの弧を描いて "Controller"とラベル付けされている。赤い点線の矢印は"Resolves to"とラベル付けされ、 DID Controllerから右方向に始まり、DID Subjectへの矢印から分岐して下へ曲がり、 DID Documentを指す。

グラフモデルの観点からは、図 7でDIDコントローラおよびDID主体として識別されるノードは別個であるが、それらを結び付けて意味論上の同等関係を表す論理的な弧が存在する。

この節は非規範的である。

2番目のケースは、DID主体が DIDコントローラとは別個のエンティティである場合である。これは、たとえば、親が子どものためにDIDを作成し、その制御を維持する場合、企業が子会社のためにDIDを作成し、その制御を維持する場合、または製造者が製品、IoTデバイス、もしくはデジタルファイルのために DIDを作成し、その制御を維持する場合である。

グラフモデルの観点からは、集合1との唯一の違いは、DID主体と DIDコントローラのノード間に同等性の弧の関係が存在しないことである。

この節は非規範的である。

DID文書は、複数のDIDコントローラを持つ場合がある。これは2つの方法のうちいずれかで起こり得る。

この節は非規範的である。

この場合、各DIDコントローラは単独で行動することができる。すなわち、それぞれがDID文書を独立して更新する完全な権限を持つ。グラフモデルの観点では、この構成では:

追加される各DIDコントローラは、別個の追加グラフノードである（自身のDIDによって識別される場合がある）。
各DIDコントローラとDID文書との間には、同じ弧（"controls"および "controller"）が存在する。

3つのDIDコントローラが、それぞれDID文書との独立した
制御関係を持つことを示す図 — 図 8 それぞれが独立して行動できる、複数の独立したDIDコントローラ。関連項目: 説明的な記述

左側に3つの黒い円が縦に並び、それぞれ"DID Controller"とラベル付けされている。これらの各円から、緑の矢印のペアが図の中央、"DID Document"とラベル付けされた 1つの長方形へ伸びている。この長方形は、右下の角が切り取られて内側に折れ、角がめくれた紙片を表すかのような小さな三角形を形成している。各緑の矢印のペアは、黒い円から長方形へ向かい"Controls"とラベル付けされた1本の矢印と、反対方向、すなわち長方形から黒い円へ向かい"Controller"とラベル付けされた1本の矢印で構成される。長方形の右側からは、"Describes"とラベル付けされた青い矢印が伸び、 "DID Subject"とラベル付けされた黒い円を指す。

この節は非規範的である。

グループ制御の場合、DIDコントローラは、複数のデジタル署名（"multi-sig"）またはしきい値数のデジタル署名（"m-of-n"）を必要とする暗号アルゴリズムを使用する場合など、何らかの形で共同して行動することが期待される。証明を検証するためのこれらの追加しきい値は、検証メソッド内で、第5.2 検証メソッド節で説明されるように表現できる。または、プライバシー上の理由から、特定のデジタル署名の生成に参加した DIDコントローラの数が隠されるような、検証メソッドの検証材料の本質的な一部であり得る。グループのメンバーによって実行される暗号操作の組み合わせによって証明が生成されることを要求する検証メソッドは、DID文書の内容を制御するために使用できる。これが正確にどのように実現されるかは、個々のDIDメソッド仕様に依存する。

機能的な観点からは、この選択肢は単一のDIDコントローラに似ている。なぜなら、 DIDコントローラグループ内の各 DIDコントローラはそれぞれ独自のグラフノードを持つが、実際の制御は、図 9に示すように、DIDコントローラグループを表す単一の論理グラフノードへ集約されるためである。

3つのDIDコントローラが、DID文書を制御する単一の
DIDコントローラグループとして共同することを示す図 — 図 9 DIDコントローラグループとして共同して行動することが期待される複数のDIDコントローラ。関連項目: 説明的な記述。

左側には3つの塗りつぶされた黒い円があり、左側の波括弧によって"DID Controller Group"とラベル付けされている。これら3つの円それぞれから、緑の矢印が中央右へ伸びる。これら3本の矢印は、塗りつぶされた単一の白い円へ収束する。この白い円の右側と、 "DID Document"とラベル付けされた、角のめくれたページの形をした長方形との間を、水平な緑の矢印のペアが接続する。上側の矢印は白い円から長方形へ右向きに伸び、 "Controls"とラベル付けされている。下側の矢印は長方形から白い円へ左向きに伸び、 "Controller"とラベル付けされている。長方形の右側からは、"Describes"とラベル付けされた青い矢印が伸び、"DID Subject"とラベル付けされた黒い円を指す。

この構成は、DID主体が組織、企業、政府機関、コミュニティ、または単一の個人によって制御されないその他のグループである場合に適用されることが多い。

この節は非規範的である。

DID文書は、DID主体を参照する、正確に1つのDIDを持つ。 DIDは、idプロパティの値として表現される。このプロパティ値は、DID文書の存続期間中、不変である。

しかし、DIDによって識別される資源、すなわち DID主体が時間とともに変化する可能性はある。これはDIDコントローラの排他的権限の下にある。詳細については、8.10 永続性節を参照。

この節は非規範的である。

DID文書のDIDコントローラは、時間とともに変化する場合がある。しかし、それがどのように実装されているかによっては、DID コントローラの変更は、DID文書自体の変更によって明らかにならない可能性がある。たとえば、その変更が、検証メソッドの1つ以上に使用される基礎となる暗号鍵またはその他の制御の所有権の移行を通じて実装される場合、それは標準的な鍵ローテーションと区別できない可能性がある。

一方、その変更が controller プロパティの値を変更することで実装される場合、それは透明である。

DIDコントローラの変更を検証することが重要である場合、実装者は、改訂されたDID文書内の検証メソッドに対して、新しいDIDコントローラを認証することが助言される。

この節は非規範的である。

ワーキンググループは、議長であるBrent ZundelおよびDan Burnett、ならびに W3C Staff ContactであるIvan Hermanに対し、ワーキンググループを生産的な方向へ導き続け、標準化プロセスの深く危険な水域を航行するためのたゆまぬ尽力について、深い感謝と心からの謝意を表する。

ワーキンググループは、この仕様の作成につながった作業に感謝し、私たちの作業に深い影響を与えた技術および仕様に取り組んだ個人に対して、誠実な感謝を表する。特に、これには1990年代および 2000年代におけるPhil Zimmerman、Jon Callas、Lutz Donnerhacke、Hal Finney、David Shaw、 Rodney Thayerによる Pretty Good Privacy (PGP)に関する作業が含まれる。

2010年代半ば、後にDecentralized Identifiersとなるものの初期実装は、Jeremie MillerのTelehashプロジェクト、およびDave LongleyとManu Spornyが主導したW3C Web Payments Community Groupの作業と協力して構築された。約1年後、XDI.org Registry Working Groupは、既存の識別子レジストリを置き換えるための分散型技術の探索を開始した。Decentralized Identifiersの概念を探索した最初期の文書論文の一部は、Christopher Allenによって開催された最初の数回のRebooting the Web of Trustワークショップに遡ることができる。その作業は、Christopher Allen、Drummond Reed、Les Chasen、Manu Sporny、 Anil Johnの間の重要な協力につながった。Anilはこの技術に可能性を見出し、この領域を探索するための初期の政府資金を割り当てた。Anil Johnの支援と長年にわたる指導がなければ、Decentralized Identifiersが今日の位置に到達した可能性は低い。Rebooting the Web of Trustワークショップでのさらなる洗練により、Drummond Reed、Les Chasen、Christopher Allen、Ryan Grantが編集した最初の実装者向け文書が生まれた。貢献者にはManu Sporny、Dave Longley、Jason Law、Daniel Hardman、Markus Sabadello、Christian Lundkvist、Jonathan Endersbyが含まれた。この初期作業はその後、W3C Credentials Community Groupに統合され、さらにインキュベートされ、最終的にグローバル標準化のために W3C Decentralized Identifiers Working Groupへ移行した。

この仕様に関する作業の一部は、United States Department of Homeland Security's (US DHS) Science and Technology Directorateから、契約HSHQDC-16-R00012-H-SB2016-1-002およびHSHQDC-17-C-00019の下で、ならびにUS DHS Silicon Valley Innovation Programから、契約70RSAT20T00000010、70RSAT20T00000029、 70RSAT20T00000030、70RSAT20T00000045、70RSAT20T00000003、および70RSAT20T00000033の下で資金提供を受けた。この仕様の内容は、必ずしもU.S. Governmentの立場または政策を反映するものではなく、公式な承認を推定すべきではない。

この仕様に関する作業の一部は、European UnionのStandICT.euプログラムから、サブグラント契約番号 CALL05/19の下でも資金提供を受けた。この仕様の内容は、必ずしもEuropean Unionの立場または政策を反映するものではなく、公式な承認を推定すべきではない。

この仕様に関する作業は、Christopher Allen、Shannon Appelcline、Kiara Robles、Brian Weller、Betty Dhamers、Kaliya Young、Kim Hamilton Duffy、Manu Sporny、Drummond Reed、Joe Andrieu、Heather Vescentが促進したRebooting the Web of Trustコミュニティによっても支援された。この仕様の開発は、Kim Hamilton Duffy、Joe Andrieu、Christopher Allen、Heather Vescent、 Wayne Changが議長を務めたW3C Credentials Community Groupによっても支援された。Phil Windley、Kaliya Young、Doc Searls、Heidi Nobantu Saulが促進したInternet Identity Workshopの参加者も、この仕様について議論し、改善し、参加者を教育するために設計された多数の作業セッションを通じて、この作業を支援した。

ワーキンググループは、次の個人のこの仕様への貢献に感謝する（アルファベット順、Githubハンドルは @で始まり、姓としてソートされている）: Denis Ah-Kang, Nacho Alamillo, Christopher Allen, Joe Andrieu, Antonio, Phil Archer, George Aristy, Baha, Juan Benet, BigBlueHat, Dan Bolser, Chris Boscolo, Pelle Braendgaard, Daniel Buchner, Daniel Burnett, Juan Caballero, @cabo, Tim Cappalli, Melvin Carvalho, David Chadwick, Wayne Chang, Sam Curren, Hai Dang, Tim Daubenschütz, Oskar van Deventer, Kim Hamilton Duffy, Arnaud Durand, Ken Ebert, Veikko Eeva, @ewagner70, Carson Farmer, Nikos Fotiou, Gabe, Gayan, @gimly-jack, @gjgd, Ryan Grant, Peter Grassberger, Adrian Gropper, Amy Guy, Daniel Hardman, Kyle Den Hartog, Philippe Le Hegaret, Ivan Herman, Michael Herman, Alen Horvat, Dave Huseby, Marcel Jackisch, Mike Jones, Andrew Jones, Tom Jones, jonnycrunch, Gregg Kellogg, Michael Klein, @kdenhartog-sybil1, Paul Knowles, @ktobich, David I. Lehn, Charles E. Lehner, Michael Lodder, @mooreT1881, Dave Longley, Tobias Looker, Wolf McNally, Robert Mitwicki, Mircea Nistor, Grant Noble, Mark Nottingham, @oare, Darrell O'Donnell, Vinod Panicker, Dirk Porsche, Praveen, Mike Prorock, @pukkamustard, Drummond Reed, Julian Reschke, Yancy Ribbens, Justin Richer, Rieks, @rknobloch, Mikeal Rogers, Evstifeev Roman, Troy Ronda, Leonard Rosenthol, Michael Ruminer, Markus Sabadello, Cihan Saglam, Samu, Rob Sanderson, Wendy Seltzer, Mehran Shakeri, Jaehoon (Ace) Shim, Samuel Smith, James M Snell, SondreB, Manu Sporny, @ssstolk, Orie Steele, Shigeya Suzuki, Sammotic Switchyarn, @tahpot, Oliver Terbu, Ted Thibodeau Jr., Joel Thorstensson, Tralcan, Henry Tsai, Rod Vagg, Mike Varley, Kaliya "Identity Woman" Young, Eric Welton, Fuqiao Xue, @Yue, Dmitri Zagidulin, @zhanb, and Brent Zundel.

分散型識別子（DID）v1.1

中核アーキテクチャ、データモデル、および表現

概要

この文書のステータス

1. はじめに

1.1 単純な例

1.2 設計目標

1.3 アーキテクチャ概要

1.4 適合性

1.5 想定読者

2. 用語

3. 識別子

3.1 DID構文

3.2 DID URL構文

パス

クエリ

フラグメント

3.2.1 相対DID URL

4. データモデル

4.1 拡張性

5. 中核プロパティ

検証メソッドのプロパティ

サービスのプロパティ

5.1 識別子

5.1.1 DID主体

5.1.2 DIDコントローラ

5.1.3 識別子の制約

5.2 検証メソッド

5.3 検証関係

5.4 サービス

6. 表現

6.1 生成と消費

6.2 JSON

6.2.1 生成

6.2.2 消費

6.2.3 JSON-LDプロセッサ

6.2.4 リモート資源の完全性

6.3 メディアタイプ

6.3.1 メディアタイプの精度

7. メソッド

7.1 メソッド構文

7.2 メソッド操作

7.3 セキュリティ要件

7.4 プライバシー要件

8. セキュリティに関する考慮事項

8.1 DIDリゾルバの選択

8.2 否認防止

8.3 トラストレス システムにおける失効

8.4 DID復旧

8.5 人間に分かりやすい 識別子の役割

8.6 拡張URNとしてのDID

8.7 不変性

8.8 DID文書内の暗号化データ

8.9 同等性プロパティ

8.10 永続性

8.11 競合する 考慮事項の評価

9. プライバシーに関する考慮事項

9.1 グループプライバシー

A. 例

A.1 DID文書

A.2 証明

A.3 暗号化

B. アーキテクチャ上の考慮事項

B.1 詳細なアーキテクチャ図

B.2 DIDの作成

B.3 DID主体の決定

B.4 DID文書の参照

B.5 DID文書内の記述

B.6 DID主体に ついての追加情報の発見

B.7 DID主体の表現を 提供する

B.8 既存のWeb資源への DIDの割り当て

B.9 DID コントローラとDID主体の関係

B.9.1 集合 #1: DID主体はDIDコントローラである

B.9.2 集合 #2: DID主体はDIDコントローラではない

B.10 複数のDIDコントローラ

B.10.1 独立制御

B.10.2 グループ制御

B.11 DID主体の変更

B.12 DIDコントローラの変更

C. 改訂履歴

8.3 トラストレスシステムにおける失効

8.5 人間に分かりやすい識別子の役割

8.11 競合する考慮事項の評価

B.6 DID主体についての追加情報の発見

B.7 DID主体の表現を提供する