Episode 174 - GluuFederation/identerati-office-hours GitHub Wiki

Title: Agentic Transaction Tokens

Channels

Short

Description

The IETF draft "Transaction Tokens for Agents" proposes an extension to the OAuth Transaction Tokens framework that addresses secure context propagation for autonomous and delegated agent workloads. It introduces actor and principal context fields into short-lived transaction tokens, enabling microservices and API call graphs to both identify the acting agent and the human or system that initiated its actions — improving traceability and authorization granularity in AI agent-driven systems. We’ll unpack real world use cases, how this fits into the evolving OAuth ecosystem, and what this means for developers building secure agentic applications that need fine-grained access control and transparent auditability.

Homework

amazon-retail-soa-cloud

Takeaways

  • ⚡ The “large service graph problem” in Service-Oriented Architecture (SOA) refers to the operational, cognitive, and governance complexity that emerges as the number of services and their interdependencies grow non-linearly. Services using OAuth token exchange to obtain a transaction token (or "TrAT" as Atul says...) is an increasingly useful pattern for SOA, especially when software crosses trust boundaries.

  • ⚡ The OAuth TrAT Best Current Practices ("BCP") draft is meant to help guide deployments... much needed as the core TrAT stanadard leaves a lot of details undefined for implementors.

  • ⚡ Transaction Tokens for Agents defines some standard claims to specify the human and agentic actors involved in a transaction. It also may include claims to support encrypted data.

  • ⚡ An enterprise can make many policies based on the contents of one TrAT, issued centrally. But will one TrAT be enough? What if a software has obtained authorization from two diffent business domains? What about information orthogonal to identity, like attestations about the trust worthiness of the hardware platform?

Livestream Audio Archive

here