要約

  • AIPの第1の検証は、応答に提示された鍵の所持を示す。第2の検証は、登録情報または解決したDID文書を使い、その鍵が agentDid に拘束されているかを確かめる。
  • 03版は、事業者スコープの did:web とエコシステム・スコープの did:opena2a を異なる管理面に置く。自己申告の種類や目的は認可の代わりにならない。

監査担当者が最初に気付いたのは、署名の失敗ではなかった。署名は正しかった。nonceは未使用で、時刻も有効期間内、応答に含まれる公開鍵で計算はきれいに一致した。

問題は、その鍵を当該エージェントに割り当てた記録がどこにもなかったことだ。

暗号は約束を破っていない。「この応答者は、この公開鍵に対応する秘密鍵を持つ」と正確に答えた。しかし「この鍵は、チャレンジに書かれた agentDid の正当な鍵か」という問いは、署名の外に残った。OpenA2A Agent Identity Protocol (AIP) 03版は、この二つの問いを混ぜない。

03版は2026年10月2日付の個人提出Internet-Draftで、2027年4月3日に失効する。RFCでもIETFワーキンググループ文書でもなく、IETF合意や実運用を示すものでもない。本文はStandards Trackを意図するが、それは著者の希望する位置付けであって、取得済みの地位ではない。

署名対象は応答全体ではない

検証者は、32バイトのランダムなchallenge、申告された agentDid、16バイトのnonce、issuedAt、expiresAt、issuerDid を含む短命のチャレンジを発行する。時刻はRFC 3339のUTC表現で、有効窓は5分だ。

署名入力は次の連結文字列である。

<challenge>|<agentDid>|<nonce>|<issuedAt>|<expiresAt>

応答にはさらに publicKey、keyId、signedAt、algorithm が付くが、これら四つは署名文字列に含まれない。提示鍵で署名を検査すること自体は合理的だ。ただし、その鍵が自分自身の正当性を証明したと扱えば循環する。鍵ペアを作れる者なら誰でも、自分の鍵に対して正しい署名を作れるからだ。

ログに残すべき第1段階の結論は「提示鍵の下で署名が有効」である。「申告主体の本人確認が完了」ではない。

鍵の所持と鍵の帰属

AIPの検証手順はまず、応答の公開鍵で署名を検査する。次に、その提示鍵が検証者の登録データ、または解決されたDID文書で agentDid に拘束された鍵と一致するかを確認する。草案は、埋め込まれた publicKey だけを信頼してはならないと明記する。

鮮度、nonceの一回性、信頼された issuerDid も必要だが、帰属確認の代替ではない。未拘束の鍵から届いた新鮮な応答は、再送でなくても未拘束のままだ。

運用では、署名検証器と識別子リゾルバーを別の証拠面として扱う必要がある。署名系が正常でもDID文書が古い、取得不能、あるいは誤更新されることがある。反対に正しいDID文書は壊れた署名を救わない。単一の緑色ステータスでは、障害時にどちらの判断が成立したのか復元できない。

DID方式が決める管理主体

03版の変更点は方式のスコープ整理だ。事業者スコープの識別子には did:web を用い、DID文書は事業者がWeb経路で提供する。ドメイン、TLS、公開権限、キャッシュ、復旧手順は、単なるWeb運用ではなく本人性の制御面になる。

did:opena2a はエコシステム・スコープに予約され、アイデンティティ事業者はその文書を配信しない。従来の did:aip:aim_ は非推奨の別名とされた。検証側は文字列の接頭辞から都合よく信頼を推定せず、識別子を不透明値として適切なリゾルバーへ渡す。

これは名前の変更以上のものだ。did:web は事業者の可用性と復旧権限を受け継ぐ。エコシステム方式は事業者の単独支配を離れる代わりに、別のガバナンス、更新、紛争処理を必要とする。無言のフォールバックは、一方の管理主体に他方を代弁させる。

草案は、2026年9月8日時点の参照実装が非推奨別名だけを解決すると記す。これは現在の本番挙動を証明しないが、仕様上の方式と実際に解決できる方式がずれる移行リスクを示す。監査では印字されたDIDだけでなく、判断時に使った方式、リゾルバー、文書ダイジェストを保存すべきだ。

自己記述は認可ではない

エージェントの type は情報であり、セキュリティ判断に使ってはならない。任意の declaredPurpose も、本人性やアテステーションの文脈にはなり得るが、欠落だけを理由に拒否してはならず、認可入力にしてはならない。

「購買エージェント」「調査補助」「請求書確認専用」という記述は、独立した裏付けと認可判断がなければ自己申告にすぎない。信頼スコアも自己採点ではなく、独立検証できる入力を要する。

さらに、正しい鍵が正しいエージェントに結び付いても、その行為が許可されたとは限らない。本人性、能力表明、認可、実行、外部結果は別々だ。チャレンジ発行、署名結果、拘束鍵の解決、発行者信頼、認可、実行、結果の各記録を分け、一つの「verified」に背負わせないことが重要になる。