Resolver
IPアドレス
コンピュータさん向けのネットワーク上の住所
https://scrapbox.io/files/646ec59bed861f001b7e47f8.png
ドメイン名
IPアドレスに付けた人間様向けの名前
https://scrapbox.io/files/646ec5b586845a001b2932a6.png
DNS
IPアドレスとドメイン名の紐付けをしまっせシステム
パソコンさんはIPアドレスしか分かりません。
ドメイン名を見せられても「う~ん、どこの住所だろう」と困ってしまいます。一方、人間様はIPアドレスがピンときません。
例えば「198.51.100.1」と「198.51.100.10」と「198.51.100.11」の違いなんて、パッと見で分かりませんよね。
うっかりミスも増えそうです。
「コンピュータさんはコンピュータさんが分かりやすい形式の住所(IPアドレス)、人間様は人間様が分かりやすい形式の住所(ドメイン名)を扱えるような仕組みがあります。」
他の人間様とコンピューターさんを通してコミュニケーションする時に、人間様(僕)とコンピューターさんのコミュニケーションを円滑にするためってイメージかYudai.icon
事前にIPアドレスとドメイン名を対応付けておいて、必要に応じて変換するのです。
実際にはDNSサーバさんに問い合わせるのを仕事にしているプログラムがパソコンさんの中にいて、そのプログラムが問い合わせを行います。
https://scrapbox.io/files/646ec7198cf49b001b2536aa.png
結構分かったYudai.icon
この場合ってDID文字列(多分僕たちが見てわかる文字列)と何を紐づけているのだろうか
公開鍵?それとも他?
Yudai.icon
DID Resolverについて質問です。
私は根本的なResolverが分からず今学びました。
そこで思ったのがDID Resolverの場合、何と何が紐づいているのでしょうか?例えばDNSだと、ドメイン名(人間)とIPアドレス(コンピューター)が紐づいていると思います。
自分の考えは人間側はDID文字列(did:ion:....)ですが、コンピューター側?が分かりません
chatGPT.icon
DID (分散型識別子、Decentralized Identifier) Resolverは、DIDと呼ばれる特定の文字列をDIDドキュメントというデータ構造に解決する役割を果たします。DIDはブロックチェーンやその他の分散型台帳技術に基づいています。DIDドキュメントは、特定のDIDに関連付けられた公開鍵、認証エンドポイント、その他の関連情報を提供します。
したがって、DID Resolverは、DID(人間が読むことができる識別子)とDIDドキュメント(DIDに関連する機械が読むことができる詳細情報)の間のマッピングを提供します。
DNSとの類似性について言えば、DNSがドメイン名をIPアドレスに解決するのと同じように、DID ResolverはDIDをDIDドキュメントに解決します。ただし、DIDドキュメントはIPアドレスよりもはるかに多くの情報を含むことが可能で、それによって個々のDIDがどのように認証され、どのように制御されるかを詳細に記述します。
DID documentとのマッピングなんだYudai.icon
chatGPT.icon
DIDとDIDドキュメント(公開鍵、認証エンドポイントなどを含む)の関連付けは、認証プロセスの一部を形成します。 具体的には、あるエンティティ(個人、組織、またはデバイス)がDIDを持つと、それはDIDドキュメントを通じて公開鍵とエンドポイント情報を公開します。このDIDドキュメントはブロックチェーンや分散型台帳上に記録されており、エンティティはプライベートキーを使って自身がそのDIDの所有者であることを証明することができます。
DID(Decentralized Identifier)を実装する場合、DIDドキュメントは通常、ブロックチェーンや他の分散型台帳(Verifiable Data Registry, VDR)に保存されます。これにより、DIDドキュメントは改ざん防止と永続性を確保します。
DID ResolverはDIDを入力として受け取り、関連するDIDドキュメントを取得するために分散型台帳(例えば、あなたが実装したいブロックチェーン)に対してクエリを実行します。その後、関連するDIDドキュメントが返されます。
そのため、DIDシステムを実装する際には、そのDIDをクエリするための特定のルールやプロトコル(つまり、Resolverがどのようにしてブロックチェーンからデータを取得するか)を定義する必要があります。これは、DIDメソッドと呼ばれるもので、DIDの特定のスキームまたはフレームワーク(例えば、did:example:1234)に依存します。
当たり前っちゃ当たり前だけど技術的な部分と繋がったYudai.icon
DID(人間様が読める識別子)でDID documentがDID Resolverによって紐づけられているからこそ、検証可能なんだ
一番初めにやらないといけないことは人間様が読み取れる文字列をどのように生成するかの工程
どう一意にするのか、DID documentはどのような工程(認証)で発行されるのか