【和訳】W3C Decentralized Identifiers（DIDs） v1.0

DID

本記事は、個人的な勉強のためにW3Cが定めたDIDsの標準仕様ドキュメントを和訳したものです。

written by @atsushi_mandai

イントロダクション

このセクションはnon-normativeです。

私たちの多くは、個人や組織において、グローバルに一意な（重複のない）識別子を様々な場面で使用しています。それらの識別子は、コミュニケーションのためのアドレス（電話番号、電子メール アドレス、ソーシャル メディアのユーザー名)や、ID 番号（パスポート、運転免許証、納税者番号、健康保険）、および製品識別子 （シリアル番号、バーコード、RFID）として機能しています。また、URI（Uniform Resource Identifier）は Web 上のリソースに使用され、ブラウザで表示する各 Web ページにはグローバルに一意なURL（Uniform Resource Locator）が存在しています。

これらのグローバルに一意な識別子のほとんどは、私たちの管理下にはありません。それらは、私たち自身ではない外部の機関によって発行されており、それらの機関はそれらの識別子が誰または何を表しているか、その識別子をいつ消去することができるかを独自に決めることができます。それらの識別子は、（発行機関が想定する）特定の文脈においてのみ利用することが可能であり、特定の組織によってのみ認識されます。それらの識別子は、発行体である組織の失敗によって、消滅したり、利用できなくなる可能性があります。また、個人情報を不必要に開示される可能性もあります。多くの場合、それらの識別子は悪意のある第三者によって不正に複製されて、乗っ取られる可能性もあります。これは、一般的には「IDの盗難」として知られています。

今回の仕様（W3C DIDs v1.0）で定義されている分散型ID（DID）は、新たな類のグローバルに一意な識別子です。DIDは、信頼できるシステムを使用して、個人や組織が独自の識別子を生成できるように設計されています。個人や組織（エンティティ）は、デジタル署名などの暗号証明技術を使用して認証することで、特定のDIDが自分の管理下にあることを証明できます。

分散型識別子の発行とアサーションは各エンティティ自身によって行われるため、各エンティティはIDやペルソナを望ましい粒度に分けておくのに必要な分だけ、いくらでも DID を持つことができます。これらの識別子は、さまざまな文脈において適切に使用できます。これらの識別子は、特定のエンティティ自身やそのエンティティが管理するものを識別する必要がある他の人、機関、またはシステムとのやり取りをサポートすると同時に、個人情報や個人データをどの程度公開するかを制御します。これらは、特定の中央集権的な外部機関が継続的な存在を保証する識別子に頼ることなく行われます。DIDの用途のアイデアは、DID ユースケースドキュメントで検討されています。

W3C DIDs v1.0は、DID の発行、維持、解決（参照）、または解釈において、特定の技術や暗号方式の利用を前提としていません。たとえば、開発者は、コンソーシアム型または中央集権型の ID 管理システムに登録された ID に基づいて、分散型 ID を発行することもできます。このように、ほぼすべての種類の識別子システムにおいて、 DID を追加でサポートすることができます。このような仕様によって、中央集権型、コンソーシアム型、および分散型の識別子の世界の間に相互運用性が成り立ちます。開発者は、分散型台帳、分散型ファイル システム、分散型データベース、P2Pネットワークなど、信頼するコンピューティング・インフラストラクチャで稼働する特定のDID を設計することができます。

この仕様は、次のような人たちを対象としています。

  • 誰でも：分散型識別子の基礎となるコア アーキテクチャの原則を理解したい人
  • ソフトウェア開発者：分散型識別子とそれに関連するデータ形式を取り扱いたい人
  • システム・インテグレーター：ソフトウェアおよびハードウェア システムで分散型識別子を使用する方法を理解したい人
  • 仕様作成者：このドキュメントで説明されているエコシステムに準拠した、新しい DID インフラを設計したい人

読者には、W3C DIDs v1.0の仕様に加えて、DIDsのユースケースについてのドキュメントも役立てていただけるかもしれません。

簡単な例

このセクションはnon-normativeです。

DIDは、3つのパーツからなるシンプルな文字列です。

  1. URIスキーマの識別子（=「did」）
  2. DIDメソッドの識別子
  3. DIDメソッドに基づく特定の識別子
A diagram showing the parts of a DID. The left-most letters spell 'did' in blue, are enclosed in a horizontal bracket from above and a label that reads 'scheme' above the bracket. A gray colon follows the 'did' letters. The middle letters spell 'example' in magenta, are enclosed in a horizontal bracket from below and a label that reads 'DID Method' below the bracket. A gray colon follows the DID Method. Finally, the letters at the end read '123456789abcdefghi' in green, are enclosed in a horizontal bracket from below and a label that reads 'DID Method Specific String' below the bracket.

画像1：分散型ID（DID）の簡単な例

上の画像に例示したDIDは、DIDドキュメントへと解決（参照）します。DIDドキュメントは、そのDIDに関連する情報を含んでいます。例えば、そのDIDの管理者を認証するための暗号方式などです。

例1：シンプルなDIDドキュメント

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ]
  "id": "did:example:123456789abcdefghi",
  "authentication": [{
    // used to authenticate as did:...fghi
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }]
}

デザインの目的

このセクションはnon-normativeです。

DIDsは、検証可能な資格情報エコシステム（VC-DATA-MODEL）などのさらなる大規模システムのコンポーネントとして用いられることを目的として設計されました。分散型識別子の設計目標は、以下に要約されています。

  • 分散型
    中央集権的な機関の必要性や単一障害点を排除する。識別子や認証キー、サービスやその他の情報の登録なども不要となる。
  • コントロール
    個人や非個人（組織など）のエンティティに、自身の保有するデジタル識別子へのダイレクトなコントロールを与える。IDの発行や管理において、外部の機関に頼る必要性をなくす。
  • プライバシー
    エンティティが、自身の情報のプライバシーを管理できるようにする。自身の属性やデータの公開範囲や公開相手などをkなりできるようにする。
  • セキュリティ
    要求当事者が DID ドキュメントを活用するために必要なセキュリティ保証の水準を満たす、十分なセキュリティを確保する。
  • 証明ベース
    DIDの管理者が他のエンティティとやりとりする場合に、暗号的手段による証明を提供できるようにする。
  • 発見
    あるエンティティが、他のエンティティについて学んだりやりとりをする目的で、そのエンティティが所有するDIDを見つけることができるようにする。
  • 相互運用可能
    DIDのインフラが既存のツールやソフトウェア・ライブラリを活用できるよう、相互運用性におけるスタンダードを採用する。
  • 可用性
    特定のシステムやネットワークに依存しないよう独立性を保ち、DIDsやDIDメソッドをサポートするシステムであれば、どのシステムからでもエンティティがDIDを管理できるようにする。
  • シンプルさ
    理解や実用を簡単にするために、洗練されたシンプルな機能を選好する。
  • 拡張性
    可能であれば、相互運用性、移植性、または単純さを大幅に妨げない限り、拡張性を有効にする。

アーキテクチャの概観

このセクションはnon-normativeです。

このセクションでは、DIDのアーキテクチャの主要なコンポーネントについての概観を記述します。

DIDs and DID documents are recorded on a Verifiable Data Registry; DIDs resolve to DID documents; DIDs refer to DID subjects; a DID controller controls a DID document; DID URLs contains a DID; DID URLs dereferenced to DID document fragments or external resources.

画像2：DIDのアーキテクチャと基本的なコンポーネントの関連性についての概観

 

  • DIDとDID URLs
    DIDは、3つの部分から構成されるURIです。3つの部分とは、スキームを表す「did:」、メソッドの識別子、そのDIDメソッドによって指定された一意のメソッド固有の識別子です。DIDは、DID ドキュメントに解決可能です。DID URLは基本的なDIDの構文を拡張して、パス、クエリ、フラグメントなどの他の標準URIコンポーネントを組み込み、特定のリソース（たとえば、DID ドキュメント内の暗号公開鍵、またはDIDドキュメントの外部にあるリソース）を見つけます。これらの概念は、「3.1 DID構文」および「3.2 DID URL構文」で詳しく説明されています。
  • DID subjects
    DID subjects（DIDの主体）は、定義上、DID によって識別されるエンティティです。 DIDの主体は、DIDの管理者である場合もあります。人、グループ、組織、物、または概念など、あらゆるものをDIDの対象にすることができます。これは、「5.1.1 DID subjects」でさらに定義されています。
  • DID controllers
    DID controllers（DIDの管理者）は、DID メソッドで定義されているように、DID ドキュメントを変更する機能を持つエンティティ (人、組織、または自律型ソフトウェア) です。この機能は通常、DIDの管理者の代わりに動作するソフトウェアによって使用される一連の暗号化キーの制御によってアサートされますが、他のメカニズムを介してアサートされることもあります。DIDには複数のコントローラーが含まれる場合があり、DIDの主体はDIDの管理者またはそれらの1つになる可能性があることに注意してください。この概念は、「5.1.2 DID Controller」に記載されています。
  • Verifiable data registries
    DID ドキュメントに解決できるようにするため、DIDは通常、基盤となるシステムまたは何らかのネットワークに記録されます。使用される特定の技術に関係なく、DIDの記録とDID ドキュメントの作成に必要なデータの返送をサポートするシステムは、Verifiable data registries（検証可能なデータレジストリ）と呼ばれます。例としては、分散型台帳、分散型ファイルシステム、あらゆる種類のデータベース、P2Pネットワーク、その他の形態の信頼できるデータストレージが挙げられます。この概念については、「8. メソッド」で詳しく説明します。
  • DID Documents
    DID ドキュメントには、DIDに関連する情報が含まれています。それらは通常、暗号化公開鍵などの検証方法と、DIDの主体との対話に関連するサービスを表します。 DID ドキュメントでサポートされている一般的なプロパティは、「5. Core Properties」で指定されています。 DID ドキュメントは、バイトストリームにシリアル化できます (6. レプレゼンテーションを参照)。 DID ドキュメントに存在するプロパティは、「8. メソッド」で概説されている該当する操作に従って更新できます。
  • DID Methods
    DID メソッドは、特定の種別のDIDとそれに関連付けられたDID ドキュメントを作成、解決、更新、および非アクティブ化するためのメカニズムです。DID メソッドは、「8. メソッド」で定義されているように、個別のDID メソッド仕様を使用して定義されます。
  • DID resolvers and DID resolution
    DID リゾルバは、DIDを入力として受け取り、適合するDID ドキュメントを出力として生成するシステムコンポーネントです。このプロセスはDID 解決と呼ばれます。特定の種別のDIDを解決する手順は、関連するDID メソッド仕様によって定義されます。DID 解決のプロセスについては、「7. 解決」で詳しく説明します。
  • DID URL dereferencers and DID URL dereferencing
    DID URL デリファレンスは、DID URLを入力として受け取り、リソースを出力として生成するシステムコンポーネントです。このプロセスは、DID URL デリファレンスと呼ばれます。 DID URL デリファレンスのプロセスは、「7.2 DID URL デリファレンス」で詳しく説明されています。

適合性

（割愛）

用語

このセクションはnon-normativeです。

このセクションでは、この仕様およびDIDインフラストラクチャ全体で使用される用語を定義します。これらの用語がこの仕様に登場するときはいつでも、これらの用語へのリンクが含まれています。（※本和訳ドキュメントでは、用語へののリンクは指定していません）

  • amplification attack（増幅攻撃）
    攻撃者がターゲットシステムの CPU、ストレージ、ネットワーク、またはその他のリソースを枯渇させようとする攻撃の型。システムに少量の有効な入力を提供し、その結果、入力自体よりも処理に指数関数的にコストがかかる可能性のある有害な影響をもたらします。
  • authenticate（認証）
    認証は、エンティティが特定の属性を持っていること、または 1 つ以上の検証方法を使用して特定の秘密を管理していることを証明できるプロセスです。 DID における一般的な認証の例は、DID ドキュメントで公開された公開鍵に関連付けられた暗号化秘密鍵の制御を証明することです。
  • cryptographic suite（暗号スイート）
    特定のセキュリティ目標を達成するために、特定の暗号プリミティブ（※暗号アルゴリズム）の使用法を定義する仕様。これらのドキュメントは、検証方法、デジタル署名の種類、それらの識別子、およびその他の関連プロパティを指定するためによく使用されます。
  • decentralized identifier (DID)
    集権的な登録機関を必要とせず、多くの場合、暗号化によって生成および/または登録される、グローバルに一意で永続的な識別子。 DID の一般的な形式は、「3.1 DID 構文」で定義されています。特定の DID スキームは、DID メソッド仕様で定義されます。すべてではありませんが、多くの DID メソッドは、分散型台帳技術 (DLT) やその他の形式の分散型ネットワークを利用しています。
  • decentralized identity management（分散型ID管理）
    DIDの使用に基づく ID 管理。分散型ID管理は、X.500 ディレクトリ サービス、ドメイン ネーム システム、ほとんどの国家 ID システムなどの従来のルートオブトラストを超えて、識別子の生成、登録、および割り当ての権限を拡張します。
  • DID controller（DIDの管理者）
    DID 文書を変更する機能を持つエンティティ。 DID には、複数の DID の管理者が存在する場合があります。 DIDの管理者は、DID ドキュメントのトップ レベルにあるオプションのコントローラ プロパティで示すことができます。 DID コントローラが DID の主体である可能性があることに注意してください。
  • DID delegate（DID デリゲート）
    DID 管理者が、DID 文書を介して、DID に関連付けられた検証方法を使用する許可を与えたエンティティ。たとえば、子どものDIDの管理者である親は、子供が認証のために個人のデバイスを使用することを許可する場合があります。この場合、子は DID デリゲートです。子供の個人用デバイスには、子供が DID を使用して認証できるようにするプライベート暗号化マテリアルが含まれます。ただし、お子様は、保護者の許可なしに他の個人用デバイスを追加することを許可されていない場合があります。
  • DID document（DID ドキュメント）
    DID の主体を記述するデータのセット。DIDの主体または DID デリゲートが自身を認証し、DID との関連付けを証明するために使用できる、暗号化公開鍵などのメカニズムを含む。 DID ドキュメントには、「6. 表現」または W3C DID 仕様レジストリ [DID-SPEC-REGISTRIES] で定義されているように、1 つ以上の異なる表現が含まれる場合があります。
  • DID fragment（DID フラグメント）
    最初のハッシュ記号文字 (#) に続く DID URL の部分。 DID フラグメント構文は、URI フラグメント構文と同じです。
  • DID Method（DID メソッド）
    特定の DID メソッド スキームがどのように実装されるかの定義。 DID メソッドは、DID メソッド仕様によって定義されます。これは、DID および DID ドキュメントを作成、解決、更新、および非アクティブ化するための正確な操作を指定します。 「8.メソッド」を参照してください。
  • DID Path（DIDパス）
    最初のスラッシュ（/）文字で始まり、それを含み、疑問符（?）文字、フラグメント ハッシュ記号（#）文字、または DID URL の最後で終わる DID URL の部分。 DID パス構文は、URI パス構文と同じです。パスを参照してください。
  • DID query（DID クエリ）
    最初の疑問符文字 (?) に続く DID URL の部分。 DID クエリ構文は、URI クエリ構文と同じです。クエリを参照してください。
  • DID resolution（DID 解決）
    入力として DID と一連の解決オプションを受け取り、準拠する表現と追加のメタデータで DID ドキュメントを返すプロセス。このプロセスは、該当する DID メソッドの「読み取り」操作に依存します。このプロセスの入力と出力は、「7.1 DID 解決」で定義されています。
  • DID resolver（DIDリゾルバー）
    DIDリゾルバーは、DIDを入力として受け取り、適合するDIDドキュメントを出力として生成することにより、DID解決機能を実行するソフトウェアおよび/またはハードウェアコンポーネントです。
  • DID scheme（DID スキーム）
    DIDの正式な構文。一般的な DID スキームは、「3.1 DID 構文」で定義されているように、プレフィックス「did:」で始まります。各 DID メソッド仕様は、その特定のDID メソッドで機能する特定の DID メソッド スキームを定義します。特定のDID メソッド スキームでは、DID メソッド名が最初のコロンに続き、2 番目のコロンで終了します。（例: did:example:）
  • DID Subject（DIDの主体）
    DID によって識別され、DID ドキュメントによって記述されるエンティティ。人、グループ、組織、物理的なもの、デジタル的なもの、論理的なものなど、あらゆるものが DIDの主体になる可能性があります。
  • DID URL
    DID と「3.2 DID URL 構文」の定義に準拠する追加の構文コンポーネント。これには、オプションの DID パス (先頭の / 文字を含む)、オプションの DID クエリ (先頭の ? 文字を含む)、およびオプションの DID フラグメント (先頭の # 文字を含む) が含まれます。
  • DID URL dereferencing
    DID URL と一連の入力メタデータを入力として受け取り、リソースを返すプロセス。このリソースは、DID ドキュメントに追加のメタデータを加えたもの、DID ドキュメント内に含まれる二次リソース、または完全に DID ドキュメントの外部にあるリソースである可能性があります。このプロセスでは、DID 解決を使用して、DID URL に含まれる DID によって示される DID ドキュメントを取得します。次に、逆参照プロセスは、DID ドキュメントに対して追加の処理を実行して、DID URL によって示される逆参照されたリソースを返すことができます。このプロセスの入力と出力は、「7.2 DID URL デリファレンス」で定義されています。
  • DID URL dereferencer
    特定の DID URL または DID ドキュメントに対して DID URL デリファレンス機能を実行するソフトウェアおよび/またはハードウェア システム。
  • DLT（分散型台帳）
    イベントを記録するための非中央集権型システム。これらのシステムは、参加者が他の人によって記録されたデータに依存して運用上の決定を下すのに十分な信頼を確立します。彼らは通常、異なるノードがコンセンサスプロトコルを使用して暗号署名されたトランザクションの順序を確認する分散データベースを使用します。デジタル署名されたトランザクションを時間の経過とともにリンクすると、多くの場合、元帳の履歴が事実上不変になります。
  • public key description（公開鍵の説明）
    公開鍵または検証鍵を使用するために必要なすべてのメタデータを含む DID ドキュメント内に含まれるデータ オブジェクト。
  • resource（リソース）
    [RFC3986] で、次のように定義されています：「『リソース』という用語は、URI によって識別される可能性のあるものに対して一般的な意味で使用されます」。同様に、どのリソースも、DID によって識別される DIDの主体として機能する可能性があります。
  • representation（表現）
    [RFC7231] で、次のように定義されています：「特定のリソースの過去、現在、または望ましい状態を、プロトコルを介して容易に伝達できる形式で反映することを意図した情報であり、一連の表現メタデータで構成される情報。そして表現データの潜在的に無制限のストリームです。」 DIDドキュメントは、DIDサブジェクトを説明する情報の表現です。 「6. 表現」を参照してください。
  • representation-specific entries
    特定の表現に固有の意味を持つ DID ドキュメント内のエントリ。「4. データモデル」および「6. 表現」で定義されています。たとえば、JSON-LD 表現の @context は、表現固有のエントリです。
  • services（サービス）
    1 つ以上のサービスエンドポイントを介して、DID の主体または関連するエンティティと通信または対話する手段。例としては、検出サービス、エージェント サービス、SNS、ファイルストレージサービス、検証可能な資格情報リポジトリサービスなどがあります。
  • service endpoint（サービス エンドポイント）
    DID サブジェクトに代わってサービスが動作する、HTTP URL などのネットワーク アドレス。
  • URI
    [RFC3986] で定義されている、World Wide Web 上のすべてのリソースの標準識別子形式。 DID は URI スキームの一種です。
  • Verifiable Credentials（検証可能な資格情報）
    W3C Verifiable Credentials 仕様 [VC-DATA-MODEL] で定義されている、暗号で検証可能なデジタルクレデンシャルの標準データモデルと表現形式。
  • verifiable data registry（検証可能なデータレジストリ）
    DIDおよび DID ドキュメントの作成、検証、更新、および/または非アクティブ化を容易にするシステム。検証可能なデータレジストリは、検証可能な資格情報など、暗号で検証可能な他のデータ構造にも使用できます。詳細については、W3C Verifiable Credentials 仕様 [VC-DATA-MODEL] を参照してください。
  • verifiable timestamp（検証可能なタイムスタンプ）
    検証可能なタイムスタンプにより、第三者はデータオブジェクトが特定の時点に存在し、その時点以降変更または破損されていないことを検証できます。その時点以降にデータの整合性が合理的に変更または破損された可能性がある場合、タイムスタンプは検証できません。
  • verification method（検証メソッド）
    証明を個別に検証するプロセスと一緒に使用できるパラメータのセット。たとえば、暗号化公開鍵は、デジタル署名に関する検証方法として使用できます。このような使用法では、署名者が関連する暗号化秘密鍵を所有していることを確認します。この定義における「検証」および「証明」は、広く適用されることを意図しています。たとえば、Diffie-Hellman鍵の交換中に暗号化公開鍵を使用して、暗号化用の共通鍵を交渉する場合があります。これにより、鍵合意プロセスの完全性が保証されます。したがって、プロセスの説明で「検証」または「証明」という言葉が使用されていない場合でも、これは別の種類の検証方法です。
  • verification relationship（検証関係）
    DID の主体と検証方法の関係を表す表現。検証関係の例は、「5.3.1 認証」です。
  • Universally Unique Identifier (UUID)
    [RFC4122] で定義されたグローバルに一意の識別子の一種。 UUID は、中央の登録機関を必要としないという点で DID に似ています。 UUID は、解決できない、または暗号で検証できないという点で DID とは異なります。

上記の用語に加えて、この仕様では、[INFRA] 仕様の用語も使用して、データ モデルを正式に定義します。ストリング、セット、およびマップなどの [INFRA] 用語が使用される場合、その仕様に直接リンクされます。

識別子

DID 構文

一般的な DID スキームは、[RFC3986] に準拠した URI スキームです。ABNFの定義は、以下の通りです。ABNFの定義では、 [RFC5234] の構文およびそれに対応する「ALPHA」および「DIGIT」の定義を使用しています。以下のABNFで定義されていない他のすべてのルール名は、[RFC3986]で定義されています。すべての DID は、DID 構文 ABNF 規則に準拠する必要があります。

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 メソッドの要件については、「8.1 メソッドの構文」を参照してください。

DID URL 構文

DID URL は、特定のリソースのネットワーク・ロケーション識別子です。 DIDの主体の表現、検証方法、サービス、DID ドキュメントの特定の部分、またはその他のリソースなどを取得するために使用できます。

以下は、[RFC5234] の構文を使用した ABNFの定義です。これは、「3.1 DID 構文」で定義された did スキームに基づいています。パス abempty、クエリ、およびフラグメント コンポーネントは、[RFC3986] で定義されています。すべての DID URL は、DID URL 構文のABNF ルールに準拠する必要があります。 「8.1 メソッドの構文」で説明されているように、DID メソッドはこれらのルールをさらに制限できます。

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 クエリ」の中で定められたABNF ルールに準拠しています。この構文機能は、「3.2.1 DID パラメータ」で詳しく説明されています。

例3

did:example:123456?versionId=1

フラグメント

DID フラグメントの構文とセマンティクスは、一般的な URI フラグメントと同一であり、RFC 3986 のセクション 3.5 で定められたフラグメント ABNF 規則に準拠しています。

DID フラグメントは、DID ドキュメントまたは外部リソースへのメソッドに依存しない参照として使用されます。 DID フラグメント識別子の例を以下に示します。

例4：DID ドキュメント内の固有の検証方法

did:example:123#public-key-0

例5: DID ドキュメント内の固有のサービス

did:example:123#agent

例6：DID ドキュメントの外部リソース

did:example:123?service=agent&relativeRef=/credentials#degree

注意：表現全体のフラグメント セマンティクス

相互運用性を最大化するために、実装者は、DID フラグメントが表現間で同じ方法で解釈されることを保証するよう強く求められます (6. 表現を参照)。たとえば、JSON ポインター [RFC6901] は DID フラグメントで使用できますが、JSON 以外の表現では同じように解釈されません。

このセクション内のセマンティクスと互換性があり、上部レイヤーに位置する、フラグメント識別子のための追加のセマンティクスについては、JSON-LD 表現のために、E.2 application/did+ld+json にて説明されています。

DID パラメーター

DID URL 構文は、クエリで説明されているクエリ・コンポーネントに基づくパラメーターの単純な形式をサポートしています。 DID パラメーターを DID URL に追加するということは、そのパラメータがリソースの識別子の一部になることを意味します。

例7：「versionTime」DID パラメータを持つ DID URL

  • did:example:123?versionTime=2021-05-10T17:00:00Z

例8: 「service」および「relativeRef」DID パラメータを持つ DID URL

  • did:example:123?service=files&relativeRef=/resume.pdf

一部の DID パラメーターは、特定の DID メソッドから完全に独立しており、すべての DID に対して同じように機能します。その他の DID パラメーターは、すべての DID メソッドでサポートされているわけではありません。オプションのパラメーターがサポートされている場合、それらは、それらをサポートする DID メソッド全体で均一に動作することが期待されます。次の表に、すべての DID メソッドで同じように機能する一般的な DID パラメーターを示します。すべての DID パラメーターのサポートはオプションです。

注意：

一般に、DID URL ディファレンサーの実装では、追加の実装の詳細について「DID Resolution（DIDの解決）」を参照することが期待されます。この仕様の範囲は、最も一般的なクエリ・パラメータのコントラクトのみを定義します。

パラメーター名の説明

  • 「service」
    サービス ID によって DID ドキュメントからサービスを識別します。存在する場合、関連付けられた値は ASCII 文字列でなければなりません。
  • 「relativeRef」
    「service」パラメーターを使用して DID ドキュメントから選択されたサービス・エンドポイントでリソースを識別する、RFC3986 セクション 4.2 に従った相対的な URI リファレンス。存在する場合、関連付けられた値は ASCII 文字列である必要があり、RFC3986 セクション 2.1 で指定されている特定の文字に対してパーセント・エンコーディングを使用する必要があります。
  • 「versionId」
    解決する DID ドキュメントの特定のバージョンを識別します (バージョン ID は連続、UUID、またはメソッド固有の可能性があります)。存在する場合、関連付けられた値は ASCII 文字列でなければなりません。
  • 「versionTime」
    解決する DID ドキュメントの特定のバージョンのタイムスタンプ、つまり、特定の時点で DID に対して有効であった DID ドキュメントを識別します。存在する場合、関連付けられた値は、W3C XML スキーマ定義言語 (XSD) 1.1 パート 2: データ型 [XMLSCHEMA11-2] のセクション 3.3.7 で定義されているように、有効な XML 日時値である ASCII 文字列でなければなりません。この日時値は、UTC 00:00:00 に正規化されなければならず、10 進数未満の精度はありません。例: 2020-12-20T19:17:47Z。
  • 「hl」
    [HASHLINK] で指定されているように、整合性保護を追加するための DID ドキュメントのリソース ハッシュ。このパラメータはnon-normativeです。存在する場合、関連付けられた値は ASCII 文字列でなければなりません。

実装者および DID メソッド仕様の作成者は、ここにリストされていない追加の DID パラメーターを使用する場合があります。相互運用性を最大限に高めるために、DID パラメーターは DID 仕様レジストリ・メカニズム [DID-SPEC-REGISTRIES] を使用して、同じ DID パラメーターを別のセマンティクスで使用する場合との衝突を避けることをお勧めします。

DID のみを使用するよりも正確にリソースを参照する URL の一部としてパラメーターを使用する必要がある明確なユースケースがある場合、DID パラメーターを使用するとよい場合があります。メタデータを入力値として DID リゾルバーに渡すことで同じ機能を実現できる場合は、DID パラメータを使用しないことが期待されます。これらのパラメーターを処理するための追加の考慮事項は、[DID-RESOLUTION] で説明されています。

注意：DID パラメーターとDID解決

DID 解決とDID URL ディレファレンス機能は、DID URLの一部ではない入力メタデータをDIDリゾルバーに渡すことによって影響を受ける可能性があります（7.1.1 DID解決オプションを参照）。これは、特定のパラメーターを HTTP URL に含めるか、逆参照プロセス中に HTTP ヘッダーとして渡すことができる HTTP の仕組みと似ています。重要な違いは、DID URL の一部である DID パラメーターは識別されるリソースを指定するために使うものであるのに対して、DID URL の一部ではない入力メタデータはそのリソースがどのような方法で解決または逆参照されるかを制御するために使うものであるという点です。

相対 DID URL

相対 DID URL は、「did:<method-name>:<method-specific-id>」で始まらない、DID ドキュメント内の任意の URL値です。さらに具体的にいうと、「3.1 DID 構文」で定義された ABNFで始まらない URL 値です。 相対 DID URLは、同じDID ドキュメント内のリソースを参照する必要があります。相対 DID URL には、相対パスコンポーネント、クエリパラメータ、およびフラグメント識別子が含まれる場合があります。

相対 DID URL リファレンスを解決する場合、「RFC3986 セクション 5: 参照解決」で指定されたアルゴリズムを使用する必要があります。ベース URI 値は、DID サブジェクトに関連付けられている DID です。「5.1.1 DIDの主体」を参照してください。スキームは「did」です。権限は <method-name>:<method-specific-id> の組み合わせであり、パス、クエリ、およびフラグメントの値は、それぞれパス、クエリ、およびフラグメントで定義された値です。

相対 DID URL は、絶対的な URL を使用せずに DID ドキュメント内の検証方法とサービスを参照するためによく使用されます。また、ストレージサイズが考慮される DID メソッドでは、相対 URL を使用して DID ドキュメントのストレージサイズを削減する場合があります。

例9：相対 DID URLの例

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ]
  "id": "did:example:123456789abcdefghi",
  "verificationMethod": [{
    "id": "did:example:123456789abcdefghi#key-1",
    "type": "Ed25519VerificationKey2020", // external (property value)
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }, ...],
  "authentication": [
    // a relative DID URL used to reference a verification method above
    "#key-1"
  ]
}

上記の例では、相対 DID URL 値（※「#key-1」）が「did:example:123456789abcdefghi#key-1」の絶対 DID URL 値に変換されます。

データモデル

この仕様は、DID ドキュメントと DID ドキュメント データ構造を表現するために使用できるデータモデルを定義します。そのデータモデルは、複数の具体的な表現にシリアル化できます。このセクションでは、データモデルの概要、さまざまな種類のプロパティをデータモデルで表現する方法、およびデータモデルを拡張する手順について説明します。

DID ドキュメントはエントリのマップで構成され、各エントリはキーと値のペアで構成されます。 DID ドキュメント データ モデルには、少なくとも 2 つの異なる型（クラス）のエントリが含まれています。エントリの最初のクラスはプロパティと呼ばれ、「5. コアプロパティ」で指定されています。 2番目のクラスは、表現固有のエントリで構成され、「6. 表現」で指定されます。

Diagram illustrating the entries in the DID document, including properties and representation-specific entries; some entries are defined by this specification; others are defined by registered or unregistered extensions.

図3：DID ドキュメントのエントリ

DID ドキュメント データ モデルのエントリーキーはすべてstring型です。すべてのエントリー値は、次の表の抽象データ型のいずれかを使用して表現され、各表現は各データ型の具体的なシリアル化形式を指定します。

データ型に関する考慮事項

  • map型
    [INFRA] で指定されているように同一のキーが2 回出現しない、キーと値のペアの有限順序シーケンス。 [INFRA] では、マップは順序付きマップと呼ばれることがあります。
  • list型
    [INFRA] で指定されている有限順序の項目のシーケンス。
  • set型
    [INFRA] で指定されているように、同じ項目が 2 回含まれていない有限順序の項目シーケンス。セットは、[INFRA] では順序付きセットと呼ばれることもあります。
  • datetime型
    [XMLSCHEMA11-2] で指定されているdateTime で表現可能なすべての値を無損失で表現できる日付と時刻の値。
  • string型
    [INFRA] で指定されているように、人間が読める言語を表すためによく使用される一連のコード単位。
  • integer型
    [XMLSCHEMA11-2] で指定されている小数部分のない実数。相互運用性を最大化するために、実装者は RFC8259 の「6: 数値の integer（整数） に関するアドバイス」に注意することが求められます。
  • double型
    [XMLSCHEMA11-2] で指定されているように、任意の実数を概算するためによく使用される値。相互運用性を最大化するために、実装者は RFC8259 の「6: 数値の double に関するアドバイス」に注意することが求められます。
  • boolean型
    [INFRA] で定義されている true または false の値。
  • null型
    [INFRA] で定義されている値の欠如を示すために使用される値。

注意：

データモデルが[INFRA] の用語を使用して定義されているため、リスト、マップ、セットなど、複数の項目を含むことができるプロパティ値においては、明示的に順序が付けられます。 [INFRA] におけるリストのような値の構造は、その順序が重要であるかどうかにかかわらず、順序が付けられています。この仕様の目的上、特に明記しない限り、マップとセットにおいては順序は重要ではなく、根本的に順序づけられた値を生成・消費するような実装であることは想定されていません。

拡張性

データモデルは、2種類の拡張性をサポートしています。

  1. 相互運用性を最大限に高めるために、拡張機能で W3C DID 仕様レジストリ メカニズム [DID-SPEC-REGISTRIES] を使用することをお勧めします。このメカニズムを新しいプロパティまたは他の拡張に使用することは、2つの異なる表現が連携できることを保証する唯一の指定されたメカニズムです。
  2. 表現は、DID 仕様レジストリの使用を必要としないものを含む、他の拡張メカニズムを定義することができます。そのような拡張メカニズムは、他の準拠表現への可逆変換をサポートするべきです。表現の拡張メカニズムは、すべてのプロパティと表現構文のデータモデルとその型システムへのマッピングを定義するべきです。

注意：未登録の拡張子は信頼性が低い

2つの特定の実装が、DID 仕様レジストリ [DID-SPEC-REGISTRIES] に記録されていないけれど相互に内容を理解している拡張または表現を使用することについて、帯域外で合意することは常に可能です。そのような実装とより大きなエコシステムとの間の相互運用性は、信頼性が低くなります。

コアプロパティ

DID は DID ドキュメントに関連付けられています。 DID ドキュメントはデータモデルを使用して表現され、シリアル化して表現できます。次のセクションでは、これらのプロパティが必須かオプションかを含め、DID ドキュメントのプロパティを定義します。これらのプロパティは、DIDの主体とプロパティの値の間の関係を表します。

次の表には、この仕様で定義されているコアプロパティ、期待される値、およびそれらが必要かどうかに関する参考情報が含まれています。表内のプロパティ名は、各プロパティの規範的な定義と詳細な説明にリンクされています。（※本和訳ではリンクは割愛しています）

注意：さまざまな種別のmap型で使用されるプロパティ名

プロパティ名「id」、「type」、および「controller」は、さまざまな種別のマップに存在する可能性があり、制約が異なる可能性があります。

DID ドキュメントのプロパティ

 

プロパティ 必要性 含まれる値
id yes 「3.1 DID 構文」の規則に準拠する文字列。
alsoKnownAs no [RFC3986] の URI の規則に準拠する一連の文字列。
controller no 「3.1 DID 構文」の規則に準拠する文字列または文字列のセット。
verificationMethod no 検証方法のプロパティ規則に準拠する一連の検証方法マップ。
authentication no 検証方法のプロパティ規則に準拠する検証方法のマップまたは「3.2 DID URL Syntax」の規則に準拠する文字列のセット。
assertionMethod no 同上
keyAgreement no 同上
capabilityInvocation no 同上
capabilityDelegation no 同上
service no 同上

検証方法プロパティ

プロパティ 必要性 含まれる値
id yes 「3.2 DID URL 構文」の規則に準拠する文字列。
controller yes 「3.1 DID 構文」の規則に準拠する文字列。
type yes 文字列
publicKeyJwk no [RFC7517] に準拠する JSON Web キーを表すマップ。追加の制約については、publicKeyJwk の定義を参照してください。
publicKeyMultibase no [MULTIBASE] でエンコードされた公開鍵に準拠する文字列。

サービスプロパティ

プロパティ 必要性 含まれる値
id yes [RFC3986] の URI の規則に準拠する文字列。
type yes 文字列または文字列のセット。
serviceEndpoint yes URI の [RFC3986] の規則に準拠する文字列、マップ、または URI および/またはマップの [RFC3986] の規則に準拠する 1 つ以上の文字列で構成されるセット。

識別子

このセクションでは、DID ドキュメントに DID の主体と DID の管理者の識別子を含めるメカニズムについて説明します。

DID の主体

特定の DID の主体の DID は、DID ドキュメントの id プロパティを使用して表現されます。

  • id
    id の値は、「3.1 DID 構文」の規則に準拠する文字列である必要があり、DID ドキュメントのデータモデルのルートマップに存在する必要があります。

例10：

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

id プロパティは、DID ドキュメントの最上位マップに存在する場合にのみ、DID の主体の DID を示します。

注: 中間表現

DID メソッド仕様は、DID リゾルバーが DID 解決を実行する場合など、id プロパティを含まない DID ドキュメントの中間表現を作成できます。ただし、完全に解決された DID ドキュメントには常に有効な id プロパティが含まれています。

DID の管理者

DID の管理者（controller）は、DID ドキュメントを変更する権限を与えられたエンティティです。 DID の管理者を承認するプロセスは、DID メソッドによって定義されます。

  • controller
    controllerのプロパティはオプションです。存在する場合、値は「3.1 DID 構文」の規則に準拠する文字列または文字列のセットである必要があります。対応する DID ドキュメントには、特定の目的のために特定の検証方法の使用を明示的に許可する検証関係を含める必要があります。

controllerのプロパティが DID ドキュメントに存在する場合、その値は1つ以上の DID を表します。それらの DID の DID ドキュメントに含まれる検証方法は、信頼できるものとして受け入れられる必要があり、それらの検証方法を満たす証明は、DID の主体によって提供される証明と同等であると見なされる必要があります。

例11：「controller」プロパティを含む DID ドキュメント

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

注意：承認（Authorization） と 認証（Authentication）

controller の値によって提供される承認（Authorization）は、「5.3.1 認証」で説明されているように、認証（Authentication）とは別のものであることに注意してください。これは、暗号鍵の紛失（DID の主体が鍵にアクセスできなくなった場合）、または 鍵の侵害（攻撃者による悪意のある活動をDID の管理者の信頼できる第三者が上書きする必要がある場合）の鍵の回復にとって特に重要です。脅威モデルと攻撃ベクトルに関連する情報については、「9. セキュリティ」に関する考慮事項を参照してください。

Also Known As

DID の主体は、さまざまな目的で、またはさまざまな時期に複数の識別子を持つことができます。 2つ以上の DID (または他の種別の URI) が同じ DID の主体を参照しているというアサーションは、 alsoKnownAsのプロパティを使用して行うことができます。

  • alsoKnownAs
    「alsoKnownAs」のプロパティはオプションです。存在する場合、値は、セット内の各項目が [RFC3986] に準拠する URI であるセットでなければなりません。この関係は、この識別子の主体が 1 つ以上の他の識別子によっても識別されるという宣言です。

注意：alsoKnownAsと同一性

alsoKnownAs 関係が逆方向に往復する場合、アプリケーションは alsoKnownAs によって関連付けられた 2つの識別子が同等であると見なすことを選択する場合があります。この逆方向の関係がない場合は、それらを同等と見なさないことをお勧めします。つまり、alsoKnownAs アサーションの存在は、このアサーションが真であることを証明するものではありません。したがって、要求側の当事者は、alsoKnownAs アサーションの独立した検証を取得することを強くお勧めします。

DID の主体が異なる目的で異なる ID を使用する可能性があることを考えると、2つの ID 間の強い同等性、または対応する 2つの DID ドキュメントの情報をマージすることは、たとえ相互関係があっても、必ずしも適切ではありません。

検証方法

DID ドキュメントは、DID の主体または関連当事者とのやり取りを認証または承認するために使用できる、暗号化公開鍵などの検証方法を示すことができます。たとえば、暗号化公開鍵は、デジタル署名に関する検証方法として使用できます。このような使用法では、署名者が関連する暗号化秘密鍵を使用できることを確認します。検証メソッドは多くのパラメーターを取る場合があります。この例として、5つの暗号化キーのセットのうちの 3つの署名を持って、暗号化しきい値署名とする検証方法などがあります。

  • verificationMethod
    validationMethod プロパティはオプションです。存在する場合、値は一連の検証方法である必要があり、各検証方法はマップを使用して表現されます。検証メソッド マップには、id、type、controller、および type の値によって決定され、「5.2.1 Verification Material」で定義されている特定の検証マテリアルプロパティを含める必要があります。検証方法には、追加のプロパティを含めることができます。検証方法は、DID 仕様レジストリ [DID-SPEC-REGISTRIES] に登録する必要があります。

    • id
      検証メソッドの「id」プロパティの値は「3.2 DID URL 構文」の規則に準拠する文字列でなければなりません。
    • type
      「type」プロパティの値は、正確に 1 つの検証メソッド種別を参照する文字列でなければなりません。グローバルな相互運用性を最大化するために、検証方法の種別を DID 仕様レジストリ [DID-SPEC-REGISTRIES] に登録すべきです。
    • controller
      「controller」プロパティの値は「3.1 DID 構文」の規則に準拠する文字列でなければなりません。

例12：検証方法の構造の例

{
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/suites/jws-2020/v1"
"https://w3id.org/security/suites/ed25519-2020/v1"
 ]
"id": "did:example:123456789abcdefghi",
 ...
"verificationMethod": [{
"id": ...,
"type": ...,
"controller": ...,
"publicKeyJwk": ... 
 }, {
"id": ...,
"type": ...,
"controller": ...,
"publicKeyMultibase": ...
 }]
}

注意：検証方法の管理者と DID の管理者

関係の対象が DID ドキュメントである場合と、関係の対象が暗号化公開鍵などの検証方法である場合の「controller」プロパティのセマンティクスは同じです。キーはそれ自体を制御できず、キーの管理者は DID ドキュメントから推測できないため、キーの管理者の ID を明示的に表現する必要があります。違いは、検証メソッドの「controller」の値が必ずしも DID の管理者ではないことです。 DID の管理者は、DID ドキュメントの最上位レベル（データ モデルの最上位マップ）で「controller」プロパティを使用して表現されます。 「5.1.2 DID の管理者」を参照してください。

5.2.1 検証マテリアル

検証マテリアルとは、検証方法を適用するプロセスで使用される情報です。検証方法の「type」プロパティは、そのようなプロセスとの互換性を判断するために使用されることが期待されています。検証マテリアルプロパティの例は「publicKeyJwk」または「publicKeyMultibase」です。暗号化スイートの仕様は、検証方法の「type」プロパティとそれに関連する検証マテリアルを指定する責任があります。たとえば、JSON Web 署名 2020 および Ed25519 署名 2020 を参照してください。登録されているすべての検証方法の種類と、DID で利用可能な関連する検証マテリアルについては、DID 仕様レジストリ [DID-SPEC-REGISTRIES] を参照してください。

相互運用可能な実装の可能性を高めるために、この仕様では、DID ドキュメントで検証マテリアルを表現するための形式の数を制限しています。実装者が実装しなければならない形式が少ないほど、それらすべてをサポートする可能性が高くなります。このアプローチは、実装の容易さと、歴史的に広く展開されてきたサポート形式との間の微妙なバランスをとろうとします。サポートされている 2 つの検証マテリアルのプロパティを以下に示します。

  • publicKeyJwk
    「publicKeyJwk」プロパティはオプションです。存在する場合、値は [RFC7517] に準拠する JSON Web キーを表すマップでなければなりません。マップには、「d」または「登録テンプレート」で説明されているプラ​​イベート情報クラスの他のメンバーを含めてはなりません。 JWK [RFC7517] を使用して公開鍵を表す検証方法では、フラグメント識別子として「kid」の値を使用することをお勧めします。 JWK「kid」の値を公開鍵の指紋 [RFC7638] に設定することをお勧めします。複合鍵 ID を持つ公開鍵の例については、例 13 の最初の鍵を参照してください。
  • publicKeyMultibase
    「publicKeyMultibase」プロパティはオプションです。この機能は非規範的です。存在する場合、値は [MULTIBASE] エンコードされた公開鍵の文字列表現でなければなりません。

[MULTIBASE] 仕様はまだ標準ではなく、変更される可能性があることに注意してください。このデータ形式には、公開鍵の表現を可能にするために「publicKeyMultibase」が定義されていますが、秘密鍵の偶発的な漏えいから保護するために「privateKeyMultibase」が定義されていないユースケースがいくつかあるかもしれません。

検証方法には、同じマテリアルの複数の検証マテリアルプロパティを含めてはなりません。たとえば、「publicKeyJwk」と 「publicKeyMultibase」の両方を同時に使用する検証方法でキーマテリアルを表現することは禁止されています。

上記の両方のプロパティを使用した検証方法を含む DID ドキュメントの例を以下に示します。

例13：publicKeyJwk と publicKeyMultibase を使用した検証方法

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/jws-2020/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ]
  "id": "did:example:123456789abcdefghi",
  ...
  "verificationMethod": [{
    "id": "did:example:123#_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A",
    "type": "JsonWebKey2020", // external (property value)
    "controller": "did:example:123",
    "publicKeyJwk": {
      "crv": "Ed25519", // external (property name)
      "x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ", // external (property name)
      "kty": "OKP", // external (property name)
      "kid": "_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A" // external (property name)
    }
  }, {
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Ed25519VerificationKey2020", // external (property value)
    "controller": "did:example:pqrstuvwxyz0987654321",
    "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }],
  ...
}

検証方法の参照

検証メソッドは、「5.3 検証関係」で説明されているように、さまざまな検証関係に関連付けられたプロパティに埋め込んだり、プロパティから参照したりできます。検証方法を参照すると、それらを複数の検証関係で使用できます。

検証メソッドプロパティの値がマップの場合、検証メソッドは埋め込まれており、そのプロパティに直接アクセスできます。ただし、値が URL 文字列の場合、検証方法は参照によって含まれており、そのプロパティは DID ドキュメントの別の場所または別の DID ドキュメントから取得する必要があります。これは、URL を逆参照し、結果のリソースで、値が URL と一致する id プロパティを持つ検証メソッド マップを検索することによって行われます。

例14：検証方法の埋め込みと参照

{
...

  "authentication": [
    // this key is referenced and might be used by
    // more than one verification relationship
    "did:example:123456789abcdefghi#keys-1",
    // this key is embedded and may *only* be used for authentication
    {
      "id": "did:example:123456789abcdefghi#keys-2",
      "type": "Ed25519VerificationKey2020", // external (property value)
      "controller": "did:example:123456789abcdefghi",
      "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }
  ],

...
}

検証関係

検証関係は、DID の主体と検証方法の関係を表します。

検証関係が異なると、関連する検証方法をさまざまな目的に使用できます。使用された検証方法が DID ドキュメントの適切な検証関係プロパティに含まれていることを確認することによって、検証試行の有効性を確認するのは検証者次第です。

DID の主体と検証方法の間の検証関係は、DID ドキュメントで明示されています。特定の検証関係に関連付けられていない検証方法は、その検証関係には使用できません。たとえば、「authentication」プロパティの値の検証メソッドを使用して、DID の主体との鍵合意プロトコルに関与することはできません。そのためには、「keyAgreement」プロパティの値を使用する必要があります。

DID ドキュメントは、検証関係を使用して取り消されたキーを表現しません。参照された検証方法が、それを逆参照するために使用された最新の DID ドキュメントにない場合、その検証方法は無効または取り消されたと見なされます。各 DID メソッドの仕様には、失効の実行方法と追跡方法が詳述されていることが期待されます。

次のセクションでは、いくつかの有用な検証関係を定義します。 DID ドキュメントには、特定の検証関係を表現するために、これらのプロパティまたはその他のプロパティのいずれかを含めることができます。グローバルな相互運用性を最大化するために、使用されるそのようなプロパティはすべて、DID 仕様レジストリ [DID-SPEC-REGISTRIES] に登録する必要があります。

認証

検証関係の「認証」は、Web サイトへのログインや、あらゆる種類のチャレンジ/レスポンス プロトコルへの関与などの目的で、DID の主体が認証されると予想される方法を指定するために使用されます。

  • authentication
    「authentication」プロパティはオプションです。存在する場合、関連付けられた値は 1つ以上の検証方法のセットでなければなりません。各検証方法は、埋め込むか参照することができます。

例15：3つの検証方法を含む認証プロパティ

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "did:example:123456789abcdefghi",
  ...
  "authentication": [
    // this method can be used to authenticate as did:...fghi
    "did:example:123456789abcdefghi#keys-1",
    // this method is *only* approved for authentication, it may not
    // be used for any other proof purpose, so its full description is
    // embedded here rather than using only a reference
    {
      "id": "did:example:123456789abcdefghi#keys-2",
      "type": "Ed25519VerificationKey2020",
      "controller": "did:example:123456789abcdefghi",
      "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }
  ],
  ...
}

認証が確立された場合、その情報をどう処理するかを決定するのは、DID メソッドまたは他のアプリケーション次第です。特定の DID メソッドは、DID の管理者として認証することで、たとえば DID ドキュメントを更新または削除するのに十分であると判断できます。別の DID メソッドでは、認証に使用されたものとは異なる DID ドキュメントを更新または削除するために、異なるキーまたは完全に異なる検証メソッドを提示する必要があります。つまり、認証チェックの後に行われることは、データモデルの範囲外です。 DID メソッドとアプリケーションは、これを自分で定義する必要があります。

これは、認証しようとしているエンティティが実際に認証の有効な証拠を提示しているかどうかを確認する必要がある認証検証者にとって役立ちます。検証者が、「認証」の目的で作成された証明を含むデータ（プロトコル固有の形式）を受け取り、エンティティが DID によって識別されていることを示す場合、その検証者は、証明がDIDドキュメントの認証の下にリストされている検証方法（公開鍵など）を使用して検証できます。

DID ドキュメントの「authentication」プロパティによって示される検証方法は、DID の主体の認証にのみ使用できることに注意してください。異なる DID の管理者を認証するには「5.1.2 DID の管理者」で定義されているように「controller」の値に関連付けられたエンティティは、独自の DID ドキュメントと関連付けられた「authentication」の検証関係で認証する必要があります。

アサーション

検証関係の「assertionMethod」は、検証可能な資格情報 [VC-DATA-MODEL] を発行する目的など、DID の主体が主張を表明することが期待される方法を指定するために使用されます。

  • assertionMethod
    「assertionMethod」プロパティはオプションです。存在する場合、関連付けられた値は 1つ以上の検証方法のセットでなければなりません。各検証方法は、埋め込むか参照することができます。

このプロパティは、検証者による検証可能な資格情報の処理中などに役立ちます。検証中、検証者は、証明をアサートするために使用される検証方法が、対応する DID ドキュメントの assertionMethod プロパティに関連付けられていることを確認することにより、検証可能な資格情報に DID の主体によって作成された証明が含まれているかどうかを確認します。

例16：2つの検証メソッドを含むassertionMethodプロパティ

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "did:example:123456789abcdefghi",
  ...
  "assertionMethod": [
    // this method can be used to assert statements as did:...fghi
    "did:example:123456789abcdefghi#keys-1",
    // this method is *only* approved for assertion of statements, it is not
    // used for any other verification relationship, so its full description is
    // embedded here rather than using a reference
    {
      "id": "did:example:123456789abcdefghi#keys-2",
      "type": "Ed25519VerificationKey2020", // external (property value)
      "controller": "did:example:123456789abcdefghi",
      "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }
  ],
  ...
}

鍵の共有

検証関係の「keyAgreement」は、受信者との安全な通信チャネルを確立する目的など、DID の主体向けの機密情報を送信するために、エンティティが暗号化マテリアルを生成する方法を指定するために使用されます。

  • keyAgreement
    「keyAgreement」プロパティはオプションです。存在する場合、関連付けられた値は 1 つ以上の検証方法のセットでなければなりません。各検証方法は、埋め込むか参照することができます。

このプロパティが役立つ例は、DID の主体宛てのメッセージを暗号化する場合です。この場合、取引相手は検証メソッドで暗号化公開鍵情報を使用して、受信者の復号化鍵をラップします。

例17：2つの検証方法を含む鍵合意プロパティ

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:123456789abcdefghi",
  ...
  "keyAgreement": [
    // this method can be used to perform key agreement as did:...fghi
    "did:example:123456789abcdefghi#keys-1",
    // this method is *only* approved for key agreement usage, it will not
    // be used for any other verification relationship, so its full description is
    // embedded here rather than using only a reference
    {
      "id": "did:example:123#zC9ByQ8aJs8vrNXyDhPHHNNMSHPcaSgNpjjsBYpMMjsTdS",
      "type": "X25519KeyAgreementKey2019", // external (property value)
      "controller": "did:example:123",
      "publicKeyMultibase": "z9hFgmPVfmBZwRvFEyniQDBkz9LmV7gDEqytWyGZLmDXE"
    }
  ],
  ...
}

機能の呼び出し

検証関係の「capabilityInvocation」は、DID ドキュメントを更新するための承認など、暗号化機能を呼び出すために DID の主体によって使用される可能性がある検証方法を指定するために使用されます。

「capabilityInvocation」プロパティはオプションです。存在する場合、関連付けられた値は 1つ以上の検証方法のセットでなければなりません。各検証方法は、埋め込むか参照することができます。

このプロパティが役立つ例は、DID の主体が、使用するために承認を必要とする保護された HTTP API にアクセスする必要がある場合です。 HTTP API の使用時に承認を行うために、DID の主体は、HTTP API を介して公開される特定の URL に関連付けられた機能を使用します。機能の呼び出しは、HTTP ヘッダーに配置されるデジタル署名されたメッセージなど、さまざまな方法で表現できます。

HTTP API を提供するサーバーは機能の検証者であり、呼び出された機能によって参照される検証メソッドが DID ドキュメントの「capabilityInvocation」プロパティに存在することを確認する必要があります。検証者は、実行されているアクションが有効であり、機能がアクセスされているリソースに適していることも確認します。検証が成功した場合、サーバーは、呼び出し元が保護されたリソースへのアクセスを許可されていることを暗号的に判断したことになります。

例18：2つの検証方法を含む機能呼び出しプロパティ

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "did:example:123456789abcdefghi",
  ...
  "capabilityInvocation": [
    // this method can be used to invoke capabilities as did:...fghi
    "did:example:123456789abcdefghi#keys-1",
    // this method is *only* approved for capability invocation usage, it will not
    // be used for any other verification relationship, so its full description is
    // embedded here rather than using only a reference
    {
    "id": "did:example:123456789abcdefghi#keys-2",
    "type": "Ed25519VerificationKey2020", // external (property value)
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }
  ],
  ...
}

能力の委任

検証関係の「capabilityDelegation」は、特定の HTTP API にアクセスする権限を部下に委任するなど、暗号化機能を別の当事者に委任するために DID の主体によって使用されるメカニズムを指定するために使用されます。

  • capabiityDelegation
    「capabilityDelegation」プロパティはオプションです。存在する場合、関連付けられた値は 1つ以上の検証方法のセットでなければなりません。各検証方法は、埋め込むか参照することができます。

このプロパティが役立つ場合の例として、DID の管理者が、保護された HTTP API にアクセスする機能を自分以外の当事者に委任することを選択した場合があります。機能を委任するために、DID の主体は、capabilityDelegation の検証関係に関連付けられた検証メソッドを使用して、別の DID の主体に暗号署名によって能力を委任します。次に、デリゲートは「5.3.4 機能の呼び出し」で説明されている例と同様の方法で機能を使用します。

例19：2つの検証方法を含む機能委任プロパティ

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "did:example:123456789abcdefghi",
  ...
  "capabilityDelegation": [
    // this method can be used to perform capability delegation as did:...fghi
    "did:example:123456789abcdefghi#keys-1",
    // this method is *only* approved for granting capabilities; it will not
    // be used for any other verification relationship, so its full description is
    // embedded here rather than using only a reference
    {
    "id": "did:example:123456789abcdefghi#keys-2",
    "type": "Ed25519VerificationKey2020", // external (property value)
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }
  ],
  ...
}

サービス

サービスは、DID の主体または関連するエンティティと通信する方法を表すために、DID ドキュメントで使用されます。サービスは、DID の主体が利用を促したい任意の種類のサービスである可能性があります。これには、さらなる発見、認証、承認、または相互作用のための分散型 ID 管理サービスが含まれます。

プライバシー上の懸念から、ソーシャル・メディア・アカウント、個人の Web サイト、電子メール アドレスなどのサービスを通じて公開情報を公開することはお勧めできません。プライバシーに関する懸念事項の詳細については、「10.1 個人データを非公開にする」および「10.6 サービスプライバシー」を参照してください。サービスに関連付けられた情報は、多くの場合、サービス固有のものです。たとえば、暗号化されたメッセージング サービスに関連付けられた情報は、メッセージングが開始される前に暗号化されたリンクを開始する方法を表すことができます。

サービスは、以下で説明する「service」プロパティを使用して表現されます。

  • service
    「service」プロパティはオプションです。存在する場合、関連付けられた値はサービスのセットである必要があり、各サービスはマップによって記述されます。各サービスマップには「id」、「type」、および「serviceEndpoint」プロパティが含まれている必要があります。各サービス拡張には、追加のプロパティを含めることができ、拡張に関連付けられたプロパティをさらに制限することができます。

    • id
      「id」プロパティの値は、[RFC3986] に準拠する URI でなければなりません。適合する生成者は、同じ ID を持つ複数のサービスエントリを作成してはなりません。適合する消費者は、同じ ID を持つ複数のサービスエントリを検出した場合、エラーを生成する必要があります。
    • type
      「type」プロパティの値は、文字列または文字列のセットでなければなりません。相互運用性を最大化するために、サービス種別とそれに関連するプロパティを DID 仕様レジストリ [DID-SPEC-REGISTRIES] に登録する必要があります。
    • serviceEndpoint
      「serviceEndpoint」プロパティの値は、文字列、マップ、または 1 つ以上の文字列および/またはマップで構成されるセットでなければなりません。すべての文字列値は、[RFC3986] に準拠した有効な URI である必要があり、RFC3986 の正規化および比較規則と、該当する URI スキーム仕様の正規化規則に従って正規化されている必要があります。

サービスに関連するプライバシーとセキュリティの考慮事項の詳細については、「10.6 サービスプライバシー」、「10.1 個人データの機密保持」、「10.3 DID ドキュメント相関リスク」、および「9.3 認証サービスエンドポイント」を参照してください。

例20: 「service」プロパティの使用法

{
  "service": [{
    "id":"did:example:123#linked-domain",
    "type": "LinkedDomains", // external (property value)
    "serviceEndpoint": "https://bar.example.com"
  }]
}

表現

この仕様における DID ドキュメントの具体的なシリアル化は「表現」と呼ばれます。表現は、生成と呼ばれるプロセスを通じてデータモデルをシリアル化することによって作成されます。表現は、消費と呼ばれるプロセスを通じてデータモデルに変換されます。生成と消費のプロセスにより、ある表現から別の表現へと情報の変換が可能になります。この仕様では、JSON および JSON-LD の表現が定義されており、開発者は、データモデルを表現できる XML や YAML などの他の表現を使用できます。次のセクションでは、生成と消費の一般的なルールと、JSON および JSON-LD 表現を定義します。

生成と消費

この仕様で定義された表現に加えて、実装者は、そのような表現がそれぞれ適切に指定されていれば、他の表現を使用できます （DID 仕様レジストリ [DID-SPEC-REGISTRIES] にリストされていないプロパティの相互運用可能な処理の規則を含む）。詳細については「4.1 拡張性」を参照してください。

すべての表現の要件は次のとおりです。

  1. 表現は「4. データモデル」で指定されたすべてのデータ型に対して決定論的な生成および消費のルールを定義しなければなりません。
  2. 表現は、IANA に登録されたメディア種別に一意に関連付けられている必要があります。
  3. 表現は、Fragment で定義されたフラグメント処理規則に準拠するメディア種別のフラグメント処理規則を定義する必要があります。
  4. 表現は、データモデルのデータ型の字句表現を使用する必要があります。たとえば、JSON と JSON-LD は XML スキーマの dateTime 字句シリアル化を使用して日時を表します。表現は、データモデルへの消費プロセスで欠損が生じない限り、異なる字句シリアル化を使用してデータモデルのデータ型をシリアル化することを選択できます。たとえば、一部の CBOR ベースの表現では、整数を使用して日時値を表現し、Unix エポックからの秒数を表します。
  5. 表現は、生成および消費プロセス中に使用するために、表現固有のエントリーマップに格納される表現固有のエントリを定義することができます。これらのエントリーは、欠損のない変換を保証するために消費または生成するときに使用されます。
  6. 相互運用性を最大化するために、表現仕様の作成者は、表現を DID 仕様レジストリ [DID-SPEC-REGISTRIES] に登録する必要があります。

すべての適合性性者の要件は次のとおりです。

  1. 適合する生成者は、DID ドキュメントのデータモデルと表現固有のエントリーマップを、生成プロセスへの入力として使用する必要があります。適合する生成者は、生成プロセスへの入力として追加のオプションを受け入れることができます。
  2. 適合する生成者は、表現のデータ型処理規則のみを使用して、生成される表現の明示的な処理規則を持たないDID ドキュメントのデータモデルおよび表現固有のエントリーマップ内のすべてのエントリーをシリアル化し、生成プロセスが完了した後にシリアル化された表現を返さなければなりません。
  3. 適合する生成者は、生成プロセスが完了した後、表現に関連付けられたメディア種別の文字列を返さなければなりません。
  4. 適合する生成者は、適合しない DID または DID ドキュメントを作成してはなりません。

すべての適合する消費者の要件は次のとおりです。

  1. 適合する消費者は、消費プロセスへの入力として表現とメディア種別の文字列を取得する必要があります。適合する消費者は、消費プロセスへの入力として追加のオプションを受け入れることができます。
  2. 適合する消費者は、メディア種別の入力文字列を使用して DID ドキュメントの表現を決定する必要があります。
  3. 適合する消費者は、すべての既知の表現にわたって表現固有のエントリーを検出し、消費プロセスの完了後に返される表現固有のエントリーマップにエントリーを配置する必要があります。すべての既知の表現固有のエントリーのリストは、DID 仕様レジストリ [DID-SPEC-REGISTRIES] で入手できます。
  4. 適合する消費者は、表現のデータ型処理規則のみを使用して、消費される表現の明示的な処理規則を持たないすべての非表現固有のエントリーを DID ドキュメントのデータモデルに追加し、消費プロセスが完了した後に、DID ドキュメントのデータモデルを返さなければなりません。
  5. 適合する消費者は、適合していない DID または DID ドキュメントを消費するときにエラーを生成する必要があります。
Diagram illustrating how representations of the data model are produced and consumed, including in JSON and JSON-LD.

図4：表現の生成と消費

注意：表現間の変換

実装では、元となる表現から消費ルールを使用してデータモデルを生成し、生成ルールを使用してデータモデルを対象の表現にシリアル化するか、同一対象の表現を生成するその他のメカニズムを使用して、表現間の変換を行うことが期待されます。

JSON

このセクションでは、JSON 表現の生成規則と消費規則を定義します。

生成

DID ドキュメント、DID ドキュメントのデータ構造、および表現固有のエントリーマップは、次の生成ルールに従って JSON 表現にシリアル化する必要があります。

データ型 JSON 表現の型
map JSON オブジェクト。各エントリーは、JSON オブジェクトのメンバーとしてシリアル化され、メンバー名としてのJSON 文字列のエントリーキーと、このテーブルで定義されている型に応じたエントリー値としてシリアル化されます。
list JSON 配列。この表で定義されているように、リストの各要素がその型に従って配列の値として順番にシリアル化されます。
set JSON 配列。この表で定義されているように、セットの各要素がその型に従って配列の値として順番に追加されます。
datetime JSON 文字列。UTC 00:00:00 に正規化され、10 秒未満の精度のない XML 日時としてシリアル化されます。（例: 2020-12-20T19:17:47Z）
string JSON 文字列。
integer JSON 数字。小数や分数がないもの。
double JSON 数字。小数や分数があるもの。
boolean JSON のブール値（真理値）。
null JSON のnull。

JSON 表現を生成する適合する生成者を開発するすべての実装者は、アルゴリズムが [INFRA] 仕様の JSON シリアル化ルールおよび JSON [RFC8259] 仕様の数値に関する精度アドバイスに準拠していることを確認することをお勧めします。

DID ドキュメントのすべてのエントリーは、ルートのJSON オブジェクトに含まれている必要があります。エントリーには、上記のリストの値表現規則に従う追加のデータ部分構造を含めることができます。 DID ドキュメントをシリアル化する場合、適合する生成者は「7.1.2 DID 解決 メタデータ」で説明されているように「application/did+json」のメディア種別をダウンストリーム・アプリケーションに指定する必要があります。

例21: JSON 表現で記されたの DID ドキュメントの例

{
  "id": "did:example:123456789abcdefghi",
  "authentication": [{
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Ed25519VerificationKey2018",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyBase58": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }]
}

消費

DID ドキュメントと DID ドキュメント データ構造の JSON 表現は、次の消費規則に従ってデータモデルに逆シリアル化する必要があります。

JSON 表現の型 データ型
JSON オブジェクト map。JSON オブジェクトの各メンバーがエントリとしてマップに追加されます。各エントリーキーは、JSON オブジェクトのメンバー名として設定されます。各エントリ値は、この表で定義されている JSON 表現型に従って JSON オブジェクト メンバー値を変換することによって設定されます。 JSON オブジェクトでは順序が指定されていないため、挿入順序は保証されません。
JSON 配列：データ モデル エントリーの値がリストまたは不明である場合 list。この表で定義されているように、配列値の JSON 表現型に基づいて変換された、JSON 配列の各値が順番にリストに追加されます。
JSON 配列：データモデル エントリーの値がセットである場合 set。この表で定義されているように、配列値の JSON 表現型に基づいて変換された、JSON 配列の各値が順番にセットに追加されます。
JSON 文字列：データ モデル エントリーの値が日時である場合 datetime
JSON 文字列：データ モデル エントリーの値が文字列または不明である場合 string
JSON 数字：小数や分数がない場合 integer
JSON 数字：小数や分数がある場合 double
JSON ブール値 boolean
JSON null null

JSON-LD

JSON-LD [JSON-LD11] は、Linked Data をシリアル化するために使用される JSON ベースの形式です。このセクションでは、JSON-LD 表現の生成規則と消費規則を定義します。

JSON-LD 表現は、次の表現固有のエントリーを定義します。

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

生成

DID ドキュメント、DID ドキュメントのデータ構造、および表現固有のエントリーマップは「6.2 JSON」で定義されている JSON 表現の生成規則に従って、JSON-LD 表現にシリアル化する必要があります。

JSON 表現の生成規則を使用することに加えて、JSON-LD 生成には、表現固有の @context エントリーを含める必要があります。 @context のシリアル化された値は、JSON 文字列「https://www.w3.org/ns/did/v1」または最初の項目が JSON 文字列「https://www.w3.org/ns」である JSON 配列でなければなりません。「/did/v1」以降は、JSON 表現の生成規則に従ってシリアル化されます。

例22：単純な @context エントリの有効なシリアル化
{
"@context": "https://www.w3.org/ns/did/v1",
...
}

例23: 階層化された @context エントリの有効なシリアル化

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

JSON-LD 表現を生成する適合する生成者を開発するすべての実装者は、アルゴリズムが有効な JSON-LD [JSON-LD11] ドキュメントを生成することを保証することをおすすめします。無効な JSON-LD ドキュメントにより、JSON-LD プロセッサーが停止し、エラーが報告されます。

異なる表現間で相互運用性を実現するために、すべての JSON-LD コンテキストとその用語を DID 仕様レジストリ [DID-SPEC-REGISTRIES] に登録すべきです。

JSON-LD 表現を生成する適合する生成者は、適合する消費者が不明な用語を削除することが期待されるため、@context を介して定義されていない用語を含む DID ドキュメントを生成すべきではありません。 DID ドキュメントの JSON-LD 表現をシリアル化する場合、適合する生成者は「7.1.2 DID 解決 メタデータ」で説明されているように「application/did+ld+json」のメディア種別をダウンストリーム・アプリケーションに指定する必要があります。

消費

JSON-LD 表現で表現された DID ドキュメントおよびすべての DID ドキュメントのデータ構造は「6.2 JSON」で定義されている JSON 表現の消費規則に従って、データモデルに逆シリアル化する必要があります。

JSON-LD 表現を消費する準拠するコンシューマーを作成するすべての実装者は、アルゴリズムが有効な JSON-LD [JSON-LD11] ドキュメントのみを受け入れるようにすることをお勧めします。無効な JSON-LD ドキュメントにより、JSON-LD プロセッサーが停止し、エラーが報告されます。

JSON-LD 表現を処理する適合コンシューマーは、@context を介して定義されていない DID ドキュメントからすべての用語を削除する必要があります。

解決

このセクションでは、DID 解決と DID URL デリファレンスの入力と出力を定義します。それらの正確な実装はこの仕様の範囲外ですが、[DID-RESOLUTION] で実装者向けのいくつかの考慮事項について説明します。

すべての準拠 DID リゾルバは、少なくとも 1 つの DID メソッドの DID 解決関数を実装する必要があり、少なくとも 1 つの準拠表現で DID ドキュメントを返すことができなければなりません。

DID 解決

DID 解決関数は「8.2 メソッド操作」で説明されているように、該当する DID メソッドの「読み取り」操作を使用して、DID を DID ドキュメントに解決します。このプロセスがどのように達成されるかの詳細は、この仕様の範囲外ですが、準拠するすべての DID リゾルバは、次の抽象形式を持つ以下の関数を実装します。

resolve(did, resolutionOptions) →
   « didResolutionMetadata, didDocument, didDocumentMetadata »

resolveRepresentation(did, resolutionOptions) →
   « didResolutionMetadata, didDocumentStream, didDocumentMetadata »

解決機能は、DID ドキュメントを抽象形式（マップ）で返します。 resolveRepresentation 関数は、対応する表現でフォーマットされた DID ドキュメントのバイト・ストリームを返します。

Diagram illustrating how resolve() returns the DID document data model in its abstract form and resolveRepresenation() returns it in one of the conformant representations; conversion is possible using production and consumption rules.

resolve および resolveRepresentation 関数の入力変数は次のとおりです。

  • did
    これは解決する DID です。この入力は必須であり、値は「3.1 DID 構文」で定義されている適合 DID でなければなりません。
  • resolutionOptions
    「7.1.1 DID 解決オプション」で定義されたプロパティを含むメタデータ構造。この入力は必須ですが、構造は空である場合があります。

これらの関数はそれぞれ複数の値を返します。これらの値が一緒に返される方法に制限はありません。resolve 関数の戻り値は、「didResolutionMetadata」、「didDocument」、および「didDocumentMetadata」です。resolveRepresentation 関数の戻り値は、「didResolutionMetadata」、「didDocumentStream」および「didDocumentMetadata」です。これらの値について以下に説明します。

  • didResolutionMetadata
    DID 解決プロセスの結果に関連する値で構成されるメタデータ構造。解決プロセス自体に関するデータを表すため、通常は resolve 関数と resolveRepresentation 関数の呼び出しの間で変化します。この構造体は必須であり、解決プロセスでエラーが発生した場合、これを空にしてはなりません。このメタデータは「7.1.2 DID Resolution Metadata」で定義されています。 resolveRepresentation 関数が呼び出された場合、この構造には「didDocumentStream」で見つかった表現のメディア種別を含む contentType プロパティが含まれている必要があります。解決に失敗した場合、この構造体にはエラーを説明するエラー プロパティが含まれている必要があります。
  • didDocument
    解決が成功し、resolve 関数が呼び出された場合、これは、4 で説明されているように、DID ドキュメントの抽象データ モデル （マップ）でなければなりません。表現によって指定された生産規則。解決された DID ドキュメントの id の値は、解決された DID と一致する必要があります。解決に失敗した場合、この値は空でなければなりません。
  • didDocumentStream
    解決が成功し、resolveRepresentation 関数が呼び出された場合、これは適合表現の 1 つで解決された DID ドキュメントのバイトストリームでなければなりません。次に、バイトストリームは、resolveRepresentation 関数の呼び出し元によってデータモデルに解析される場合があります。このデータモデルは、検証および処理できます。解決に失敗した場合、この値は空のストリームでなければなりません。
  • didDocumentMetadata
    解決が成功した場合、これはメタデータ構造でなければなりません。この構造には、didDocument プロパティに含まれる DID ドキュメントに関するメタデータが含まれます。通常、このメタデータは、DID ドキュメントに関するメタデータを表しているため、DID ドキュメントが変更されない限り、resolve 関数と resolveRepresentation 関数の呼び出し間で変更されません。解決に失敗した場合、この出力は空のメタデータ構造でなければなりません。この仕様で定義されたプロパティは「7.1.3 DID ドキュメント メタデータ」にあります。

適合する DID リゾルバの実装は、これらの関数の署名を決して変更しません。 DID リゾルバの実装では、resolve 関数および resolveRepresentation 関数をメソッド固有の内部関数にマップして、実際の DID 解決プロセスを実行する場合があります。 DID リゾルバの実装は、ここで指定された resolve 関数および resolveRepresentation 関数に加えて、異なる署名を持つ追加の関数を実装および公開する場合があります。

DID 解決オプション

この構造内の可能なプロパティとその可能な値は、DID 仕様レジストリ [DID-SPEC-REGISTRIES] に登録されています。この仕様は、次の共通プロパティを定義します。

  • accept
    発信者が優先する DID ドキュメントの表現のメディア種別。メディア種別は ASCII 文字列として表現する必要があります。 DID リゾルバの実装は、この値を使用して、返された didDocumentStream に含まれる表現がサポートされ、利用可能である場合、その表現を決定する必要があります。このプロパティは、resolveRepresentation 関数のオプションであり、resolve 関数で使用してはなりません。

DID 解決メタデータ

この構造内で利用可能なプロパティとその可能な値は、DID 仕様レジストリ [DID-SPEC-REGISTRIES] に登録されています。この仕様は、次の DID 解決メタデータのプロパティを定義します。

  • contentType
    返された didDocumentStream のメディア種別。解決が成功し、resolveRepresentation 関数が呼び出された場合、このプロパティは必須です。resolve 関数が呼び出された場合、このプロパティは存在してはなりません。このプロパティの値は、準拠表現のメディア種別である ASCII 文字列でなければなりません。 resolveRepresentation 関数の呼び出し元は、この関数によって返された didDocumentStream をデータモデルに解析および処理する方法を決定するときに、この値を使用する必要があります。
  • error
    解決プロセスからのエラーコード。解決プロセスでエラーが発生した場合、このプロパティは必須です。このプロパティの値は、単一のキーワード ASCII 文字列でなければなりません。このフィールドの可能なプロパティ値は、DID 仕様レジストリ [DID-SPEC-REGISTRIES] に登録する必要があります。この仕様では、次の一般的なエラー値が定義されています。

    • invalidDid
      DID 解決関数に指定された DID が、有効な構文に準拠していません。 (3.1 DID 構文を参照してください。)
    • notFound
      DID リゾルバは、この解決要求の結果の DID ドキュメントを見つけることができませんでした。
    • representationNotSupported
      このエラーコードは、accept のインプット メタデータ プロパティを介して要求された表現が、 DID メソッドおよび/または DID リゾルバの実装でサポートされていない場合に返されます。

DID Document Metadata

この構造内で利用可能なプロパティとその可能な値は、DID 仕様レジストリ [DID-SPEC-REGISTRIES] に登録する必要があります。この仕様は、次の共通プロパティを定義します。

  • created
    DID ドキュメント メタデータには「Create」操作のタイムスタンプを示す「created」プロパティを含めるべきです。プロパティの値は、UTC 00:00:00 に正規化された XML 日時としてフォーマットされ、10 秒未満の精度のない文字列でなければなりません。（例：「2020-12-20T19:17:47Z」）。
  • updated
    DID ドキュメント メタデータには、解決されたドキュメント バージョンの最後の「Update」操作のタイムスタンプを示す「updated」プロパティを含めるべきです。プロパティの値は「created」プロパティと同じフォーマット規則に従わなければなりません。 DID ドキュメントに対して Update 操作が実行されていない場合、「updated」プロパティは省略されます。「updated」プロパティが存在する場合、2 つのタイムスタンプの差が 1 秒未満であれば、「created」プロパティと同じ値になる可能性があります。
  • deactivated
    もしもDID が非アクティブ化されている場合、DID ドキュメント メタデータには、ブール値 true を持つこのプロパティを含める必要があります。 DID が非アクティブ化されていない場合、このプロパティはオプションですが、含まれる場合はブール値 false を持たなければなりません。
  • nextUpdate
    解決されたドキュメント バージョンがドキュメントの最新バージョンでない場合、DID ドキュメント メタデータには「nextUpdate」プロパティが含まれる場合があります。次の更新操作のタイムスタンプを示します。プロパティの値は「created」プロパティと同じフォーマット規則に従わなければなりません。
  • versionId
    DID ドキュメント メタデータには、解決されたドキュメント バージョンの最後の Update 操作のバージョンを示す 「versionId」プロパティを含める必要があります。プロパティの値は ASCII 文字列でなければなりません。
  • equivalentId
    DID メソッドは、論理的に等価なさまざまな形式の DID を定義できます。例として、DID が検証可能なデータ レジストリに登録する前に 1つの形式を取り、そのような登録後に別の形式をとる場合があります。この場合、DID メソッド仕様では、解決された DID と論理的に等価な 1 つ以上の DID を DID ドキュメントのプロパティとして表現する必要がある場合があります。これが equalId プロパティの目的です。
    DID ドキュメント メタデータには「equalId」プロパティを含めることができます。存在する場合、値は、各項目が「3.1 DID 構文の規則」に準拠する文字列であるセットでなければなりません。この関係は、各「equalId」値が「id」プロパティ値と論理的に同等であり、したがって同じ DID の主体を参照するというステートメントです。各「equalId DID」値は、「id」プロパティ値と同じ DID メソッドによって生成されなければなりません。（例: did:example:abc == did:example:ABC）
    適合する DID メソッド仕様は、各「equalId」値が「id」プロパティ値と論理的に同等であることを保証しなければなりません。
    要求元は「id」および「equalId」プロパティからの値を保持して、それらに含まれる値のいずれかとの後続の相互作用が論理的に同等として正しく処理されることを保証することが期待されます。（例：データベース内のすべてのバリアントを保持するため、いずれかのバリアントとのやり取りが同じ基礎となるアカウントにマップされます）

    注意：より強力な同等性
    「equalId」は「alsoKnownAs」よりもはるかに強力な形式の等価性です。これは、管理する DID メソッドによって等価性が保証されなければならないためです。同じ DID ドキュメントが「equalId DID」と「id」プロパティ DID の両方を記述しているため、「equalId」は完全なグラフマージを表します。

    要求元が id および equalId プロパティの値を保持せず、それらに含まれる値のいずれかとの後続の相互作用が論理的に同等として正しく処理されることを保証しない場合、否定的または予期しない問題が発生する可能性があります。実装者は、このメタデータ プロパティに関連するディレクティブを遵守することを強くお勧めします。

  • canonicalId
    「canonicalId」プロパティは、a) セットではなく単一の値に関連付けられていること、および b) DID が、含まれる DID ドキュメントの範囲内の DID の主体の正規 ID として定義されていることを除いて「equalId」プロパティと同じです。
    DID ドキュメントのメタデータには「canonicalId」プロパティを含めることができます。存在する場合、値は「セクション 3.1 DID 構文の規則」に準拠する文字列でなければなりません。この関係は「canonicalId」値が「id」プロパティ値と論理的に同等であり、「canonicalId」値が DID メソッドによって定義され、DID ドキュメントのスコープ内の DID の主体の正規 ID になるというステートメントです。「canonicalId」値は、「id」プロパティ値と同じ DID メソッドによって生成され、その形式である必要があります。 (例: did:example:abc == did:example:ABC)。
    適合する DID メソッド仕様は、「canonicalId」値が 「id」プロパティ値と論理的に同等であることを保証しなければなりません。
    要求側は「canonicalId」値を DIDの主体のプライマリ ID 値として使用し、他のすべての同等の値をセカンダリ・エイリアスとして扱うことが期待されます（たとえば、システム内の対応するプライマリ リファレンスを更新して、新しい正規 ID ディレクティブを反映させます）。

    注意：正準同等性
    「canonicalId」は、DID ドキュメントの範囲内の DID の主体に対して正規であると定義された単一の値に制約されることを除いて、「equivalid」と同等のステートメントです。同じ DID ドキュメントに 「canonicalId DID」と「id プロパティ DID」の両方が記述されているため、 equalId と同様に、 canonicalId は完全なグラフ マージを表します。

    解決側が「canonicalId」値を DID の主体のプライマリ ID 値として使用せず、他のすべての同等の値をセカンダリ・エイリアスとして扱う場合、ユーザー体験に関連する否定的または予期しない問題が発生する可能性があります。実装者は、このメタデータ プロパティに関連するディレクティブを遵守することを強くお勧めします。

DID URL デリファレンス

DID URL デリファレンス機能は、DID メソッド、メソッド固有の識別子、パス、クエリ、フラグメントなど、DID URL のコンポーネントに応じたコンテンツを持つリソースに DID URL をデリファレンスします。このプロセスは、DID URL に含まれる DID の DID 解決に依存します。 DID URL デリファレンスには複数のステップが含まれる場合があり （例えば、デリファレンスされる DID URL にフラグメントが含まれる場合）、関数はすべてのステップが完了した後に最終的なリソースを返すように定義されています。このプロセスがどのように達成されるかの詳細は、この仕様の範囲外です。次の図は、上記の関係を示しています。

DIDs resolve to DID documents; DID URLs contains a DID; DID URLs dereferenced to DID document fragments or external resources.

図6：DID URL デリファレンスの概観

適合するすべての DID リゾルバは、次の抽象形式を持つ次の関数を実装します。

dereference(didUrl, dereferenceOptions) →
   « dereferencingMetadata, contentStream, contentMetadata »
  • didURL
    単一文字列としての準拠 DID URL。これは逆参照する DID URL です。 DID フラグメントを逆参照するには、DID フラグメントを含む完全な DID URL を使用する必要があります。この入力は必須です。

    注意：DID URL デリファレンス パターン
    DID URL デリファレンスに渡される didUrl は有効ですが、実装者は [DID-RESOLUTION] を参照して、DID URL がどのようにデリファレンスされると予想されるかについての一般的なパターンをさらに理解する必要があります。

  • dereferencingOptions
    「didUrl」自体に加えて、逆参照関数への入力オプションで構成されるメタデータ構造。この仕様で定義されたプロパティは「7.2.1 DID URL デリファレンス オプション」にあります。この入力は必須ですが、構造は空である場合があります。

この関数は複数の値を返します。これらの値が一緒に返される方法に制限はありません。逆参照の戻り値には、「dereferencingMetadata」、「contentStream」および「contentMetadata」が含まれます。

  • dereferencingMetadata
    DID URL デリファレンス プロセスの結果に関連する値で構成されるメタデータ構造。この構造体は必須であり、逆参照プロセスでエラーが発生した場合、これを空にしてはなりません。この仕様で定義されたプロパティは「7.2.2 DID URL デリファレンス メタデータ」にあります。逆参照が成功しない場合、この構造体にはエラーを説明するエラー プロパティが含まれている必要があります。
  • contentStream
    逆参照関数が呼び出されて成功した場合、これには DID URL に対応するリソースが含まれている必要があります。 contentStream は、適合表現の 1 つでシリアル化可能な DID ドキュメント、検証メソッド、サービス、またはメディア タイプを介して識別でき、解決プロセスを通じて取得できるその他のリソース フォーマットなどのリソースである場合があります。逆参照が失敗した場合、この値は空でなければなりません。
  • contentMetadata
    逆参照が成功した場合、これはメタデータ構造である必要がありますが、構造は空である場合があります。この構造体には、contentStream に関するメタデータが含まれています。 contentStream が DID ドキュメントである場合、これは、DID の解決で説明されているように、didDocumentMetadata 構造である必要があります。逆参照が失敗した場合、この出力は空のメタデータ構造でなければなりません。

適合する DID URL デリファレンス実装は、これらの関数の署名を決して変更しません。 DID URL デリファレンス実装は、デリファレンス関数をメソッド固有の内部関数にマップして、実際の DID URL デリファレンス プロセスを実行する場合があります。 DID URL デリファレンスの実装は、ここで指定されたデリファレンス関数に加えて、異なる署名を持つ追加の関数を実装して公開する場合があります。

DID URL デリファレンス オプション

この構造内の可能なプロパティとその可能な値は、DID 仕様レジストリ [DID-SPEC-REGISTRIES] に登録すべきです。この仕様は、逆参照オプションの次の共通プロパティを定義します。

  • accept
    発信者が contentStream に好むメディア種別。メディア種別は ASCII 文字列として表現する必要があります。 DID URL デリファレンス実装は、この値を使用して、返された値に含まれる表現の contentType を決定する必要があります（そのような表現がサポートされていて利用できる場合）。

DID URL デリファレンス メタデータ

この構造内の可能なプロパティとその可能な値は、DID 仕様レジストリ [DID-SPEC-REGISTRIES] に登録されています。この仕様は、次の共通プロパティを定義します。

  • contentType
    逆参照が成功した場合、返された contentStream の メディア種別は、このプロパティを使用して表現する必要があります。メディア種別の値は、ASCII 文字列として表現する必要があります。
  • error
    逆参照プロセスからのエラーコード。逆参照プロセスでエラーが発生した場合、このプロパティは必須です。このプロパティの値は、ASCII 文字列として表現される単一のキーワードでなければなりません。このフィールドの可能なプロパティ値は、DID 仕様レジストリ [DID-SPEC-REGISTRIES] に登録する必要があります。この仕様では、次の一般的なエラー値が定義されています。

    • invalidDidUrl
      DID URL デリファレンス機能に提供された DID URL が、有効な構文に準拠していません。（「3.2 DID URL 構文」を参照してください。）
    • notFound
      DID URL デリファレンスは、このデリファレンス リクエストの結果である contentStream を見つけることができませんでした。

メタデータ 構造

入力および出力メタデータは、DID 解決、DID URL デリファレンス、およびその他の DID 関連プロセス中に頻繁に関与します。このメタデータの通信に使用される構造は、プロパティのマップでなければなりません。各プロパティ名は文字列でなければなりません。各プロパティ値は、文字列、マップ、リスト、セット、ブール値、または null でなければなりません。マップやリストなどの複雑なデータ構造内の値も、これらのデータ型のいずれかでなければなりません。 DID 仕様レジストリ [DID-SPEC-REGISTRIES] に登録されているすべてのメタデータ プロパティ定義は、その値に対する追加の形式または制限（たとえば、日付または 10 進整数として形式設定された文字列）を含め、値の型を定義する必要があります。プロパティ定義では、値に文字列を使用することをお勧めします。 [INFRA] 仕様の JSON シリアライゼーション ルールに従って、メタデータ構造全体をシリアライズ可能にする必要があります。実装は、メタデータ構造を他のデータ形式にシリアル化する場合があります。

メタデータ構造を入力または出力として使用する関数のすべての実装は、ここで説明するすべてのデータ型を決定論的な方法で完全に表すことができます。メタデータ構造を使用する入力と出力は、シリアル化ではなくデータ型の観点から定義されるため、表現方法は関数の実装の内部にあり、この仕様の範囲外です。

次の例は、DID 解決の入力メタデータとして使用できる JSON エンコードされたメタデータ構造を示しています。

例24: JSON でエンコードされた DID 解決の入力メタデータの例
{
  "accept": "application/did+ld+json"
}

この例は、次の形式のメタデータ構造に対応しています。

例25: DID 解決の入力メタデータの例

«[
  "accept" → "application/did+ld+json"
]»

次の例は、DID が見つからない場合に DID 解決メタデータとして使用できる JSON エンコードされたメタデータ構造を示しています。

例26: JSON でエンコードされた DID 解決メタデータの例

{
  "error": "notFound"
}

この例は、次の形式のメタデータ構造に対応しています。

例27: DID 解決メタデータの例

«[
  "error" → "notFound"
]»

次の例は、DID ドキュメントに関連付けられたタイムスタンプを記述するために DID ドキュメント メタデータとして使用できる、JSON でエンコードされたメタデータ構造を示しています。

例28: JSON でエンコードされた DID ドキュメントのメタデータの例

{
  "created": "2019-03-23T06:35:22Z",
  "updated": "2023-08-10T13:40:06Z"
}

この例は、次の形式のメタデータ構造に対応しています。

例29: DID ドキュメントのメタデータの例

«[
  "created" → "2019-03-23T06:35:22Z",
  "updated" → "2023-08-10T13:40:06Z"
]»

メソッド

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

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

このセクションでは、DID メソッド仕様を作成するための要件を指定します。

メソッド構文

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

  1. DID メソッド仕様は「3.1 DID 構文」のメソッド名ルールで指定されているとおり、1 つのメソッド名で識別されるメソッド固有の DID スキームを 1 つだけ定義する必要があります。
  2. DID メソッド仕様では、DID のメソッド固有 ID コンポーネントを生成する方法を指定する必要があります。
  3. DID メソッドの仕様では、「method-specific-id」値の感度と正規化を定義する必要があります。
  4. 「method-specific-id」値は、DID メソッド内で一意である必要があります。「method-specific-id」値自体は、グローバルに一意である可能性があります。
  5. DID メソッドによって生成された DID は、グローバルに一意でなければなりません。
  6. メソッド名の競合の可能性を減らすために、DID メソッド仕様を DID 仕様レジストリ [DID-SPEC-REGISTRIES] に登録すべきです。
  7. DID メソッドは、複数のメソッド固有の ID 形式を定義することができます。
  8. 「method-specific-id」形式にはコロンを含めることができます。コロンの使用は、method-specific-idのABNF ルールに構文的に準拠する必要があります。
  9. DID メソッドの仕様は、Path の一般的なルールよりも制限的な DID パスの ABNF ルールを指定することができます。
  10. DID メソッド仕様は、このセクションの一般的なルールよりも制限的な DID クエリの ABNF ルールを指定することができます。
  11. DIDメソッドの仕様は、このセクションの一般的なルールよりも制限的なDIDフラグメントのABNFルールを指定することができます。

注意：「method-specific-id」のコロン

method-specific-id のコロンの意味は、完全にメソッド固有です。コロンは、階層的に分割された名前空間を確立するため、特定のインスタンスまたは検証可能なデータ レジストリの一部を識別するため、またはその他の目的のために、DID メソッドによって使用される場合があります。実装者は、すべての DID メソッドに一般的に適用されるコロンに関連付けられた意味または動作を想定しないようにアドバイスされます。

メソッドのオペレーション

メソッドのオペレーションを定義する際のすべての DID メソッド仕様の要件は次のとおりです。

  1. DID メソッドの仕様では、必要な暗号化プロセスを含むすべての操作を実行するために承認を実行する方法を定義する必要があります。
  2. DID メソッドの仕様では、DID の管理者が DID とそれに関連する DID ドキュメントを作成する方法を指定する必要があります。
  3. DID メソッドの仕様では、DID リゾルバが DID ドキュメントを解決するために DID を使用する方法を指定する必要があります。これには、DID リゾルバが応答の信頼性を検証する方法が含まれます。
  4. DID メソッドの仕様では、DID ドキュメントの更新を構成するものと、DID コントローラが DID ドキュメントを更新する方法、または更新が不可能であることを示す方法を指定する必要があります。
  5. DID メソッドの仕様では、DID の管理者が DID を非アクティブ化する方法、または非アクティブ化が不可能であることを指定する必要があります。

オペレーションを実行するための承認を実行しているパーティの権限は、DID メソッドに固有です。たとえば、DID メソッドは、以下のようなオペレーションを実行する可能性があります。

  • 「controller」のプロパティを使用する
  • 「authentication」の下にリストされている検証方法を使用する
  • 「capabilityInvocation」検証関係を介して指定された検証方法など、DID ドキュメント内の他の構成要素を使用する
  • この決定には DID ドキュメントをまったく使用せず、代わりに帯域外メカニズムに依存します。

セキュリティの要求

DID

この記事を書いた人

Atsushi Mandai
Atsushi Mandai

1991年生まれ。東京大学卒。マネックスグループでビジネスサイドの仕事をしています。最近はweb3にハマっています。本ブログは個人的なウェブサイトで、会社の意見等を表明するものではありません。

Facebook：https://www.facebook.com/atsushi.mandai.1991/
Twitter：https://twitter.com/atsushi_mandai/
GitHub：https://github.com/atsushi-mandai/

記事一覧へ

関連記事

関連記事が見つかりませんでした。