OAuth Identity Chaining, Transaction Tokens, and Human-in-the-Loop: Summer 2026 Identity Standards Recap

It might be hard to believe that summer's almost over (though my European colleagues certainly aren't complaining after one of the hottest summers ever), but school schedules and supply lists are here nonetheless. Even as many of us tried to beat the heat and hopefully enjoy a bit of time with our families, several important developments happened in the Identity standards world.

As Duende's specifications and standards expert, I'm reading draft specifications, participating in email lists, watching IETF meetings, and attending community events like the Internet Identity Workshop and the OAuth Security Workshop. My role is to distill all of that information into tools you can use and information you can act on.

So if you're coming back from summer vacation or just need to get up to speed on recent developments in identity standards, you're in the right place.

There's an enormous amount of work going on related to identity (especially agentic identity) in the IETF, OpenID Foundation, and W3C. By one count, more than 70 individual drafts are being proposed for the IETF OAuth working group alone.

A significant theme I see throughout much of that work is transacting across trust boundaries. How do we allow humans and their AI agents to access third-party services, propagate their identity and authorization context, and keep humans in the loop while they're doing this? These aren't necessarily new problems, but agentic AI has made these use cases more prevalent and the need to address them more acute.

This is by no means the only area the identity standards community is working on, but agentic use cases need solutions to these problems, and they command a significant share of the community's attention.

Today I'll discuss 3 significant milestones that occurred this summer in the identity standards community, all related to agentic use cases that cross trust domains. I'll also briefly touch on a few other specifications that I think are worth paying attention to, and try to leave you with a "syllabus" of action items.

1. OAuth Identity Chaining Reaches Proposed Standard Status

What happened: The IETF's OAuth Identity and Authorization Chaining Across Domains specification (draft-ietf-oauth-identity-chaining) received IESG approval and is now on track to become a Proposed Standard.

What it does: When a request crosses organizational or cloud trust boundaries (think of a microservice in your AWS environment calling a partner API in their Azure environment), the identity and authorization context of the original requester needs to travel with it. Without a standard mechanism, each hop is a security blind spot. The downstream service has no reliable way to know who originally initiated the request, what they were authorized to do, or whether intermediate services have expanded or narrowed those permissions.

Identity Chaining solves this by combining two existing building blocks you may already know: OAuth 2.0 Token Exchange (RFC 8693) and the JWT Profile for OAuth 2.0 Authorization Grants (RFC 7523). A client in Trust Domain A exchanges its token with its own authorization server to receive a short-lived JWT authorization grant scoped to Trust Domain B. It presents the grant to Domain B's authorization server, which validates it and issues an access token. Domain B now knows who originally authorized the request, what they were allowed to do, and that Domain A's authorization server vouched for the chain.

sequenceDiagram
    participant Client
    participant AS_A as Auth Server A
    participant AS_B as Auth Server B
    participant Resource as Resource (Domain B)

    Client->>AS_A: Token Exchange Request (Token A)
    AS_A-->>Client: JWT Authorization Grant
    Client->>AS_B: Request Token Exchange (JWT Grant)
    AS_B-->>Client: Access Token (Domain B)
    Client->>Resource: API Request (Access Token B)

Why it matters for AI agents: An AI agent pipeline is, structurally, a chain of trust-domain crossings. If your orchestration layer fires off sub-agents that call external APIs, you need to know and be able to prove that every hop in that chain was authorized by someone with the actual right to authorize it. Identity Chaining will be the standardized plumbing that makes that possible.

You can build this into an IdentityServer implementation today using our extension points (notably token exchange). Though I'm not making any official commitments today regarding if or when more formal support would be built into our products, it is something we're investigating, and we'd love to hear from you. Feel free to join our Discord and ping me - I'm joedecock. I would love to chat and exchange ideas!

2. Draft For "Human-in-the-loop" Use Cases Shared

What happened: The OAuth Transaction Authorization Challenge (draft-rosomakho-oauth-txn-challenge) was submitted to the OAuth mailing list. This draft addresses the difficult problem of keeping the human in the loop, and, while it is an early draft, it's one that I'm watching particularly closely. The use case is extremely important, and the community is very interested in this problem.

What it does: Imagine an AI agent is about to initiate a $5,000 wire transfer on your behalf. It has an access token. The API is callable. Nothing in the current OAuth machinery stops it. This draft introduces a mechanism for a protected resource to reject that request and require explicit human authorization before processing it.

The flow works like this:

1. An agent sends a request to a protected resource.
2. The resource returns a Transaction Authorization Challenge, a signed JWT that describes exactly what operation is being requested, why approval is needed, and which authorization server should handle the approval. These authorization details are expressed using Rich Authorization Requests, or RAR.
3. The agent relays the challenge to the client without modifying it. The challenge is cryptographically signed, so any tampering is detectable.
4. The client presents the challenge to the authorization server.
5. The authorization server determines the right approving party, which might be the user themselves, another resource owner, or an organizational authority, such as a compliance workflow.
6. Once approval is obtained, the AS issues an access token whose authorization details (again expressed using RAR) describe the specifically approved operation.
7. The agent retries the request with this token. The resource validates that the token covers the exact operation that was challenged.

sequenceDiagram
    participant Agent
    participant Resource as Protected Resource
    participant Client
    participant AS as Authorization Server

    Agent->>Resource: API Request
    Resource-->>Agent: Transaction Auth Challenge<br>(JWT w/authorization_details)
    Agent->>Client: Relay Challenge
    Client->>AS: Present Challenge
    AS-->>Client: Access Token (w/RAR)
    Client->>Agent: Relay Access Token
    Agent->>Resource: Retry Request (w/ Access Token)
    Resource-->>Agent: Processed Request

Why it matters for AI agents: The protected resource, not the agent or the orchestration layer, is the one asserting what requires human approval. The agent cannot describe the operation differently from how the resource signed it. This mechanism closes a real gap in current agentic systems, where "human approval" often means the agent asks a local confirmation question that the protected resource cannot verify.

Notably, this draft requires RAR (RFC 9396). If you're building systems that will need to comply with this, it's worth starting to think about how you'd model authorization details using RAR now. For the Duende community, RAR is something we're actively considering. Please add your thoughts to the feature request on our github discussions, or again, reach out on our Discord.

3. Transaction Tokens Combined With Identity Chaining Proposed

What happened: Two revisions of the Transaction Token Authorization Grant Profile (draft-fletcher-transaction-token-chaining-profile-02) were shared with the OAuth mailing this summer.

What it does: Transaction Tokens (Txn-Tokens) are short-lived, cryptographically signed JWTs that capture the full authorization context of an in-progress transaction: who initiated it, for what purpose, and with what parameters, all scoped to a single trust domain. They're the authoritative token for a request as it flows through internal services.

The problem this draft addresses: what happens when your internal service needs to call a partner service in a different trust domain to complete the transaction? You can't hand over your internal Txn-Token. It contains internal topology, credentials, and context that should never cross your organization's trust boundary.

This profile defines how to use a Txn-Token as the subject_token in a Token Exchange request. Your authorization server consumes the full internal context, applies claims minimization (stripping internal details the partner doesn't need and shouldn't see), and issues a JWT Authorization Grant carrying only what the partner's authorization server is authorized to receive. The Txn-Token itself never crosses the boundary.

The following diagram illustrates the flow described above:

sequenceDiagram
    participant Client
    participant AS_A as Auth Server A (Internal)
    participant AS_B as Auth Server B (Partner)
    participant Resource as Partner Resource
    Client->>AS_A: Token Exchange Request (Txn-Token)
    Note over AS_A: Apply Claims Minimization
    AS_A-->>Client: JWT Authorization Grant
    Client->>AS_B: Request Token Exchange (Grant)
    AS_B-->>Client: Access Token
    Client->>Resource: API Request (with Access Token)

Why it matters for developers: If you're building multi-tenant platforms, enterprise integrations, or any system where an AI agent's work spans organizational boundaries, this is the standard pattern for calling a third-party API on behalf of an internal transaction without leaking internal authorization context to the partner.

More OAuth and Identity Standards Worth Watching

Browser-Based Apps BCP is Finally Unblocked: The OAuth 2.0 for Browser-Based Applications Best Current Practice document, which provides guidance to developers on how to build secure SPAs with OAuth, has finally been submitted to the IESG for publication! The basic idea described in this specification is to pair your SPA with a server process, authenticate requests between the SPA and the server with a cookie, and perform all the OAuth protocol work on the server side. This has a number of security benefits, allows for backchannel requests to the client, and significantly reduces the risk of token exfiltration.

While final publication of this BCP has been held up by a variety of dependencies on other specifications, the core idea has been well understood and stable for a long time. We at Duende have been implementing it for years in our BFF Security Framework. To learn more about the pattern and our tooling that can help you implement it, visit our Backend for Frontend documentation.

CAEP Interop Profile Recommended By Working Group: The Shared Signals Working Group has recommended the CAEP Interoperability Profile 1.0 for approval as an OpenID Final Specification. It's in the 60-day public review period now, which runs through September 25, with the member vote following September 26 to October 10.

CAEP (Continuous Access Evaluation Profile) lets transmitters and receivers share real-time security events (a session was revoked, a device fell out of compliance, a credential changed) so access can be cut off without waiting for a token to expire. The main CAEP specification published last summer defines eight such event types, and leaves implementers a great many choices about the machinery around them. This profile constrains those choices: which endpoints a transmitter must advertise, which stream operations both sides must support, push or poll delivery, RS256 signatures, and OAuth 2.0 with ssf.read and ssf.manage scopes. I'm hopeful that this profile will improve interoperability and adoption of CAEP.

OIDF Digital Credentials Harmonized Presentation: The OpenID Foundation is standing up a new working group in collaboration with ISO, Digital Credentials Harmonized Presentation, with the first meetings held this summer. This new group's goal is to make it easier to work across the fragmented landscape of Verifiable Credential formats (SD-JWT VC, mdoc, W3C VC Data Model).

Action Items for Developers Building with OAuth and OIDC

The pattern I see across many of the summer's identity standards developments has been a focus on use cases that agentic use highlights, particularly human approval of particular transactions and managing authorization and identity context across trust boundaries.

For developers building on OAuth and OIDC today, the practical takeaways are:

• Learn Token Exchange (RFC 8693). It underpins both Identity Chaining and the Transaction Token profile. If your authorization server supports it (Duende IdentityServer does), experiment with it now.
• Revisit your SPA security posture, following the latest advice from the Browser-Based Apps BCP.
• Start modeling authorization details with RAR. The Transaction Authorization Challenge draft requires it, and more agentic patterns will follow.
• Watch CAEP if you have any scenario where "revoke access immediately" matters.

At Duende, we track these specifications closely and build support into IdentityServer as standards mature. Once again, I'd love to hear from folks who need solutions to the problems these drafts address. If you're investigating or building on top of IdentityServer, please reach out on our Discord. I'm always excited to talk about identity standards, specs, problems, and solutions.

References:

• draft-ietf-oauth-identity-chaining — OAuth Identity and Authorization Chaining Across Domains
• draft-rosomakho-oauth-txn-challenge — OAuth Transaction Authorization Challenge
• draft-fletcher-transaction-token-chaining-profile-01 — Transaction Token Authorization Grant Profile
• RFC 8693 — OAuth 2.0 Token Exchange
• RFC 9396 — OAuth 2.0 Rich Authorization Requests