Two tokens, one exchange: binding a user's consent to an attested agent workload

Two clocks mark out the trust model. In the illustrative payloads, the user's access token runs from `iat` 1770000000 to `exp` 1770000300 ^[12], five minutes of validity ^[13]. The workload's JWT-SVID from SPIRE runs to 1770000060 ^[15], sixty seconds ^[14], one fifth as long ^[16]. The human's authorization is allowed to be stale; the proof that an attested process is making the call is not. In practice that means the agent has to reach its SPIRE agent close to the moment it posts to the token endpoint, which puts workload attestation on the request path rather than in startup configuration.

The refusal is the interesting part. The caller never supplies an authoritative logical agent identity: `spiffe://example.org/agent/demo` is mapped to a configured logical agent such as `urn:agent:demo` inside the trusted policy boundary ^[18], and the actor token itself does not let the workload choose an AgentID ^[17]. So the question "which agent is this" is answered by a table in PingFederate, not by anything the agent says about itself. Whoever can edit that mapping can promote a workload into a different logical agent without touching a line of agent code.

Validation is described as two independent processors, one for the user token and one for the SVID, checking signature, issuer, audience, time, key ID and algorithm before the SPIFFE ID is mapped and a short-lived transaction JWT is issued ^[6]. The write-up is explicit that claims are only consumed after the whole token passes those checks, and that raw tokens are never written to application or audit logs ^[2], with tokens confined to the request body over validated TLS rather than URLs, log lines, audit events or error responses ^[5]. That last constraint is the one operators break first, because a redacted token is much harder to debug than a logged one.

Downstream, the user's access token stops at the exchange. It is not forwarded to the MCP gateway or to any downstream service ^[3]. What travels instead is a Txn-Token signed with ES256 and typed `txntoken+jwt` ^[19], carrying the requesting workload in `req_wl` and a transaction context naming the target, the tool `customer.read`, the logical agent and an instance ID ^[20]. The gateway's authorization decision now keys on fields that used to be telemetry. The response comes back in the ordinary OAuth token response shape ^[21], so nothing in the client transport has to change.

Read the source for what it is: a design, not a deployment record. The payloads are labelled illustrative decoded claims ^[2], the Txn-Token body carries `iat` 0 and `exp` 0 ^[20], and the text says PingFederate *should* issue the token after validating subject and actor separately ^[7]. The architectural point stands on its own, since the base Transaction Tokens profile leans on authenticated TTS clients and this design adds explicit actor evidence on top ^[11]. But nobody has shown you a policy that runs.