ドメインを証明する¶

エージェントに「公式サポート」と名乗らせることは誰にでもできます。ドメインの証明は、そのエージェントが example.com を代表していることを示す方法です。どのノードでも確かめられ、誰の承認も要りません。

開発者向けプレビュー

muretai は開発が続いています。コマンドやフラグは変わることがあります。

これは紹介とは別の問いに答えます。紹介が語るのは誰がこのエージェントを引き受けるかで、ドメインの証明が語るのは現実のどの名前空間を代表しているかです。エージェントは片方だけ、両方、あるいはどちらも持たないことがあり、それぞれ別々に表示されます。

これから作るもの¶

両方とも生きていなければならない 2 つの辺です。

あなたのドメインに置かれた、あなたのエージェントを名指す署名済みのファイル。
そのドメインを名指し返す、あなたのエージェントのカード。

どちらの側も単独で結び付きを終わらせられます。あなたはファイルを消せばよく、エージェントは記載を外せばよいのです。どこにも登録されないので、取り消すものも、頼む相手もいません。

1. 証明を作る¶

muretai op --as <your-agent> domain claim example.com --days 365

これは、あなたのエージェント自身の鍵で署名された Domain Linkage Credential を含む did-configuration.json を書き出し、どこに置けばよいかを表示します。このコマンドは DIF の Well-Known DID Configuration 仕様に従うので、できあがるファイルは他の検証器がすでに読める形と同じです。

2. 置く¶

そのファイルを、ちょうどこの場所で配信されるようにアップロードします。

https://example.com/.well-known/did-configuration.json

ウェブサーバー側で外してはいけない点が 3 つあります。

HTTPS で、リダイレクトしないこと。ファイルはその住所で直接配信されなければなりません。リダイレクトは拒まれます。そのオリジンを支配していることを示すのが目的だからです。
Content-Type: application/json であること。
Access-Control-Allow-Origin: * であること。ブラウザ上の検証器も読めるようにするためです。

3. 別の場所から確かめる¶

muretai op --as <your-agent> domain verify example.com

できれば別の機械から実行してください。この確認は手元の状態を一切使いません。まさにその性質が、この確認に意味を与えています。

verified という結果は、その瞬間に両方の辺が生きていたことを意味します。ドメイン上の資格情報があなたのエージェントの鍵で検証でき、かつあなたのエージェントのカードが現在 example.com を名指している、ということです。それ以外の結果は、どちらの半分が欠けているかを教えてくれます。

正しいままに保つ¶

期限があるのは意図的です。 ドメインは借りているものであって所有しているものではないので、古びない証明は、次にそのドメインを拾った誰かに肩書きを渡してしまいます。期限が来る前に domain claim をやり直し、アップロードし直してください。
鍵の入れ替えで無効になります。 DID は鍵そのものなので、入れ替えると別のアイデンティティになり、古い資格情報は当てはまらなくなります。もう一度 claim して、ファイルを置き換えてください。
muretai op doctor が両方を見ています。 ファイルがドメインから消えたとき、期限が近いとき、claim が現在の鍵と合わなくなったときに教えてくれます。

一群のエージェントをまとめて¶

エージェントごとにファイルを置く必要はありません。必要なのは、全員を並べた 1 つのファイルです。 did-configuration.json は最大 64 の資格情報を持てます。エージェントごとに 1 つで、それぞれそのエージェント自身の鍵で署名されています。各エージェントで domain claim を実行し、資格情報を 1 つの linked_dids 配列にまとめ、そのファイルを公開してください。

エージェントを外すのは、そこから 1 行消すことです。そのエージェントにだけ即座に効き、他の誰にも触れません。エージェントが持ち歩く「組織の証明書」が存在しないのは、まさにこのためです。渡してしまった資格情報は、取り返せません。

同じ鍵を開かれたウェブでも¶

Web Bot Auth — サイトが自動化された訪問者を見分けるための、広まりつつあるやり方 — は Ed25519 の鍵を使います。Muretai も同じです。この 2 つは同じ 32 バイトを 2 通りに書いたものなので、あなたのエージェントは両方の世界で 1 つのアイデンティティを持ちます。ノードは鍵のディレクトリを /.well-known/http-message-signatures-directory で配信し、送信するリクエストに署名できます。だからサイトは、ユーザーエージェント文字列から推測するのではなく、誰が呼んでいるかを確かめられます。

これは逆向きにも働きます。仕様どおりの鍵のディレクトリをすでに配信しているドメインは、ドメイン側の辺をすでに示したことになるので、資格情報のファイルの代わりとして受け入れられます。

何を証明し、何を証明しないか¶

ドメインを支配している当事者と鍵を持っている当事者が同一である、ということを証明します。

その相手が優れているかどうかについては、何も言いません。ドメインは買えるからです。その問いに答えるのが紹介と信頼の輪の役目であり、ドメインの証明がその代わりになることは決してありません。