Tim Berners-Lee氏 最近 仕様を変換する決定を発表しました これは、Webの分散型識別子を定義します（DID、分散識別子）、 推奨規格の状態で、 これにより、GoogleとMozillaによって提起された異議を無効にします。
仕様 DIDは新しいタイプのグローバル識別子を導入します そのXNUMXつだけ 個々の中央集権化された組織やサービスにリンクされていない、 ドメインレジストラや認証局など。 識別子は任意のリソースに関連付けられ、リソースの所有者によって信頼されているシステムによって生成される場合があります。
識別子認証 暗号化メカニズムに基づく所有権の証明認証を使用し、 デジタル署名のように。 この仕様では、ブロックチェーンベースの方法を含む、ID情報の分散制御と取得のためのさまざまな方法が許可されています。
新しいURIの形式は、「did：method：unique_identifier」として形成されます。 ここで、「did」は新しいURIスキームを指定し、「method」は識別子を処理するメカニズムを示し、「unique_identifier」はメソッド固有のリソース識別子です。
メソッドのあるフィールド 検証済みデータの保存に使用されるサービスの名前を指定しますは、識別子の一意性を保証し、その形式を決定し、作成されたリソースへの識別子のバインドを提供します。 IDを持つURIは、要求されたオブジェクトを記述し、所有者を確認するための公開鍵を含むメタデータを含むJSONドキュメントに変換されます。
メソッドの実装はDID標準の範囲外であり、その仕様で定義されており、別のレジストリに保持されています。
今 135の方法が提案されています さまざまなブロックチェーン、暗号化アルゴリズム、分散テクノロジー、分散型データベース、P2Pシステム、および識別メカニズムに基づいています。 また 一元化されたシステムでDIDリンクを作成することが可能ですたとえば、webメソッドを使用すると、従来のホスト名をバインドできます（たとえば、「did：web：example.com」）。
Googleの反対意見は、仕様の分離に関連しています メソッドの最終的な実装のための仕様の分散型識別子の一般的なメカニズムについては、メソッドの仕様を調査せずに主要な仕様の正確さを分析することはできません。
メソッド仕様の準備ができていないときにメイン仕様を公開すると改訂が困難になります。Googleは、メソッド標準化のプロセスのように、いくつかの最良のメソッドが標準化の準備ができるまで、一般的なDID仕様の標準化を延期することを提案しています。主な仕様を確定する必要がある場合があります。
Mozillaの異議は、仕様が移植性を適切に推進しておらず、問題をメソッド登録側に任せていることです。
レジストリでは、互換性や標準ソリューションの統合に関係なく作成されたXNUMXを超えるメソッドがすでに提案されています。 現在の形式では、既存のメソッドをニーズに合わせて調整するのではなく、タスクごとに新しいメソッドを作成することをお勧めします。
W3Cの立場は、新しい拡張可能な識別子クラスと関連する構文を定義するDID仕様の標準化により、メソッド開発とメソッド標準化に関するコンセンサスが促進されるというものです。
現在の形では、 問題を解決するための主要な仕様の適用可能性の十分な証拠があります 分散型テクノロジーを開発するコミュニティで需要があります。 提案されたメソッドの実装は、新しいURLスキームとの類推によって判断されるべきではなく、多数のメソッドの作成は、開発者のニーズの基本仕様に準拠していると見なすことができます。
特定の方法の標準化は、より困難な作業と見なされています、一般的なクラスの識別子で標準化するよりも、開発者間のコンセンサスを達成するという点で。 したがって、メソッドの標準化の前に共通の仕様を採用することは、分散型識別子を実装するコミュニティへの潜在的な害を少なくすることができるソリューションと見なされます。
最後に あなたがそれについてもっと知りたいなら、確認できます 詳細は次のリンクをご覧ください。