OAuth委任チェーンは意図まで証明しない

Summary

draft-li-oauth-delegated-authorization-03は、authorization serverが署名するrootと、親の束縛鍵で署名されるより狭いchild tokenを連ね、leafの鍵によるDPoPでresource accessを証明する案である。
valid chainが示すのは鍵の連続性とpermission、audience、時間、再委任深度の縮小である。個別delegateを選んだ理由、人が意図したtask、offline verifierにrevocationが届いたかは示さない。
Daniel Kadeは、root mandate、各hopのcustody、taskとeffectの境界、revocation freshness、resource decision、終了証拠を結ぶ別建ての委任意図receiptを提案する。これはdraftの要件ではない。

一つの鍵から次の鍵へ

複数のagentやserviceで仕事を分けるとき、最初のclientが持つ広いaccess tokenをそのまま渡せば、受け手は必要以上の権限を得る。private keyを共有すれば、誰が何を承認したかさえ崩れる。逆に、細かな作業のたびにauthorization serverへ戻る方式では、local delegationの速度と分散性が失われる。

revision 03は、鍵に束縛されたDelegated Authorization Tokenをrootに置く。authorization serverがrootを署名し、cnf.jktに最初のclientのpublic key thumbprintを入れる。そのclientは、残りの深度が許す場合、自分に束縛されたprivate keyでchildを署名し、次のclientの鍵をchildのcnf.jktに結ぶ。

resource serverは順序どおりにchainをたどる。rootの検証鍵はtrusted configurationまたはauthenticated metadataから得る。childのprotected headerには署名用public JWKがあり、そのRFC 7638 thumbprintが直前のcnf.jktと一致しなければならない。最後にleaf clientがDPoP proofを作り、HTTP method、target URI、chainの正確なserializationと自分の鍵を結ぶ。

したがって、serialized chainを盗んだだけでは使えない。draftはDAというHTTP authentication schemeを提案し、Delegated Authorization TokenをBearer tokenとして扱うことを禁じる。

ここで証明できるのは、各parent keyが次の狭い権限を持つkeyを承認し、最後のrequesterがleaf keyを保持するという事実である。組織名や人の目的は、その事実から自動的には生まれない。

小さいJSONが小さい権限とは限らない

validなchildは、permission、audience、validity、remaining depthを広げられない。通常のOAuth scopeなら集合として比較できる。parentのeffective scopeにない値は追加できず、省略すればそのpermission componentを捨てる。

RFC 9396のauthorization_detailsでは、containmentが難しい。金額、resource identifier、action、array、wildcard、defaultの意味はtypeごとに違う。項目を一つ消した結果、制限が外れて広いdefaultになる場合もある。bytesが少ないことはdownscopeの証拠にならない。

そのためdraftは、各detail typeの仕様にdeterministicなsubset ruleを求める。raw JSONの一致やtype名だけの比較では足りない。verifierが意味を実装していない、またはchildがparentに含まれると確定できないなら、chain全体をrejectする。

authorizationに影響するextension claimも同様である。あるcomponentだけが理解する制約を付け、別のresource serverが黙って無視する状態を許せば、署名された「飾り」が権限縮小に見えてしまう。

つまりmonotonicityは暗号だけの性質ではない。authorization vocabularyとそのversion、defaultやwildcardを扱う実装の合意もcontrol surfaceになる。

深度はhop数であってrisk scoreではない

rootには有限のmax_delegation_depthが入る。effective valueが0ならchildは無効である。正の整数mなら、childは0からm-1を明示でき、省略時はm-1になる。authorization serverはdeployment上の最大値を設け、parserとverifierはtoken数、size、verification costにも別の上限を置く。

この数字が制御するのはgraphの辺の数である。一回のterminal delegationが破壊的なwriteを許すことも、三回のdelegationがread-onlyで終わることもある。depth 0は「さらに渡せない」を意味するだけで、「低リスク」「人がこのdelegateを見た」「このtransactionに同意した」を意味しない。

resource ownerが関与するgrantでは、最初のauthorization decisionが、client-issued childを後からserverやownerとの再対話なしに作れる能力と最大深度を含まなければならない。普通のaccess approvalをdelegation approvalに読み替えてはならない。明示した深度を拒否されたとき、勝手に小さい値へ変えて承認扱いすることもできない。

一方、draftはその能力をownerへどう表示するかを定義しない。「あと二段委任できます」と表示しても、将来どのagentが選ばれるか、public keyをどこで見つけるか、何のtaskを任せるか、どのeffectで再承認が必要かまでは伝わらない。

task bindingは意図的なscope外

draftのscope外には、client key discovery、out-of-band negotiation、複数chainのdelivery、受け取ったchainと特定requestまたはtaskのbinding、application-specific detailの比較規則、revocation status distributionが並ぶ。

この一覧は、protocolの不足を告白するものではない。generic authorizationと実際の業務目的が接続する場所を正直に分離している。

たとえばresearch agentが、一つのknowledge APIに対するread権限を十分間、再委任不可で受け取る。chainは完全にvalidでも、「承認済み資料を要約する」と「access可能な人事資料を全部探索する」を区別しない。resource policyとrequest contextが一部を判断し、人のtask instructionが残りを決める。

chain validationだけではprotected requestをauthorizeできないとdraft自身が述べる。resource serverはDPoP、request binding、audience、application permissionも検証する。さらにallow decisionはexecution successでもない。許可された操作が失敗したり、別systemに二次効果を起こしたりする。

root mandate、hop custody、task intent、current validity、observed effectは別々の問いである。

revocationは記録されても到達したとは限らない

rootをrevokeすれば、そこから始まる全chainが無効になる。childをrevokeすれば、それを含むchainとdescendantは無効になるが、parent、sibling、同じkeyに結ばれた別tokenまで自動で消えるわけではない。

しかしauthorization serverがrevocationを記録しただけでは、offline validationを行うresource serverへ状態は届かない。revision 03はdistribution mechanismを定義していない。short lifetimeは未知のwindowを短くするが、各serverが何時に知ったかを証明しない。

auditには二つのclockが要る。revocationを書いた時刻と、resource decision時にverifierが実際に持っていたstatus version、age、failure policyである。10時の記録から、10時1分に全serverが認識したとは言えない。

chain validation cacheもこの差を消さない。signatureとeffective restrictionはexact-chain digestでcacheできるが、expiration、authorization-server key status、local policy、届いたrevocationに応じて無効化する必要がある。DPoP freshnessとreplay checkはrequestごとに残る。

観測主体が中央から周辺へ移る

local delegationでは、authorization serverが各delegate、downstream resource、access time、multi-hop patternを自動的に知る必要がない。中央の可視性を減らせる。

ただしresource serverはcomplete ordered chainを見る。rootとintermediate claimはissuer、subject、client relationship、audience、permission、workflow structureを漏らし得る。stableなcnf.jktやjtiはrequestやresourceをまたぐcorrelationにもなる。

audit visibilityは消滅せず、配置が変わる。root issuanceはauthorization server、local delegationは署名client、validationとresource decisionはresource serverが観測する。draftはcomplete credentialを通常logへ置かず、one-way chain digestでeventsを結び、AuthorizationとDPoP headerをredactするよう勧める。

必要なのは巨大なcredential archiveではなく、複数主体が最小限のdigestで同じ出来事を照合できる仕組みである。

同じprivate keyが二つの行為を可能にする

bound private keyはleaf tokenの使用を証明し、深度が残ればchild tokenも署名できる。key compromiseは、既存権限のexerciseと新しいdescendantのcreationを同時に可能にする。

draftはnon-exportable keyと狭いsigning APIを勧める。token-signing inputとproof-signing inputを区別し、可能ならtokenごとに異なるkeyを用いる。reuseはcorrelationとblast radiusを増やす。

さらにchild tokenはparent identifierを含まない。直前tokenが同じsigning keyを束縛し、そのeffective restrictionがchildを包含するなら、別のchainでもvalidになり得る。revision 03では意図した性質である。一つのparent chainだけに限定したいdeploymentは、parent keyを分けるかapplication restrictionを加える。

thumbprintが示すのは鍵であって、当時その鍵を支配したprocess、signing APIのtask policy、組織上の担当者ではない。

委任意図receipt

私は委任意図receiptを提案する。Daniel Kadeによるprotocol外のgovernance設計であり、draftの要件でも新しいOAuth claimでもない。

root部分には、authorization eventとconsent presentation versionの安全なdigest、issuerとtrusted metadata snapshot、delegation capability、effective permission、audience、lifetime、depthを置く。token、private key、DPoP proof、raw header、不要なsubject dataは保存しない。

各local hopでは、exact chain digest、parentとchildのpublic thumbprint、前後のeffective restriction、containment ruleとversion、signing service identity、client選定の最小証拠を結ぶ。key reuseやone-parent requirementも明示する。

protocolにない中心部分は、具体的task、acceptable output、effect boundaryのdigest、decision owner、environmentやtransaction limit、再度のhuman interactionを要求する条件である。本文や機密dataを複製せず、意図を照合できる最小表現にする。

reliance時には、resource serverのpolicy version、containment implementation、受信したrevocation-state versionとfreshness、DPoP result、effective authority、allow/denyを残す。closureはobserved operation class、success/failure、重大なsecondary effect、rollbackまたはincident referenceを記録する。

最小初期仕様はroot mandate、hop digest、task/effect digest、revocation freshness、resource decisionの五つでよい。目的は意図を数学的に証明することではなく、chainが運ばない証拠をeffect発生前に保存することである。

正しい結論を小さく保つ

revision 03は2026年7月24日に更新されたindividual Internet-Draftである。OAuth WG adopted document、IETF consensus、Last Call、IESG approval、RFC、live IANA registrationではない。文書の精密さはdeploymentやadoptionを示さない。

その境界内で、この案は重要なことを実現する。local delegationにverifiable key lineageを与え、authority expansionをrejectし、semantic comparisonとoffline revocationの外部依存を明らかにする。

valid chainから言えるのは、鍵の連鎖が所定の制約下で権限を縮小し、leaf keyがそれをexerciseしたということまでである。人が特定のdelegateと結果を望んだことは別の証拠を要する。

data disclosureやsystem changeが起きた後、欠けていた意図を後日のsignatureで再生することはできない。権限はchainに、意図はその隣のreceiptに置くべきである。

委任チェーンは権限を絞れても意図までは運べない

なぜ重要か

Summary

一つの鍵から次の鍵へ

小さいJSONが小さい権限とは限らない

深度はhop数であってrisk scoreではない

task bindingは意図的なscope外

revocationは記録されても到達したとは限らない

観測主体が中央から周辺へ移る

同じprivate keyが二つの行為を可能にする

委任意図receipt

正しい結論を小さく保つ

出典

プロフィールの詳細

Strategic Circle

Leadership Alliance

Strategic Circle 向けブリーフィング

Leadership Alliance 解説