Summary

  • revision 01は、Issuer署名付きJWT CredentialをAuthorization: DPoPに載せ、RFC 9449と同じrequest proofを使う。
  • wire formatとproofが同じでも、access tokenとCredentialの意味は同じではない。Verifierは信頼済みissと許可したtypで処理を分ける必要がある。
  • requestへの鍵所持証明は、Issuerが設定するaud、現在のstatus、claim開示の妥当性、local authorization、処理結果を代替しない。

再利用されたのは運搬路である

提案の狙いは、新しいpresentation envelopeを増やさず、OAuth resource serverがすでに持つDPoP処理を使うことだ。HolderはCredential全体をtokenの位置に置き、別のproofにhtu、htm、iat、jti、必要なnonce、athを署名する。athは受信したCredentialのUS-ASCII bytesに対するSHA-256であり、proof keyはcnf.jktまたはcnf.jwkのthumbprintと照合される。

ここまで成功しても、値の種類は決まらない。RFC 9068のJWT access tokenはaudとat+jwtを要求する。今回のCredentialはdeploymentが定義した別のtypを必要とし、at+jwtやID Token用typeを使えない。両方を受け取るserverは、信頼するissと受理するtypでvalidation branchを切り替える。同じwire appearanceを理由にbranchを共有すれば、暗号的に正しい入力へ誤ったpolicyを適用する。

request bindingはaudienceではない

htuとhtmは、確認済みkeyがこのmethodとURIのrequestに使われたことを示す。これはrequest-level proof-of-possessionである。一方、Credentialを受理してよいVerifierの集合は、存在するならIssuerが発行時に設定したaudで決まる。Holderが送信先を選んでもaudienceを後から作ることはできない。

提案はaudのないCredentialを認める。その場合、同じIssuerを信頼するすべてのresource serverがpresentation先になり得る。共通のidentity providerを信頼することと、同じclaim vocabularyや業務権限を受け入れることは別だ。したがってVerifierは、Credentialが有効というだけでaccessを推論してはならない。

長い寿命はstatusの鮮度を問う

Credentialはaccess tokenより長く使われ得る。その差を埋めるのが推奨statusである。status claimがあればVerifierは取得して確認し、invalidなら拒否する。長寿命なのにstatusがないCredentialをlocal policyで拒否することもできる。

status listをcacheすれば、そのcache lifetimeがrevocation delayになる。Issuer signature、freshなDPoP proof、過去に取得したstatusは、それぞれ異なる時計のreceiptだ。requestごとにIssuerへ問い合わせない構造はlatencyと直接追跡を減らすが、status取得自体が利用先を示す可能性も残る。

全体を送るという制約

この方式にはclaim selectionがない。すべてのVerifierがJWT全体を見て、安定したsignature valueによって横断的に相関できる。Authorization headerがaccess logやproxyに残る危険もある。TLSは通信路を守るが、不要なclaimや保存済みcopyを消さない。

VerifierがCredentialを発見し、必要なclaimだけを求め、人の同意を取る必要があるなら、OpenID4VPのようなnegotiation型の仕組みが適する。ここで想定されるのは、softwareが相手とCredentialを事前に知る場面だ。SD-JWT VCもdisclosureなしのIssuer-signed JWTとしてしか使えない。

Lu HengのMinimum Initial Specificationが示すのは、小さな共通機構の再利用と、すべてのauthorityを一か所へ集めることの違いである。Running-Code Primacyの観点では、実際のtyp branch、Issuer trust、audience、status age、authorization version、resource resultを別々に残すべきだ。

Sources and limits

これらはOAuth WG adoption、IETF consensus、RFC化、実装、相互運用、AI agent deployment、実際の発行・失効、認可、service resultを証明しない。既存のRFC 9449 Articleは一般的なsender constraintを扱い、本稿はrevision 01のsame-wire/different-authority問題だけを扱う。