OAuth Actor Profile — Cross-Domain AI Agent Flow
Cross-trust-domain AI agent delegation (Appendix B of draft-mcguinness-oauth-actor-profile-00). Alice's travel-assistant agent books a trip on her behalf, with the request crossing from the enterprise trust domain into the travel-provider trust domain and then into the provider's internal service mesh. Tokens transform: ID Token → ID-JAG → Access Token → Transaction Token. Across every hop, `sub` stays Alice and the `act` claim grows a new outermost actor while preserving prior hops as inner actors. This is the actor profile's full multi-hop, multi-domain story.
Alice authenticates to the Enterprise IdP AS via a standard OIDC Authorization Code flow. The AS issues an ID Token whose `aud` is the Travel Assistant agent's client identifier. Note: the actor profile is NOT yet in play — an ID Token implicitly identifies a user and does not carry a `sub_profile` claim. The entity type for Alice will be established by the AS in the next step's issued ID-JAG.
• This is plain OIDC. No actor profile claims appear in the ID Token itself.
• The `aud` of the ID Token is the Travel Assistant's client URI — the agent is the OIDC client that initiated Alice's login.
• Appendix B §B.3 — 'An ID Token implicitly identifies a user; the entity type is not carried in a `sub_profile` claim and is established by the AS in subsequent issued tokens (Step 2).'
• The Travel Assistant will now use this ID Token as the `subject_token` in a Token Exchange to obtain an ID-JAG (Step 2).
Step 1: Authenticate → ID Token
application/x-www-form-urlencoded
as.enterprise.example
grant_type=authorization_code &code=<auth-code-after-alice-login> &client_id=https%3A%2F%2Fagents.enterprise.example%2Ftravel-assistant &redirect_uri=https%3A%2F%2Fagents.enterprise.example%2Fcb
{"alg":"RS256","typ"?:"JWT"}{"iss"?:"https://as.enterprise.example","sub"?:"https://idp.enterprise.example/users/alice","aud"?:"https://agents.enterprise.example/travel-assistant","exp"?:1743379200,"iat"?:1743375600}