要約

  • 本人は内側のDelegation Authorizationを署名し、ver=3ではエージェント公開鍵のSPKIハッシュをagent_key_bindingに含める。発行者は、その正確なコンパクト表現を載せた外側のAIC-JWTを署名する。
  • 検証者は外側のcnfが示す所持証明鍵と、本人が署名した鍵束縛を照合する。発行者の署名が正しくても鍵の差し替えは許されず、再発行には新しいnonceを持つDAが要る。

監査担当者が異常に気づいたのは、署名失敗ではなく成功の多さだった。外側の署名も、エージェントの所持証明も、時刻も正常だった。ただし二つの正常な検証が参照していた鍵が違った。本人の委任は鍵Aを指し、発行された資格情報は鍵Bを使っていた。

AI Agent Identity Certificate (AIC) JSON Web Token Profile 02版は、この状態を拒否対象にする。2026年10月2日に公開された有効な個人提出Internet-Draftで、文書上の予定ステータスはInformational、失効日は2027年4月5日である。RFCでもIETFの合意・承認でもなく、実運用の証拠でもない。ここで重要なのは、委任に関わる四者の権限を混ぜない設計である。

内側の文字列をそのまま守る

本人はDelegation Authorization（DA）をコンパクトJWTとして作成し署名する。エージェントまたは発行者は、その文字列全体を外側AIC-JWTのdaクレームに入れる。発行者の署名はその正確な文字列も覆うため、内側のJOSEヘッダー、ペイロード、署名のどれかを変えれば外側の署名も成立しない。

検証時にDAをいったんオブジェクトへ変換し、同じ意味のJWTを作り直してはならない。JSONの順序や符号化が変われば署名対象のバイト列は別物になる。保存すべきなのは、後から正規化した解釈だけでなく、本人が実際に署名したコンパクト文字列とそのダイジェストである。

内外の署名は別の問いに答える。本人の署名は委任の作成者を示す。発行者の署名は、それを運ぶ外側の資格情報に責任を持つ主体を示す。信頼された発行者であっても本人の委任を書き換えられず、正しいDAが入っていても任意の発行者を信頼できるわけではない。両方の鍵は設定済みポリシーで検証され、同じ受容可能な信頼ドメインに根を持つ必要がある。

typによる型の分離も欠かせない。内側DAは単独のAIC-JWTやアクセストークンではない。委任を求めるために署名された入力を、発行済みの出力として再利用させないための境界である。

本人が選んだ鍵を照合する

現在のDAバージョンver=3はagent_key_bindingを必須とする。これは宣言されたアルゴリズムで計算した、エージェント公開鍵のDER SubjectPublicKeyInfoのハッシュである。DA内部にあるため本人の署名で保護される。一方、外側トークンの必須cnfは、発行済みトークンをエージェントの所持証明鍵へ束縛する。

検証者はこの二つが同じ鍵を表すことを確認する。外側署名、DA署名、所持証明がそれぞれ正しくても、組合せは無効になり得る。発行者が端末を取り違えた場合も、中継者の鍵を入れた場合も、発行者自身の署名は正しいままである。比較によって初めて、本人が認めていない差し替えが見える。

ver=2はagent_idだけを束縛し、鍵を束縛しない旧形式である。草案は指定した代替策がある場合に限って受容する。ver=1は拒否し、新規DAはバージョン3を使う。これらを一つの「互換」指標にまとめると、形式の差ではなく証拠強度の差が消える。

kidは、すでに信頼され適切に範囲づけられた鍵集合から候補を選ぶための手掛かりにすぎない。x5cやx5tも、存在するだけでは証明書経路や信頼ポリシーを成立させない。便利なヘッダーが信頼の根になることはない。

更新は新しい同意である

外側のexp - iatはDAが求めた期間を超えられず、外側の期限はDAの期限より後に置けない。発行者は短くできるが、本人の許可を長くすることはできない。

DAのnonceはそのjtiでもあり、最初の発行で消費される。同じDAとnonceから二枚目の外側トークンを作ってはならない。更新や再発行には、本人が新しいnonceを含むDAをもう一度署名する必要がある。つまり更新は発行者による時計の延長ではなく、新しい同意である。

この発行時の再利用防止と、API要求ごとのリプレイ防止は別の台帳を使う。同じアクセストークンを有効期間中に複数回提示することはあり得る。要求単位の再送検知はDPoP proofのjtiなどが担う。DA nonceは「同じ承認から二枚発行したか」、DPoPは「同じ要求証明を再送したか」を問う。

一貫性の後にローカル判断が来る

完全プロファイルは、本人、能力、委任モード、制約、モード固有のsubjectやactor配置も内外で比較する。不一致は拒否する。都合のよい能力だけを黙って残し、それを本人が署名した内容として扱ってはならない。

これらが成立しても、行為が許可されるとは限らない。有効な権限は本人の付与、エージェント能力、AIC制約に囲まれ、ゲートウェイのローカルポリシーがさらに制限する。暗号検証は実行を証明せず、実行ログは外部の銀行・ネットワーク・配送先で期待した結果が生じたことを証明しない。

低リスク向けの軽量consumer profileは、許可されたモードでDAを省ける。その場合、完全プロファイルにある本人承認の暗号学的証明を持たない。選択は可能だが、同じ保証として表示してはならない。