要約

  • draft-wei-aic-jwt-01は2026年9月8日に公開された、個人投稿の有効なInternet-Draftである。IETF採用文書でも承認済み標準でもなく、実装実績も示さない。Experimentalは著者が望む到達点にすぎない。
  • フルプロファイルでは、プリンシパル署名のDelegationAuthorization JWTを、発行者署名のAIC-JWTが包む。内側は権限とagent_idを保護し、外側はそのDA文字列とcnfを保護する。
  • 01版は、現行DAが権限をエージェントIDに結び付ける一方、DA内のエージェント公開鍵結合は将来版に残すと明記した。現在の提示鍵は外側のcnfで示され、利用時に所有証明が検査される。
  • 「二重署名は有効」という一行ではなく、各署名者がどの結合を引き受けたかを鍵結合票に残すべきだ。これはDaniel Kadeの提案であり、IETF要件ではない。

版番号が進んでも、標準化段階は進んでいない

I-D Announceは01版を9月8日14時48分UTCに記録した。DatatrackerではIndividual Submissionsに属し、状態はI-D Existsである。RFCストリーム、担当Area Director、telechat日はない。Internet-Draftは誰でも提出できる。冒頭の「Intended status: Experimental」は著者の希望を示すが、IETFによる採用、承認、導入勧告にはならない。

それでも00版との差は大きい。AIC-JWTは、別のX.509 AIC草案で定義されたモデルをHTTP、Web、OAuthのアプリケーション層へ写すものだと整理された。JWTやOAuthが新しい権限を生むのではなく、外部のAIC能力方式と配備方針が意味を決める。

DAのclaims versionは1から2になり、RFC 7523でgrantとして扱うためのフィールドが加わった。01実装は00版のDAを暗黙に読み替えず、拒否しなければならない。なかでも運用上重要なのは、プリンシパルが承認するエージェントIDと、実際にトークンを提示する鍵を同じ署名事実として扱わない点である。

内側の署名は委任内容を動かせなくする

PKIフローでは、まずエージェントが鍵ペアを生成し、希望する能力、委任モード、制約、nonceを含む発行要求を作る。プリンシパルが要求を確認してDA JWTに署名し、エージェントへ返す。エージェントはそれをCAへ提出する。OAuth ASモードでは、同じプリンシパル署名DAをRFC 7523のJWT bearer authorization grantとしてtoken endpointへ送る。

DAにはiss、sub、aud、exp、jtiに加え、agent_id、プリンシパル結合、理由、能力、委任モード、制約、要求有効期間、時刻、nonceが入る。検証鍵はプリンシパルのkey_hashと一致し、jtiはnonceと同じでなければならない。内側の型はaic+da+jwt、外側はaic+jwtなので、委任だけを最終トークンとして受理してはならない。

外側のda claimは、受け取ったcompact serializationをそのまま保持する。検証前の再構築や再シリアライズは禁止される。発行者が能力、モード、対象、agent_idを書き換えればプリンシパル署名が壊れる。逆にプリンシパル鍵だけでは、発行者署名が必要な外側トークンを作れない。

この署名が証明するのは、プリンシパルが特定のエージェントIDに特定の条件で委任したという命題である。現在のDAには、提示鍵そのもののthumbprintをプリンシパル署名へ入れる仕組みはない。

提示鍵は外側のcnfに載る

エージェント鍵を示すのは必須のcnf claimである。RFC 7800のconfirmation claimを使い、RFC 7638のJWK thumbprintであるjktが推奨される。DPoPを使うなら、cnf.jktとproof鍵のthumbprintは一致しなければならない。mTLS環境は、クライアント証明書の鍵との照合もできる。

01版はPKIとOAuthの両方の発行節で同じ境界を書く。DA-levelのエージェント鍵結合は、X.509 AIC DA v2に合わせた将来のclaim-set revisionに予約されている。現行版では、提示鍵をcnfで利用時に結び付ける。cnfは外側payloadにあるため、その値を署名で覆うのは発行者である。

これは発行者が好きな鍵を選べるという意味ではない。記述されたフローではエージェントが鍵を生成し、プリンシパルは要求を確認する。発行者はDA署名、プリンシパル鍵、audience、期限、nonceの一意性、能力制限を検査し、外側の期限をDAより長くできない。問題は不正の主張ではなく、後から何を証明できるかだ。

監査者が二つの署名結果だけを受け取った場合、内側からはプリンシパルがagent_idを含むDAに署名したこと、外側からは発行者が特定のcnfとDAを一緒に署名したことが分かる。プリンシパルが画面で鍵を見た事実まで証明するには、発行記録が別に必要である。

さらにcnfの存在だけでは所有証明を実行したことにならない。草案はAIC-JWTが本質的にsender-constrainedではないと警告する。検証側がDPoP等を強制しなければ、盗まれたトークンが期限までbearer credentialとして使われ得る。鍵の指定と、その鍵を今回の送信者が持つという判定は別の出来事である。

鍵結合票は秘密を増やさず責任を残せる

高い保証が必要な配備では、DAの正確なhashとversion、プリンシパル鍵ID、agent_id、発行者、外側token hash、cnf方式と鍵thumbprint、発行方針、nonce消費結果、期限の交差、提示時の所有証明方式、検証結果、取消・訂正参照を一枚の鍵結合票に残したい。プリンシパルが鍵を明示確認した場合だけ、その証拠を独立した欄に置く。

replayの時計も二本必要だ。DA nonceは最初の発行で消費され、同じDAから二つ目の外側トークンを作らせない。一方、発行済みaccess tokenは有効期間中に複数回提示されることがある。要求ごとの再送防止はDPoP proofのjtiなどが担う。発行の一回性を、通信の一回性と読み替えてはならない。

鍵thumbprintや関係図は相関情報になり得る。票は公開台帳でなくてよい。権限のある監査者にだけcommitment、方針結果、参照番号を開示する設計もできる。最小化しながら責任を保存することが目的である。

Heng LuのPolicy Mirrorを当てると、選択と帰結が見える。プリンシパルはIDと能力を選び、発行者はDAを受理して現在の鍵結合に署名し、検証者は所有証明とlocal policyを適用し、resource ownerが作用を受ける。二重署名を一つの信用表示に縮めると、まさにこの分担が消える。

情報源