要約

  • 新しいindividual Internet-Draftは、単一resource server向け、短命、取引単位のpolicy再評価を備えたtxnat+jwtを提案する。
  • 型を正しく検証しても、refresh tokenやclient credentialの永続性、bearer replay、複数resourceのpartial commit、実行結果までは証明できない。

draft-tulshi-oauth-transactional-access-tokens-00は2026年9月29日公開の初版である。Standards Trackを意図するが、OAuth Working Group採択、IETF consensus、RFCではない。実装、相互接続、性能や安全性を示す一次証拠もまだない。評価対象は設計上の責任分離である。

Txn-ATはRFC 9068のJWT access tokenを土台にする。typをtxnat+jwtに変え、audを一つのresource serverに限定し、txnを必須にする。tctxとrctxにはauthorization serverがpolicyで評価してから主張するcontextを載せる。推奨寿命はiatからexpまで300秒以内だ。

異なる型は装飾ではない。Txn-ATを知らない受け手が普通のaccess tokenとして処理すると、取引境界を理解しないまま権限だけ受け取る。逆に内部workloadが外部Txn-ATをtrust-domain用のtxntoken+jwtとして受ければ、境界を飛び越える。両方を拒否することが設計の一部になる。

発行までの権限は短命ではない。clientはtoken exchange、refresh token、またはclient credentialsを使う。authorization serverは毎回policyを評価し、credentialやtransaction handleが正しくても拒否できる。新しい取引には、client、subject、必要ならsender-constraining keyへ結びついたopaque handleも返す。

handleは同じ取引の別resource向けtokenを要求できる。ここで証拠は分かれる。永続credentialは質問する資格、policy receiptは今回の判断、handleは取引の継続、Txn-ATは一つのaudienceへの主張、内部Txn-Tokenはtrust domain内のcontext、execution receiptは現実の効果を示す。

draft自身、consentとclient authorityはdurableだと述べる。authorization codeで一度得たrefresh tokenは、後の取引でユーザー操作を要求しない。盗まれた根credentialはpolicyを自動突破しないが、何度でも審査を受ける入口になる。短いexpだけをrisk metricにすると根を見失う。

policyが毎回動くことと、正しい判断をすることも別である。client入力を未評価のままtctxやrctxへコピーしてはいけない。subject、authentication、attestation、resource、authorization details、environmentのfreshnessを確認する必要がある。署名はserver assertionのintegrityを守るが、判断の妥当性を保証しない。

同じ取引でもaudienceごとにtxnを変えるため、resource同士の単純な照合は難しくなる。しかしclient_id、発行時刻、subject、contextは別のjoin keyになりうる。authorization serverは内部transaction IDを知り、すべての要求を見る。相関が消えるのではなく、中心へ集約される。

HMACで内部IDとaudienceからtxnを導く案はmapping tableを不要にする一方、K_txnのrotationとretentionを監査設計にする。retired keyを残す期間、誰が参照できるか、内部stateと同時に漏れた場合の相関範囲を決めなければならない。

replayはさらに明示的だ。bearer Txn-ATは有効期間中に再利用できる。draftはDPoPまたはmutual TLSを推奨し、一回性が必要なserverにはjti記録を許すが、必須ではない。五分間はpayment、deletion、network changeを複数回起こすには十分である。

txnはapplication idempotency keyでもない。二つのHTTP requestが同じbusiness effectかを決めず、RS1成功・RS2失敗をatomicに戻さない。request ID、duplicate rule、commit receipt、compensationはapplication側に残る。

したがってrunning codeの試験はnegative pathから始める。wrong typ、複数aud、expired handle、違うclientまたはsubject、stale context、key mismatch、ordinary-token downgrade、内部token exchange失敗を公開する。registration metadataは意図であり、実行証拠ではない。

薄い共通層が運べるのは型、audience、provenance、評価済みcontextまでである。policy engineの判断を普遍化せず、token acceptanceをexecutionへ昇格させない。この境界を保てるなら、取引単位化は広いsession grantより観察可能になる。

情報源