分散型識別子(DID)v1.0

非規範的と記している項と同じく、この仕様のすべての作成ガイドライン、図、例、注は、非規範的です。この仕様のその他の部分はすべて規範的です。

このドキュメントの「することができる／してもよい(MAY)」、「しなければならない(MUST)」、「してはならない(MUST NOT)」、「選択できる／任意である(OPTIONAL)」、「推奨される(RECOMMENDED)」、「必須である／要求される(REQUIRED)」、「すべきである／する必要がある(SHOULD)」、「すべきでない／する必要がない(SHOULD NOT)」というキーワードは、ここで示しているように、すべて大文字で表示されている場合にのみ、BCP 14[RFC2119] [RFC8174]で記述されているように解釈されるべきです。

このドキュメントには、JSONとJSON-LDのコンテンツを含む例が含まれています。これらの例には、インライン・コメント(//)や、例の価値をほとんど高めることのない情報を示す省略記号(...)の使用など、無効な文字が含まれているものもあります。実装者がこの情報を有効なJSONやJSON-LDとして用いたい場合は、このコンテンツを削除するように注意してください。

一部の例には、この仕様では定義していない用語(プロパティー名と値の両方)が含まれています。それらは、(// 外部(プロパティー名|値))というコメントで示しています。このような用語をDIDドキュメントで用いた場合には、形式的な定義とJSON-LDコンテキストの両方へのリンクとともに、DID仕様レジストリ[DID-SPEC-REGISTRIES]に登録することが期待されます。

DIDとDIDドキュメントの実装の相互運用性は、この仕様に準拠したDIDとDIDドキュメントを作成、解析する実装の機能を評価することによってテストされます。DIDとDIDドキュメントのプロデューサとコンシューマの相互運用性は、DIDとDIDドキュメントの適合性を確保することによって提供されます。DIDメソッド仕様の相互運用性は、個々のDIDメソッド仕様の詳細によって提供されます。ウエブ・ブラウザがすべての既知のURIスキームを実装する必要がないのと同様に、DIDと連携する適合ソフトウェアがすべての既知のDIDメソッドを実装する必要はないものと理解されています。しかし、特定のDIDメソッドのすべての実装は、そのメソッドに対して相互運用可能であることが期待されます。

適合DID(conforming DID)は、3. 識別子で規定している規則を具体的に表したもので、同項の関連する規範的なステートメントに準拠しています。

適合DIDドキュメント(conforming DID document)は、この仕様で記載しているデータ・モデルを具体的に表したもので、4. データ・モデルと5. コア・プロパティーの関連する規範的なステートメントに準拠しています。適合ドキュメントのシリアル化形式は、6. 表現で記述しているように、確定的で、双方向的で、ロスのないものです。

適合プロデューサ(conforming producer)は、適合DIDまたは適合DIDドキュメントを生成し、6. 表現の関連する規範的なステートメントに準拠したソフトウェアおよび/またはハードウェアとして実現される任意のアルゴリズムです。

適合コンシューマ(conforming consumer)は、適合DIDまたは適合DIDドキュメントを利用し、6. 表現の関連する規範的なステートメントに準拠したソフトウェアおよび/またはハードウェアとして実現される任意のアルゴリズムです。

適合DIDリゾルバ(conforming DID resolver)は、7.1 DID解決の関連する規範的なステートメントに準拠したソフトウェアおよび/またはハードウェアとして実現される任意のアルゴリズムです。

適合DID URLデリファレンサ(conforming DID URL dereferencer)は、7.2 DID URL逆参照の関連する規範的なステートメントに準拠したソフトウェアおよび/またはハードウェアとして実現される任意のアルゴリズムです。

適合DIDメソッド(conforming DID method)は、8. メソッドの関連する規範的なステートメントに準拠した任意の仕様です。

DID仕様レジストリ[DID-SPEC-REGISTRIES]には、DIDメソッド名とそれに対応するDIDメソッド仕様の参考となるリストが含まれています。実装者は、特定のDIDメソッド名でどのDIDメソッド仕様を用いるかを義務づける中央機関が存在しないことを念頭に置く必要があります。特定のDIDリゾルバがDIDメソッドを正しく実装しているかどうかに疑問がある場合、DID仕様レジストリを用いて登録済みの仕様を調べ、どのDIDリゾルバの実装を用いるべきかについて十分な情報を得た上で決定することができます。

デジタルの世界または物理的な世界のエンティティーをDID、DIDドキュメントまたは暗号材料にバインディングするには、この仕様書で検討しているセキュリティ・プロトコルを用いる必要があります。以下の項では、いくつかの考えられるシナリオと、その中のエンティティーが認証または承認を目的としてDIDまたはDIDドキュメントに対する管理を証明する方法について説明します。

DIDドキュメントが、DIDサブジェクトの認証や承認を目的としたサービスを公開する場合に(5.4 サービスの項を参照)、そのサービス・エンドポイントでサポートされる認証プロトコルの要件に準拠する責任は、サービス・エンドポイントの提供者、サブジェクトまたは要求側にあります。

DIDとDIDドキュメントの更新の否認防止は、次の場合にサポートされます。

• 検証可能なデータ・レジストリが、検証可能なタイムスタンプをサポートしている。DID解決処理中に使用できる有用なタイムスタンプの詳細については、7.1.3 DIDドキュメント・メタデータを参照。
• サブジェクトが、9.5 DIDドキュメントの変更通知で詳しく説明している不正な更新を監視している。
• サブジェクトが、DIDメソッドの認証メカニズムに従って、悪意のある更新を元に戻す十分な機会を得ている。

DIDドキュメントに対する不正な変更に対する1つの軽減策は、DIDサブジェクトを監視し、変更があった場合に積極的に通知することです。これは、登録済みの電子メール・アドレスにパスワードのリセット通知を送信することで、従来のユーザ名/パスワードのアカウントの乗っ取りを防止するのに似ています。

DIDの場合、そのような通知を生成する中間登録機関やアカウントの提供者は存在しません。しかし、DIDが登録されている検証可能なデータ・レジストリが変更通知を直接サポートしている場合は、サブスクリプション・サービスをDIDコントローラに提供することができます。通知は、既存のDIDに記載されている関連するサービス・エンドポイントに直接送信することができます。

DIDコントローラが(検証可能なデータ・レジストリ自体以外の)第三者監視サービスに依存することを選択した場合、別の攻撃進路が導入されることになります。

分散型識別子のアーキテクチャでは、暗号材料や暗号デジタル署名の有効期限ポリシーを実施する中央機関が存在しない可能性があります。したがって、要求側は、DIDリゾルバや検証ライブラリなどの支援ソフトウェアを用いて、暗号材料が使用時に有効期限切れでなかったことを検証します。要求側は、検証処理への入力に加えて、独自の有効期限ポリシーを採用する場合があります。例えば、要求側によって、5分前までの認証を受け入れる場合もあれば、高精度の時間資源にアクセスできる要求側が、最新の500ミリ秒以内のタイムスタンプ付き認証を求める場合もあります。

要求側が、従来の暗号デジタル署名の検証など、既に有効期限切れとなった暗号材料の使用を延長する正当なニーズを持っている場合もあります。このような状況では、要求側は、検証ソフトウェアに、暗号キー材料の有効期限切れを無視するか、使用した時に暗号キー材料が有効期限切れだったかどうかを判断するように指示することができます。

ローテーションとは、DIDドキュメントに新しい検証メソッドが追加されたときに、既存の検証メソッドに関連づけられている秘密の暗号材料を無効化または廃止できるようにする管理処理です。以後、コントローラが古い秘密の暗号材料を用いて生成した新しい証明は、代わりに新しい暗号材料を用いて生成し、新しい検証メソッドを用いて検証できるようになります。

コントローラが検証メソッドを頻繁にローテーションすることで、侵害された1つの検証メソッドの攻撃者にとっての価値を下げることができるため、ローテーションは、検証メソッドの侵害を防ぐための有効なメカニズムです。ローテーションの直後に失効を行うことは、メッセージの暗号化や認証に関するものなど、コントローラが短期間の検証用に指定する検証メソッドに有効です。

検証メソッドのローテーショの使用を検討する際には、次の留意点が役立つ可能性があります。

• 検証メソッドのローテーションは、事前予防的なセキュリティ対策です。
• 一般的に、検証メソッドのローテーションを定期的に行うことがベスト・プラクティスと考えられています。
• セキュリティが高い環境では、より頻度の高い検証メソッドのローテーションを採用する傾向があります。
• 検証メソッドのローテーションは、DIDドキュメントの現在または最新のバージョンへの変更としてのみ明示されます。
• 検証メソッドが長期間稼働していたり、多くの操作に用いられていたりする場合に、コントローラは、ローテーションを実行したいと考える可能性があります。
• 検証メソッドを頻繁にローテーションすることは、関連付けられている資格証明を継続的に更新またはリフレッシュすることを余儀なくされる関係者にとって苛立たしいことかもしれません。
• 最新バージョンのDIDドキュメントに存在しない検証メソッドに依存する証明や署名は、ローテーションの影響を受けません。このような場合、検証ソフトウェアには、証明や署名の有効性を判断するために、特定の検証メソッドが有効であったと思われる時期や、履歴記録を含む検証可能なデータ・レジストリへのアクセスなどの追加情報が必要な場合があります。このオプションは、すべてのDIDメソッドで利用できるわけではありません。
• DIDメソッドの操作に関する項では、検証メソッドのローテーションを実行するために用いられると見込まれる更新を含む、DIDメソッド仕様でサポートされるDIDの操作を規定しています。
• コントローラは、既存の検証メソッドをしばらくしてから置き換えることを意図した新しい検証メソッドを追加した場合に、ローテーションを実行します。
• すべてのDIDメソッドが検証メソッドのローテーションをサポートしているわけではありません。

失効とは、既存の検証メソッドに関連付けられている秘密の暗号材料を無効化し、デジタル署名の新しい証明を作成するための有効な形式ではなくなるようにする管理処理です。

失効は、検証メソッドの侵害に対応するために有用なメカニズムです。ローテーションの直後に失効を行うことは、メッセージの暗号化や認証に関わるものなど、コントローラが短期間の検証用に指定する検証メソッドに有用です。

検証メソッドに関連付けられている秘密が侵害されると、攻撃者は、コントローラがDIDドキュメントで表している検証関係に従って、例えば、認証のためにそれを使用できます。攻撃者による秘密の使用は、検証メソッドが登録されてから失効となる時点までの、正当なコントローラの使用と区別できない可能性があります。

検証メソッドの失効の使用を検討する際には、次の留意点が役立つ可能性があります。

• 検証メソッドの失効は、事後対応的なセキュリティ対策です。
• キーの失効をサポートすることがベスト・プラクティスと考えられています。
• コントローラは、侵害されていることが判明した検証メソッドを直ちに失効させることが期待されます。
• 検証メソッドの失効は、最新バージョンのDIDドキュメントへの変更にのみ取り入れることができます。以前のバージョンに遡って調整することはできません。
• 5.2.1 検証材料で記載しているように、検証メソッドの不在は、失効をサポートするすべてのDIDメソッドに適用される唯一の失効形式です。
• 検証メソッドが、コントローラやコントローラの代わりに動作する信頼できる関係者が排他的にアクセスすることができなくなった場合、なりすまし、盗難、詐欺などの侵害のリスクを軽減するために、直ちに失効させることが期待されます。
• 失効は、失効後に作成された、失効した検証メソッドに関連付けられている証明や署名を無効なものとして扱うべきであることを表すコントローラとして理解されることが期待されます。また、既存の証明や署名が攻撃者によって作成された可能性があるという懸念を示唆する可能性もありますが、必ずしもそうとは限りません。しかし、検証者は、自らの判断で、そのような証明や署名を受け入れるか拒否するかを選択する可能性があります。
• DIDメソッドの操作の項では、DIDドキュメントから検証メソッドを削除するために用いられる可能性のある更新と無効化など、DIDメソッド仕様がサポートするDIDの操作を規定しています。
• すべてのDIDメソッドが検証メソッドの失効をサポートしているわけではありません。
• 検証メソッドがDIDドキュメントに存在する場合でも、公開キーの失効証明書、外部の許可・拒否リストなどの追加情報を用いて、検証メソッドが失効したかどうかを判断することができます。
• 検証メソッドが公的に失効した場合、個人のオペレーティングシステム、ウイルス対策ソフトウェア、エンドポイント保護ソフトウェアなど、侵害された検証メソッドに依存するソフトウェアの日常的な操作に影響を与える可能性があります。

リカバリーとは、デバイスの紛失などによりDIDの操作を行う機能を失ったコントローラが、DIDの操作を行う機能を回復するための事後対応的なセキュリティ対策です。

DIDリカバリーの使用を検討する際には、次の留意点が役立つ可能性があります。

• 頻繁ではなくとも、事前予防的に定期的なリカバリーを行うことで、管理が失われていないことを確認することができます。
• リカバリーに関連付けられている暗号材料を他の目的で再利用しないことがベスト・プラクティスと考えられています。
• リカバリーは、通常、検証メソッドのローテーションおよび検証メソッドの失効と組み合わせて実行されます。
• リカバリーは、8.2 メソッドの操作で説明しているように、コントローラやそれに代わって動作する信頼できるサービスがDIDの操作を実行する排他的な機能を失った場合に推奨されます。
• DIDメソッド仕様では、リカバリーを容易にするために、信頼できる関係者の定足数をサポートできるようにすることを選択できます。そのための機能の一部を5.1.2 DIDコントローラで提案しています。
• すべてのDIDメソッド仕様が、他のDIDメソッドを用いて登録されたDIDからの管理を認識するとは限らず、第三者の管理を同じメソッドを用いるDIDに制限する場合があります。
• DIDメソッド仕様のアクセス制御とリカバリーには、リカバリーのための管理の第2トラックを維持することでキーの侵害を防ぐタイム・ロック機能を含めることもできます。
• 現在、すべてのDIDメソッドに適用される共通のリカバリー・メカニズムは存在しません。

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

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

この問題に対する解決策は、この仕様を参照する[DNS-DID]などの別の仕様で定義されています。そのような仕様では、次の点を慎重に検討することを強く推奨します。

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

DIDコントローラが必要とする場合、DIDまたはDID URLは、永続的な、ロケーションに依存しない資源識別子として機能することができます。この種の識別子は、URN(Uniform Resource Names)として分類されており、[RFC8141]で定義されています。DIDはURNの拡張形式であり、デジタル資源に対して、暗号によって安全で、ロケーションに依存しない識別子を提供すると同時に、検索を可能にするメタデータも提供します。DIDドキュメントとDID自体の間には間接性があるため、DIDコントローラは、DIDを調整することなく、資源の実際のロケーションを調整したり、資源を直接提供したりすることさえできます。この種のDIDは、検索された資源が、実際に識別された資源であることを明確に検証することができます。

この目的でDIDを使用しようとするDIDコントローラは、特に、次の点について、[RFC8141]のセキュリティに関する留意点に従うことをお勧めします。

• DIDコントローラは、永続性に関するコントローラの要件をサポートするDIDメソッドを選択することが期待されます。分散特性ルーブリック[DID-RUBRIC]は、実装者が最適なDIDメソッドを決定するのに役立つツールの1つです。
• DIDコントローラは、そのDIDコントローラが管理するDIDの永続性にどの程度依存できるかを要求側が判断できるように、その運用ポリシーを公開することが期待されます。このようなポリシーがない場合には、要求側は、DIDが同じDIDサブジェクトの永続的識別子であるかどうかについて、何らかの仮定を行うことは期待されません。

サイバー・セキュリティの悪用の多くは、現実と、合理的で誠実な当事者の想定との間のギャップを利用することに依存しています。DIDドキュメントの不変性により、セキュリティ上の利点が得られます。個々のDIDメソッドは、不要な動作やセマンティクスを排除するような制約を検討すべきです。DIDメソッドがロックダウン(locked down)されていればいるほど、一連の同じ機能を提供しながらも、悪意のある当事者に操作される可能性は低くなります。

例として、DIDドキュメントを1回編集すれば、ドキュメントのルートidプロパティー以外のすべてを変更できると考えてみましょう。しかし、サービスが定義された後にそのtypeを変更することは、実際に望ましいのでしょうか?あるいは、キーの値を変更することは望ましいでしょうか?それとも、オブジェクトの特定の基本的なプロパティーが変更されたときに、新しいidを要求する方がよいのでしょうか?ウェブサイトの悪意のある乗っ取りでは、サイトのホスト名の識別子はそのままにして、その下の部分を微妙に変更させるという結果を狙うことがよくあります。IPアドレスに関連付けられているASNのように、サイトの特定のプロパティーが不変であることを仕様で必須とすれば、異常の検知はより容易になり、攻撃の実行ははるかに困難で費用がかかるでしょう。

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

暗号化アルゴリズムは、暗号技術や計算能力の進歩により、機能しなくなることが知られています。実装者は、DIDドキュメントに置かれた暗号化されたデータは、暗号化されたデータを利用できるのと同じ対象者が、最終的に平文(clear text)で利用できるようになる可能性があると想定することをお勧めします。これは、DIDドキュメントが公開されている場合に特に該当します。

DIDドキュメントの全部または一部を暗号化することは、長期的にデータを保護するための適切な手段ではありません。同様に、暗号化されたデータをDIDドキュメントに置くことは、個人データを保護するための適切な手段ではありません。

上記の注意点を踏まえ、暗号化されたデータがDIDドキュメントに含まれていれば、実装者は、暗号化されたデータと関連当事者との関係を推測するために用いられる可能性のある相関付け可能な情報を関連付けないことをお勧めします。相関付け可能な情報の例には、受信側の公開キー、受信側の管理下にあることが知られているデジタル資産の識別子、受信側に関する人間が読める記述などがあります。

equivalentIdとcanonicalIdのプロパティーが、DIDメソッド自体によって生成されると仮定した場合、DIDドキュメントのidフィールドに存在する解決済みのDIDに適用されるのと同じセキュリティと正確性の保証がこれらのプロパティーにも適用されます。alsoKnownAsプロパティーは、同等性の正確なステートメントであることが保証されておらず、DIDドキュメントの解決を超える検証ステップを実行せずに依存すべきではありません。

equivalentIdとcanonicalIdのプロパティーは、同じDIDメソッドによって生成される1つのDIDのバリエーションに対する同等性の言明を表し、要求側がDIDメソッドと、適合するプロデューサとリゾルバを信頼している範囲で信頼することができます。

alsoKnownAsプロパティーでは、同じDIDメソッドによって管理されていないURIへの同等性の言明が認められており、管理しているDIDメソッドの外部で検証ステップを実行しなければ信頼できません。5.1.3 別名の追加ガイダンスを参照してください。

DIDドキュメント内の他のセキュリティ関連のプロパティーと同様に、DIDドキュメント内の同等性ステートメントに依存している関係者は、適切な検証の実行後に攻撃者によってこれらのプロパティーの値が置き換えられないように保護すべきです。検証を実行した後にメモリやディスクに保存されたDIDドキュメントへの書き込みアクセスは、DIDドキュメントを再検証しない限り、検証を逃れる可能性のある攻撃ベクトルです。

画像、ウェブページ、スキーマなど、外部の機械可読コンテンツへのリンクが含まれているDIDドキュメントは、改ざんに対して脆弱です。外部リンクは、ハッシュリンク[HASHLINK]などのソリューションを用いて完全性を保護することを強くお勧めします。完全性を保護できず、DIDドキュメントの完全性を外部リンクに依存している場合は、外部リンクを避けるべきです。

DIDドキュメント自体の完全性が影響を受ける可能性がある外部リンクの一例は、JSON-LDコンテキスト[JSON-LD11]です。侵害を防ぐために、DIDドキュメントのコンシューマは、JSON-LDコンテキストのローカルな静的コピーをキャッシュすることおよび/または外部のJSON-LDコンテキストの安全なバージョンに関連付けられていることがわかっている暗号ハッシュに対して外部コンテキストの整合性を検証することをお勧めします。

DIDは永続的であるように設計されているため、コントローラは、信頼できる1つの第三者やアドミニストレーターに依存して識別子を維持する必要はありません。理想的なケースでは、アドミニストレーターは、コントローラから管理を奪うこともできなければ、認証、承認、構成証明などの特定の目的での識別子の使用を防ぐこともできません。第三者は、コントローラの同意なしに、コントローラに代わって、エンティティーの識別子を削除したり、操作不能にしたりすることはできません。

しかし、暗号による管理の証明を可能にするすべてのDIDメソッドでは、秘密の暗号材料を転送すれば、管理を証明する手段をいつでも別の関係者に転送可能であるということに注意することが重要です。したがって、長期にわたって識別子の永続性に依存するシステムでは、識別子が実際に意図した関係者の管理下にあることを定期的に確認することが不可欠です。

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

そのため、暗号による管理の証明は、リスクの高いシナリオに必要なID保証のレベルを評価する際の1つの要素としてのみ用いられることが期待されます。DIDベースの認証は、暗号による秘密をシステム間で送信することなくその秘密の管理を決定できる機能のおかげで、ユーザ名とパスワードよりもはるかに優れた保証を提供します。しかし、それは絶対確実なわけではありません。機密性が高く、価値の高い、または命に関わる操作を伴うシナリオでは、必要に応じて追加の要素を用いることが期待されます。

様々なコントローラが利用することによる潜在的な曖昧さに加えて、一般的には、特定のDIDが、ある時点で、同じサブジェクトに関して用いられていることを保証することは不可能です。技術的には、コントローラが1つのDIDを様々なサブジェクトに再利用することは可能であり、さらに微妙なことに、サブジェクトの正確な定義が時間の経過とともに変化したり、誤解されたりする可能性があります。

例えば、個人事業主が用いる、金融取引に用いられる様々な資格証明を受信するDIDについて考えてみましょう。コントローラにとって、その識別子はその事業(business)を指していました。事業が成長するにつれ、最終的に有限責任会社として法人化されます。コントローラは、そのDIDが彼らにとって事業を指すため、同じDIDを使い続けます。しかし、国や税務署、地方自治体にとって、そのDIDは、もはや同じエンティティーを指さなくなりました。意味の微妙な変化が、クレジットの提供者やサプライヤーにとって重要かどうかは、必然的に彼らの判断に委ねられています。多くの場合、支払いが行われ、集金を実施できる限り、変化は重要ではありません。

このような潜在的な曖昧さのために、DIDは絶対的ではなく、文脈的に有効なものであると見なされます。その永続性は、それが全く同じサブジェクトを指すことや、同じコントローラの管理下にあることを意味するものではありません。むしろ、DIDが作成されたコンテキストや、その使用方法を理解し、その意味が変わる可能性を考慮し、潜在的かつ避けることのできない意味ドリフト(semantic drift)に対処するための手順とポリシーを採用する必要があります。

認証イベントのセキュリティ・コンテキストに関する追加情報は、コンプライアンス上の理由から、特に金融部門や公共部門などの規制分野で必要とされることがよくあります。この情報は、多くの場合、保証レベル(LOA;Level of Assurance)と呼ばれます。例としては、秘密の暗号材料の保護、ID証明処理、オーセンティケータのフォーム・ファクタなどがあります。

支払サービス(PSD 2)とeIDASは、このような要件をセキュリティ・コンテキストに導入しています。保証レベルのフレームワークは、eIDAS、NIST 800-63-3、ISO/IEC 29115:2013などの規則や標準によって分類・定義されています。これには、セキュリティ・コンテキストに対する要件が含まれ、その達成方法について勧告を行います。これには、FIDO2/WebAuthnが要件を満たすことができる強力なユーザ認証が含まれる場合があります。

規制シナリオの中には、特定レベルの保証の実装を必要とするものがあります。そのような状況の一部では、assertionMethodやauthenticationなどの検証関係が用いられる可能性があるため、適用されるセキュリティ・コンテキストに関する情報を表し、検証者に提供する必要があるかもしれません。この情報をDIDドキュメントのデータ・モデルでエンコードするかどうか、またどのようにエンコードするかは、この仕様の範囲外です。興味のある読者は、1)検証可能な資格証明[VC-DATA-MODEL]を用いて情報を送信できること、2)4.1 拡張性で説明しているように、DIDドキュメントのデータ・モデルを拡張してこの情報を組み込むことができること、そして、そのような拡張に対して10. プライバシーに関する留意点を適用できることを心に留めておくとよいでしょう。

DIDメソッド仕様が、対応するDIDとDIDドキュメントが公開される可能性のある、一般向けの検証可能なデータ・レジストリ用に記述されている場合、そのDIDドキュメントに個人データが含まれていないことが極めて重要です。代わりに、個人データは、1)検証可能な資格証明[VC-DATA-MODEL]か、2)DIDサブジェクトまたはDIDコントローラの管理下にあるサービス・エンドポイントなどの他の手段で送信することができます。

サービス・エンドポイントのURL内での個人データの漏洩や相関関係を防ぐために、サービス・エンドポイントにおけるURLの使用に関して十分な注意が払われることが期待されます。例えば、ユーザ名が含まれているURLをDIDドキュメントに含めるのは危険です。なぜなら、ユーザ名は、DIDサブジェクトが共有することに同意していない情報を露呈する可能性があるという点で、人間にとって意味のあるものである可能性が高いからです。この仕様で提案しているプライバシーのアーキテクチャを用いると、DIDドキュメント内の検証メソッドによって識別され、安全性が確保された通信チャネルを用いて、個人データをプライベートなピア・ツー・ピアで交換することができます。また、不変の分散型台帳には個人データが書き込まれないため、これにより、DIDサブジェクトと要求側がGDPRの忘れられる権利を実施することもできます。

あらゆる種類のグローバルに明確な識別子と同様に、DIDは相関関係に用いられる可能性があります。DIDコントローラは、個々の関係に対して一意の対のDIDを用いることで、このプライバシーのリスクを軽減することができます。実際には、個々のDIDは仮名として機能します。対のDIDは、相関関係が明示的に望まれる場合にのみ、複数の関係者と共有する必要があります。対のDIDがデフォルトである場合、DIDを公開したり、複数の関係者と共有したりする必要があるのは、DIDコントローラおよび/またはDIDサブジェクトが公的なIDと相関関係を明示的に望んでいる場合のみです。

対応するDIDドキュメント内のデータを相関付けることができれば、対のDIDの対相関関係保護機能は、簡単に破られてしまいます。例えば、複数のDIDドキュメント内で同一の検証メソッドや特注のサービス・エンドポイントを用いると、同じDIDを用いるのと同程度の相関関係情報が得られます。したがって、対のDIDに対するDIDドキュメントでは、検証メソッドが対の関係に対して一意であることを保証するなど、対で一意の情報も用いる必要があります。

対のDIDに対するDIDドキュメントでは、対で一意のサービス・エンドポイントも用いるのが自然だと思えるかもしれません。しかし、一意のエンドポイントを用いると、2つのDID間のすべてのトラフィックを一意のバケットに完全に分離でき、時差相関や類似度解析が容易になります。したがって、エンドポイントのプライバシーのためのよりよい戦略は、多くの異なるサブジェクトが管理している多数のDID間でエンドポイントを共有することかもしれません(10.5 集団プライバシーを参照)。

DIDサブジェクトがどのような種類や性質のものであるかを明示的にまたは推論によって示すために使用できるプロパティーをDIDドキュメントに追加することは、特にDIDサブジェクトが人である場合に危険です。

このようなプロパティーは、個人データ(10.1 個人情報の保護を参照)や相関付け可能なデータ(10.2 DIDの相関関係のリスクと10.3 DIDドキュメントの相関関係のリスクを参照)が、DIDドキュメントに存在するという結果になる可能性があるだけでなく、特定の操作や機能に含まれる、または除外されるような方法で、特定のDIDをグループ化するために使用できます。

型の情報をDIDドキュメントに含めると、IoTデバイスなどの人ではないエンティティーであるDIDサブジェクトであっても、個人のプライバシーに被害が生じる可能性があります。DIDコントローラに関するこのような情報が集約されると、デジタル指紋の一形態として機能する可能性があり、避けるべきです。

これらのリスクを最小限に抑えるために、DIDドキュメントのすべてのプロパティーは、DIDの使用に関連する暗号材料、エンドポイントまたは検証メソッドを表すためのものであるべきです。

あるDIDサブジェクトが、集団の中の他のものと区別できなければ、プライバシーは確保できます。別の関係者と私的な関わりを持つ行為自体が認識可能なフラグである場合には、プライバシーは大幅に低下します。

DIDとDIDメソッドは、特に合法的にそれを最も必要としている人々のために、集団プライバシーを改善するように機能する必要があります。デフォルトで匿名性と仮名性を保持する技術やヒューマン・インターフェースを選択してください。デジタル指紋を削減するためには、要求側の実装全体で共通の設定を共有し、ワイヤー・プロトコルで交渉されたオプションを最小限にとどめ、暗号化されたトランスポート層を用い、メッセージを標準的な長さにパディングしてください。

コントローラが、DIDドキュメントで少なくとも1つのサービス・エンドポイントをオプションで表現できれば、コントローラの管理性と代理性が向上します。DIDドキュメントにエンドポイントを追加するたびに、エンドポイントの記述間などの相関関係またはサービスが承認メカニズムによって保護されていないこと、あるいはその両方により、プライバシーのリスクが高まります。

DIDドキュメントは公開されていることが多く、標準化されているため、その非常に標準に基づいた性質によって効率的に保存され、インデックス化されます。このリスクは、DIDドキュメントが不変の検証可能なデータ・レジストリに公開されている場合には、さらに悪化します。DIDによって参照されるDIDドキュメントの履歴へのアクセスは、標準を用いることでより効率的になるトラフィック分析の一形態です。

1つのDIDドキュメントで複数のサービス・エンドポイントを用いることによって生じる付加的なプライバシーのリスクの程度を見積もることは困難です。プライバシーの被害は通常、意図しない結果です。DIDは、個人、世帯、クラブ、雇用者に関連付けられている可能性のあるドキュメント、サービス、スキーマなどを参照することができ、それらのサービス・エンドポイントの相関関係は、強力な監視・推論ツールとなりえます。この潜在的な被害の例は、https://example.co.ukなどの複数の共通する国レベルのトップ・レベル・ドメインを用いて、DIDサブジェクトのおおよそのロケーションをより高い確率で推論する場合に見られます。