An agent presents two credentials: one representing me and one identifying Agent XYZ. A token service returns an access token stating that Agent XYZ is acting on my behalf.<\/p>\n
What prevents the agent from taking that token somewhere I never authorized?<\/p>\n
Not the actor claim alone.<\/strong> Secure delegation requires verified input credentials, controlled issuance, restricted output tokens, and enforcement by the receiving application. OAuth token exchange supplies the protocol; it does not automatically determine what I intended.<\/p>\n The RFC behind token exchange<\/strong><\/p>\n RFC 8693, OAuth 2.0 Token Exchange<\/strong>, defines an OAuth-based Security Token Service, or STS. A client submits existing security tokens and requests a new token suitable for a particular purpose. The exchange can change token format, target audience, or authorization context, including representing delegation or impersonation.<\/p>\n The distinction matters:<\/p>\n For our agent scenario, delegation is the useful model: Lisa remains the authorization subject, while Agent XYZ is recorded as the actor.<\/p>\n How an exchange works<\/strong><\/p>\n An illustrative request to an STS token endpoint contains:<\/p>\n grant_type=urn:ietf:params:oauth:grant-type:token-exchange<\/p>\n subject_token=<Lisa’s eligible access token><\/p>\n subject_token_type=urn:ietf:params:oauth:token-type:access_token<\/p>\n actor_token=<Agent XYZ’s supported identity token><\/p>\n actor_token_type=urn:ietf:params:oauth:token-type:jwt<\/p>\n requested_token_type=urn:ietf:params:oauth:token-type:access_token<\/p>\n audience=case-management-api<\/p>\n scope=cases.read cases.update<\/p>\n <\/p>\n The subject_token provides the subject\u2019s security context; the optional actor_token identifies the proposed actor. audience, resource, and scope describe requested targets and permissions. These are requests<\/strong>, not issuer obligations. Client authentication is a separate consideration from submitting either token.<\/p>\n The conceptual flow is:<\/p>\n Existing credentials + requested target and permissions<\/p>\n |<\/p>\n v<\/p>\n Security Token Service<\/p>\n \u251c\u2500 Validate credentials<\/p>\n \u251c\u2500 Evaluate exchange policy<\/p>\n \u251c\u2500 Establish delegated authority<\/p>\n \u2514\u2500 Issue a constrained token<\/p>\n |<\/p>\n v<\/p>\n Resource API<\/p>\n \u251c\u2500 Validate issued token<\/p>\n \u2514\u2500 Authorize this operation<\/p>\n <\/p>\n An exchange bridges security contexts; it is not simply a JWT re-signing operation. RFC 8693 explicitly limits its scope to the exchange protocol rather than defining every deployment\u2019s trust and authorization policy.<\/p>\n The exchanger must verify\u2014not believe\u2014the inputs<\/strong><\/p>\n The STS should not accept:<\/p>\n subject = Lisa<\/p>\n actor = Agent XYZ<\/p>\n trust_me = true<\/p>\n <\/p>\n It must establish those identities from credentials validated under an explicitly configured trust relationship. Token-validation rules depend on the accepted token profile; the API must also validate the resulting token independently. For JWT access tokens using RFC 9068, validation includes the expected token type, issuer, audience, signature, and expiration. (datatracker.ietf.org<\/a>)<\/p>\n For this deployment, I would require the following issuance controls:<\/p>\n <\/p>\n These are recommended policy requirements\u2014not defaults guaranteed by enabling RFC 8693. Its may_act claim can express actor eligibility, but identifying an eligible actor is still different from authorizing every requested target or operation.<\/p>\n Crucially, the resulting token is normally issued for the resource server to validate<\/strong>, not merely for the exchanger to recognize later. A resource server that trusts the STS must still enforce the token\u2019s intended use.<\/p>\n A signed actor claim is attribution, not consent<\/strong><\/p>\n An illustrative delegated token might contain:<\/p>\n {<\/p>\n “iss”: “https:\/\/identity.example.org”,<\/p>\n “sub”: “user:lisa”,<\/p>\n “aud”: “case-management-api”,<\/p>\n “scope”: “cases.read cases.update”,<\/p>\n “act”: {<\/p>\n “sub”: “spiffe:\/\/agents.example.org\/agent\/xyz”<\/p>\n }<\/p>\n }<\/p>\n <\/p>\n The issuer asserts that Lisa is the subject and Agent XYZ is the current actor. The signature protects that assertion against modification. The actor claim does not<\/strong>, by itself, establish that Lisa approved a specific case update or requested access to another application.<\/p>\n This is the central distinction:<\/p>\n Who is acting, whose authority applies, and which action was authorized are separate facts.<\/strong><\/p>\n If the deployment intentionally gives Agent XYZ all of Lisa\u2019s application rights, then an unexpected operation within those rights may be policy-authorized even though Lisa did not intend it. No token format can recover a narrower instruction that the authorization system never captured.<\/p>\n Preventing the \u201cLisa never asked for that\u201d failure<\/strong><\/p>\n There are several different failures hiding inside that example. They require different controls.<\/p>\n Suppose Agent XYZ receives a token for the case-management API, then presents it to payroll.<\/p>\n Payroll must reject it because payroll is not its intended audience. Sharing an issuer or signing key does not make a token valid for every application. RFC 9700 recommends audience-restricted access tokens to limit this kind of reuse.<\/p>\n For this architecture, prefer one narrowly defined target per token and exact audience validation at each API.<\/p>\n Audience validation does not help if the agent can ask an STS to convert its case-management token into a payroll token.<\/p>\n The recommended issuance policy is to authorize each permitted exchange edge explicitly:<\/p>\n Lisa delegation + Agent XYZ \u2192 case-management: allowed<\/p>\n Lisa delegation + Agent XYZ \u2192 payroll:\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 denied<\/p>\n <\/p>\n Changing audience is a legitimate purpose of exchange, so the defense is not \u201cnever change audience.\u201d It is never let possession of an input token alone authorize an arbitrary audience transition<\/strong>. This follows from the protocol\u2019s separation between the requested target and issuer policy.<\/p>\n Audience restriction cannot distinguish \u201cupdate case 4821\u201d from \u201cupdate every case Lisa can access.\u201d A broad cases.update scope may be equally insufficient.<\/p>\n RFC 9396, Rich Authorization Requests<\/strong>, defines authorization_details for expressing finer-grained authorization requirements using structured JSON. The application-specific authorization type must define what those details mean and how they are enforced.<\/p>\n For example, a proposed\u2014not standardized\u2014authorization object could be:<\/p>\n {<\/p>\n “type”: “case_operation”,<\/p>\n “actions”: [“update”],<\/p>\n “case_ids”: [“4821”],<\/p>\n “allowed_fields”: [“status”],<\/p>\n “allowed_status_values”: [“resolved”]<\/p>\n }<\/p>\n <\/p>\n In this design, Lisa approves that operation through a trusted authorization interaction. The STS issues authority no broader than the approved operation, and the API checks the actual resource and requested mutation against it.<\/p>\n RFC 9396 does not<\/strong> automatically add this object to RFC 8693 exchanges. Supporting it requires an agreed issuer\/API profile and enforcement implementation. Structured authorization is useful only when the resource server understands and checks it.<\/p>\n A bearer token can be used by whoever possesses it. A signed act claim can therefore attribute a stolen token to Agent XYZ even when another party presents it.<\/p>\n Sender-constrained tokens address that problem by requiring proof of possession of an associated key. RFC 9700 recommends these alongside audience restrictions.<\/p>\n RFC 9449, DPoP<\/strong>, provides application-layer sender constraint. The client supplies signed proofs, and the recipient validates the proof and its relationship to the access token.<\/p>\n DPoP proofs include request method and URI information, token binding through ath for protected-resource requests, and freshness\/replay controls. But DPoP does not<\/strong> ordinarily bind the business request body or establish Lisa\u2019s approval of its contents.<\/p>\n A legitimate\u2014or compromised\u2014agent holding the bound key can still generate proofs for operations its token permits. Sender constraint prevents a different presenter from simply replaying the token; it does not make the authorized presenter trustworthy.<\/p>\n A practical task-bound delegation design<\/strong><\/p>\n For the Lisa\/Agent XYZ scenario, I would implement the following:<\/p>\n This is a proposed deployment architecture combining token exchange, constrained access tokens, and fine-grained authorization\u2014not a claim that RFC 8693 implements these controls automatically.<\/p>\n The takeaway<\/strong><\/p>\n Token exchange can turn verified credentials into a token trusted by another system. It must not turn identity evidence into unrestricted authority.<\/strong><\/p>\n For the threat in question, insist on four distinct properties:<\/p>\n \u201cAgent XYZ acting for Lisa\u201d explains attribution. \u201cAgent XYZ may perform this operation on this resource for Lisa\u201d is the authorization boundary.<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":" An agent presents two credentials: one representing me and one identifying Agent XYZ. A token service returns an access token stating that Agent XYZ is acting on my behalf. What prevents the agent from taking that token somewhere I never authorized? Not the actor claim alone. Secure delegation requires verified input credentials, controlled issuance, restricted …<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2243],"tags":[2246,1488,2244,2216],"class_list":["post-12634","post","type-post","status-publish","format-standard","hentry","category-spiffe","tag-agent-identity","tag-oauth","tag-spiffe","tag-spire"],"_links":{"self":[{"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/posts\/12634","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=12634"}],"version-history":[{"count":1,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/posts\/12634\/revisions"}],"predecessor-version":[{"id":12635,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/posts\/12634\/revisions\/12635"}],"wp:attachment":[{"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=12634"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=12634"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=12634"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
\n\n
\n Boundary<\/strong><\/td>\n Required decision<\/strong><\/td>\n<\/tr>\n<\/thead>\n\n \n Input trust<\/td>\n Is this issuer permitted to supply this kind of identity evidence?<\/td>\n<\/tr>\n \n Credential validity<\/td>\n Is the token authentic, current, and acceptable in this exchange context?<\/td>\n<\/tr>\n \n Actor identity<\/td>\n Which actor does the verified credential actually identify?<\/td>\n<\/tr>\n \n Exchange eligibility<\/td>\n May this client or actor exchange this subject\u2019s credential?<\/td>\n<\/tr>\n \n Target authorization<\/td>\n May this delegation reach the requested API?<\/td>\n<\/tr>\n \n Permission authorization<\/td>\n Which requested operations may the output token permit?<\/td>\n<\/tr>\n \n Output binding<\/td>\n Must the resulting token be bound to a particular presenting key?<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n \n
\n
\n
\n
\n
\n