要約

  • draft-ietf-oauth-transaction-tokens-11は、audで区切られたTrust DomainのCall Chainにおいて、本人・workload情報と取引文脈を運ぶ短命な署名付きJWTを定める。現在はWG Consensus: Waiting for Write-UpのStandards Track Internet-Draftであり、RFCでもIETFの最終承認でもない。
  • 受信側はJWS署名、audience、有効期限を検証しなければならない。これはコンテナの完全性と適用範囲を確かめるが、各rctxやtctx値が依頼者入力、観測、導出、TTSの独立主張のどれかまでは自動的に証明しない。
  • Daniel Kadeは、実際に判断へ用いたclaimごとに、出所、実施した検証、観測者と時刻、変換、policy版、鮮度、許容用途、矛盾、結果を記す「claim-origin envelope」を提案する。完全なtokenや不要な個人情報ではなくhashや参照を保存できる。これはIETF要件ではない。

承認記録には二つの緑色が並んでいた。「JWS valid」と「customer_verified」。一つ目は再検証できた。二つ目は、どの主体が、どの証拠で、いつ確かめたのか分からなかった。値は署名対象に含まれている。それだけを理由に、画面はTTSが本人確認まで行ったように見せていた。

暗号の故障ではない。証明した範囲より広い名前を付けたことが故障だった。

JWS署名から分かるのは、特定の鍵が特定のbytesを署名し、その後にbytesが変わっていないことだ。Transaction Token Serviceは、どのclaimをtokenへ入れるかについて権威を持つ。しかし、値の採用権限と、値の元になった出来事の独立検証は同じではない。後段のworkloadが必要とするのは、コンテナ保証とclaim保証を混ぜない記録である。

第11版は前進だが、RFCではない

Datatrackerは、2026年7月30日付の第11版をOAuth Working Groupの現役Standards Track Internet-Draftとして掲載している。調査時点のWG状態はWG Consensus: Waiting for Write-Up、IESG状態はI-D Existsで、担当Area Directorもtelechat日も示されていなかった。成熟した作業段階ではあるが、最終承認やRFCとして扱うことはできない。

履歴と第10版から第11版への公式差分によれば、変更は文書履歴の誤記訂正に限られる。本稿が扱う保証構造は第10版にもあった。I-D announcementは第11版の発行を知らせるもので、標準化完了の告知ではない。

提案が対象とする問題は、microserviceの現場では分かりやすい。一つの外部要求が複数のserviceを通るたび、主体、目的、権限範囲、取引詳細を引き継ぐ必要がある。すべてのserviceへ元のcredentialを渡して各自に解釈させると、露出と実装差が増える。そこでTransaction Tokenは、audが示すTrust Domainの内部だけで使う短命な署名付きJWTとして、共通文脈をCall Chainへ運ぶ。

各Trust Domainには論理的に一つのTTSが置かれる。実体は複数instanceでもよい。TTSはtokenを要求するworkloadを認証し、要求権限を確認し、文脈を選び、署名する。JWTがclaim形式を、JWSが署名表現を提供し、OAuth WGが文書を進めている。

受信検証とlocal authorizationは別の責務

受信workloadには三つの必須検証がある。JWS署名を検証すること、audが自分のTrust Domainを指すことを確かめること、期限切れでないことを確かめることだ。これで、正しいdomain向けにTTSが署名した未改変のtokenを有効時間内に受け取った、と言える。

その後のauthorization方法は仕様の範囲外である。workloadはtoken中の情報を使えるが、実行を許す責任は自ら負う。「署名検証済み」はlocal policyを置き換える判定ではない。

仕様はTransaction Tokenをauthentication credentialとして扱わず、OAuth access tokenとして使用してはならないとも定める。OAuth 2.0のaccess tokenはauthorityのgrantを表す。Transaction Tokenはtransactionのcontextを表す。形式が似ていることを理由に後者へ前者の権能を与えると、説明が許可へ変質する。

replayにも自動的な耐性はない。一意のtxnは再利用検知や一回限りの運用を助けるが、分散したCall Chainで厳密に実施するには共有stateが必要になり、実現できない場合がある。署名は二度目の提示を物理的に妨げない。

claimの集合は一つでも、生成経路は一つではない

必須のscopeはTTSが決める。元のsubject tokenが表すscopeを拡大してはならず、scopeを理解できない場合は無制限とみなさず拒否しなければならない。これは入力権限と出力権限の間にある明確な制約である。

推奨されるrctxはrequestまたはenvironmentのcontextを格納する。依頼者がcontextを渡したとき、TTSはそれを評価すべきだ。ただし最終値は、入力と完全に一致する場合、入力から導出される場合、TTSが独立にassertする場合がある。TTSは利用可能にするclaim集合について権威を持つ。そのことは、集合内の全要素を同じ証拠で確かめたという意味ではない。

同じく推奨されるtctxは、Call Chainを通じて不変であるべき取引詳細を運ぶ。値はrequest詳細の写しでも、導出結果でも、TTSが追加した主張でもよい。署名後の不変性と、署名前の来歴は異なる問いである。

例えば、source_ipは認証済みgatewayが観測し、transfer_amountは依頼者のunsigned JSONから転記し、risk_tierはTTSが検証済みcredentialと外部signalから計算したとする。三つとも同じ署名で完全性を得る。だが、IPにはgatewayの観測信頼、金額には入力権限、risk tierにはmodelとpolicy版の説明が必要だ。まとめて「issuer attested」と呼ぶと、その違いを消してしまう。

これはrctxやtctxが本質的に信用できないという主張ではない。ある値は非常に強く検証され得る。保証の強さが、具体的なsource、check、time、transformation、useに依存するという主張である。一つのtokenの中で異なる保証が共存すること自体は問題ではない。見分けられないことが問題になる。

subject tokenの多様性は検証履歴の多様性になる

TTSへ渡すsubject tokenにはOAuth token、SAML token、self-signed JWT、unsigned JSON object、TTSが理解する独自形式を使える。TTSはsubject tokenを検証し、署名付きなら署名も検証する。したがって「validated」という一語の中身は形式ごとに異なる。issuer、key、algorithm、audience、時刻、schema、transport contractなどの確認が組み合わさる。

JWT Best Current Practicesは、token自身の指定だけからalgorithmやkeyを安全に決められない理由を示す。OAuth Token Exchangeはtoken交換の関連枠組みであり、Transaction Token案はdomain内部の取引文脈に焦点を置く。保護された経路でunsigned JSONを有効入力とするdeploymentもあり得るが、それが署名credentialと同じ暗号保証を持つわけではない。

TTSは要求workloadのauthenticationと、希望するtokenを取得するauthorityも検証する。一方、発行policyとbusiness logicはdeployment固有で仕様外だ。同じfield名を採用する二つの実装が異なるcheckを行っても、両方が仕様に従う場合がある。ローカルのpolicy versionを残さなければ、共通syntaxが差を隠す。

tokenの期限と情報の鮮度は一致しないことがある

Transaction Tokenの寿命は数分以下、予想されるinvocationの時間だけであるべきだ。それでもTTS policyの下で、発行時に提示されたsubject tokenより後まで有効にでき、TTSはそのriskを評価すべきだとされる。開始済みの短い処理を完了するには合理的でも、新tokenのexpが上流情報すべての現況確認を意味するわけではない。

OAuth access tokenは自然な期限前にinvalidatedとなることもある。riskに応じてTTSはtoken introspectionなどで現在の失効状態を確認できるが、常時照会が一律必須ではない。「未期限切れ」と「12時04分に失効なしを確認」は別の証拠である。

replacement tokenは許可行為を拡大できず、txn、sub、audを変更できない。scopeを縮小し、assertionを追加し、policyによって期限を延長することはできる。要求したworkloadのCall Chainを保持しなければならないが、保持方法は仕様外だ。どのreplacementでclaimが追加されたか分からないと、最終tokenは段階的な生成履歴を一枚の静止画にしてしまう。

Trust Domainを越える場合も同様だ。Transaction Tokenは自身のaud内だけで有効で、cross-domainの継続は別のOAuth identity-and-authorization chainingの対象になる。他domainが署名を検証できても、元domainのローカルな意味と信頼判断まで自動的に受け継ぐことはない。

一人のreviewerの指摘を、consensusへ膨らませない

2026年8月8日のWGLC messageで、一人のreviewerは文書の前進を支持し、blocking commentはないとした。その上でreplacement chainのauditabilityを明確にするよう求め、signed tokenに運ばれた情報とissuerが独立にattestした情報を実装者が混同し得る、と警告した。

これは有用なreview evidenceだが、範囲を守る必要がある。一人のreviewerと、その人が述べた実装経験である。WG consensus、導入率調査、確認済みincident、revision 11の欠陥証明ではない。運用上起こり得る読み違いを具体的に名指しした資料として扱うべきだ。

判断の横にclaim-origin envelopeを置く

Daniel Kadeが提案するのは、新しい万能token schemaではない。実際に判断へ使った各値の横に置くclaim-origin envelopeである。source classと非秘密のsource identifier、実施したvalidation、observerと時刻、transformationとcodeまたはpolicy version、関係するissuer・signing key・Trust Domain、freshnessまたはinvalidation check、許容用途、sensitivityとlogging rule、矛盾や未確認事項、downstream decision、expiryとclosureを記録する。

envelopeはTransaction Token外に置ける。issuance receiptを参照し、token hashだけを保存し、redacted evidenceへlinkしてもよい。草案はreplayと機微情報のriskから、完全なTransaction Tokenをそのままlogすることを禁じる。TTS発行記録との照合にはhashを使え、署名を除いたJWS payloadを記録する選択肢もある。ただしpayloadにも個人情報が含まれ得る。requester IPなどが法的に個人情報となるかはjurisdiction次第で、本稿は法令遵守の結論を出さない。

必要なのは、判断の根拠を後から再構成できる最小限の記録である。再利用できるbearer tokenや生の個人情報をもう一つの倉庫へ複製することではない。

情報源