Skip to main content

Component: Token Exchange Service

What it is: the RFC 8693 issuer. On an allow, exchanges the presented token for a narrower, hop-scoped token with nested act claims.

What it does: never trusts that /v1/authorize was actually called first — it re-decides, and mints only against a committed audit row naming this exact hop.

Why it re-decides instead of trusting the caller: if exchange simply trusted "authorize already said yes," a caller could skip straight to exchange with a stale or fabricated claim. Re-deciding against the same pinned policy, and additionally requiring a committed audit row for this exact hop, means a token can only ever be minted for a decision that both actually happened and was actually recorded — see The delegation-chain audit model.

Why jti is single-use: a subject token can be exchanged exactly once. That's what turns "holder of a delegation token gets one tool call or one further delegation, then nothing" from a convention into a database-enforced fact — replaying the same subject token a second time is invalid_grant, not a second narrower token.