OAuth Token Exchange (RFC 8693)
OAuth Token Exchange under RFC 8693 is a procedure in which a service exchanges an existing token for a new one, for example to continue working on behalf of a user or as that user's representative.
RFC 8693 was published in January 2020. A client presents a subject_token representing the user to the authorization server and optionally an actor_token representing the acting service. The server issues a new token that, depending on the case, represents impersonation, acting as the user, or delegation, acting for the user. With delegation, the act claim names the acting party, and several act claims can be nested to form a chain.
This brings the procedure close to the requirements for AI agents: an agent receives its own token for a partial task, and the token keeps it visible who is acting for whom.
Example
An assistant receives access to a user's calendar and bookings. For the travel booking, it exchanges its token for a new one for a specialist agent, with an act claim for the assistant and a limited purpose. The booking service sees that the specialist agent acts on the user's behalf through the assistant.
How it differs
Impersonation blurs who is acting; delegation records it. A delegation chain in KYA pursues the same goal at the level of signed evidence: each level is signed by the previous one and may only narrow authority.
In practice
- Use delegation instead of impersonation, so the token keeps it visible which agent is acting.
- Limit the new token to the partial task, for example through audience, purpose and short validity.
- Also record the chain in signed evidence if third parties are to verify the hand-over later.
Role in KYA
KYA verifies delegation chains in evidence, not in OAuth tokens. The check mirrors the idea of the act claim, however: each level must be bound to the next, and no level may allow more than the previous one.
Related check: Delegation chain (delegation_provenance). Is every hop signed, connected without gaps and no broader than the previous one?
Frequently asked questions
What is the difference between impersonation and delegation?
With impersonation, the service acts as the user, and the new token does not distinguish the two. With delegation, it remains recognizable through the act claim that another party acts on the user's behalf.
What is the act claim for?
It names the acting party in a delegated token. Nested act claims form a chain showing through which stations an instruction was passed on.
Is token exchange suitable for AI agents?
Yes, for passing access between services and agents. For independently verifiable proof of authority, signed mandates and receipts are needed in addition.
Does KYA verify OAuth tokens from token exchange?
No. KYA verifies delegation chains in evidence such as mandates. The logic is comparable: binding to the next level and narrowing authority further down.