Proposal: Workload/Agent Identity SSO and Explicit Delegated “On-Behalf-Of” Access

[mcguinness]

Proposal: Workload /Agent Identity SSO and Explicit Delegated “On-Behalf-Of” Access

Objective

Extend the OAuth Identity Assertion JWT Authorization Grant (ID-JAG) specification so that:

1. The IdP Authorization Server (AS-A) can, by policy, determine how identity and delegation are represented when minting an ID-JAG for a Resource Authorization Server (AS-B).
2. The ID-JAG defines a common JWT assertion format used between authorization servers to convey identity and delegation context, regardless of which identity or delegation model is used.

This proposal enables:

• Workload/Agent Identity SSO — a service or autonomous agent authenticating as itself across authorization domains
• Delegated “On-Behalf-Of” Access — a client, workload, or AI agent acting using a user’s authority
• A uniform JWT-based assertion format between Resource Authorization Server and IdP Authorization Server that works across all models

The extension:

• Preserves the existing OAuth user delegation model
• Makes delegation explicit when supported
• Enables workload identity and future actor chains
• Allows backward compatibility for Resource AS that only understand traditional user delegation assertions
• Introduces no new JWT claim registrations
• Normatively depends on OAuth Entity Profiles
• Reuses the RFC 8693 act claim for explicit delegation
• Supports IETF WIMSE Workload Identity Credentials as an input actor credential format

Identity & Delegation Models the IdP May Apply

The existing specification supports the widely deployed implicit delegation model of a client acting on behalf of a user. The sub claim of the ID-JAG always represents a user and the client_id is the application registered in the Resource Authorization Server that is acting on behalf of the user.

This extension does not replace that model but provides the following:

• Preserves the implicit model for compatibility
• Allows delegation to be made explicit using act claim
• Adds support for workloads or AI agents acting independently

When issuing an ID-JAG for a Resource Authorization Server, the IdP Authorization Server selects the delegation model and identity mapping based on what the client provided and IdP Authorization Server defined policy.

Model	Meaning	ID-JAG Representation	Resource Authorization Server Compatibility
Client Acting as User (Existing OAuth Model)	Client acts for user (implicit)	sub = user	Existing delegation model that is widely deployed today
Explicit User Delegation	Client/workload explicitly shown as actor	sub = user, act = client/workload	Requires actor-aware Resource Authorization Server
Workload or Agent Acting as Itself (Workload SSO)	No user involved	sub = workload or sub = ai-agent	Requires workload or AI-agent-aware Resource Authorization Server
Compatibility Mapping	Workload translated to legacy identity	Policy-mapped identity	For legacy Resource Authorization Server only

1. ID-JAG as the Common JWT Assertion Between Authorization Servers

ID-JAG defines a common JWT assertion format used between authorization servers to convey identity and delegation context.

Regardless of identity model:

• Resource Authorization Server validates a single JWT structure
• Identity semantics (user, workload, AI-agent, delegation) are conveyed within the same assertion
• Resource Authorization Server relies on IdP Authorization Server policy for identity composition and delegation enforcement

This establishes a stable federation boundary while allowing identity semantics to evolve.

2. Normative Dependencies

The draft adds normative references to:

• OAuth Entity Profiles
• IETF WIMSE Workload Identity Credentials

ID-JAG adds support for the following existing claims from Entity Profiles:

• sub_profile
• client_profile

IdP Authorization Server publishes additional Authorization Server metadata:

• entity_profiles_supported

No new claim registrations are introduced.

3. IdP Policy Determines ID-JAG Structure

During Token Exchange, IdP Authorization Server evaluates:

• Target audience (aud = Resource Authorization Server) to determine the trust relationship, token requirements, and delegation model
• Supplied credentials (user token, workload token, or both)
• Delegation grants and enterprise policy
• Resource Authorization Server capability profile

Support for WIMSE Workload Credentials

When a workload presents an actor credential conforming to the WIMSE Workload Identity Credentials specification, the IdP Authorization Server:

• MAY accept the WIMSE credential as an actor_token in a Token Exchange request
• Validates the credential according to WIMSE processing rules and local trust policy
• Derives the workload identity used in the act claim or sub claim (for workload SSO)

This enables interoperable workload identity federation using a standardized workload credential format.

The IdP Authorization Server then selects the appropriate identity model and issues an ID-JAG that reflects the selected delegation model and context.

A. Existing User Delegation (Implicit Model)

sub = user
sub_profile = user
(no act claim)

Maintains full backward compatibility.

B. Explicit Delegation (Modern On-Behalf-Of)

sub = user
sub_profile = user
act.sub = client/workload
act.sub_profile includes "service" or "ai-agent" (if non-user)

Makes delegation visible and enforceable.

C. Workload Identity SSO (Acting as Self)

sub = workload
sub_profile includes "service" or other non-user profile

Enables cross-domain workload SSO.

D. Agent Identity SSO (Acting as Self)

sub = ai-agent
sub_profile includes "ai-agent"

Enables cross-domain AI agent SSO.

E. Compatibility Mapping

IdP Authorization Server maps identities into a representation Resource Authorization Server understands when native workload, AI-agent, or actor support is absent.

Mapping is policy-controlled, not client-controlled.

4. Resource AS Processing Rules

Resource Authorization Server processes the same ID-JAG assertion format in all cases.

Condition	Resource Authorization Server Behavior
act present	Perform dual-principal authorization
No act, sub_profile=user	Standard user authorization
No act, sub_profile=service	Workload acting as self
No act, sub_profile=ai-agent	AI agent acting as self
Compatibility mapping	Process as normal legacy identity

5. Access Token Issuance

Resource Authorization Server issues tokens preserving the identity model expressed in the ID-JAG.

Permissions must be the intersection of:

• User rights (if present)
• Workload/Agent rights
• Delegation grants
• Requested scope/resource
• Requested Authorization Details

6. Sender-Constraining Guidance

Scenario	Recommendation
Existing OAuth user model	Existing guidance applies
Explicit delegation (act)	SHOULD use sender-constrained tokens
Workload acting as self	SHOULD use sender-constrained tokens
Compatibility mapping	SHOULD use sender-constraining if workload-originated

7. Metadata and Discovery

No new ID-JAG metadata is defined.

Authorization Servers supporting this extension SHOULD publish:

entity_profiles_supported

IdP Authorization Server maintains internal policy describing Resource Authorization Server capability levels.

8. IANA Impact

None.

• No new JWT claim registrations
• No new registries
• Reuses Entity Profiles and RFC 8693 act

Final Outcome

Goal	How It Is Achieved
Preserve existing OAuth delegation	Keep implicit user model unchanged
Support workload or AI Agent identity SSO	sub_profile indicates service or ai-agent
Support delegated on-behalf-of access	sub = user + act = workload
Provide common AS-to-AS assertion	ID-JAG JWT assertion format
Support legacy systems	IdP compatibility mapping
Enable future actor chains	Policy-driven evolution
Keep single client interface	IdP decides representation per AS
Avoid new claims	Reuse Entity Profiles + act

This extension establishes ID-JAG as a common JWT assertion format between authorization servers, enabling both workload identity SSO and delegated user access while remaining fully backward compatible.

[alperdedeoglu]

modelcontextprotocol/modelcontextprotocol#214 also worth mentioning.

[dschenkelman]

I like this idea :P

some comments:

Intro

• worth calling out in table that Client Acting as User (Existing OAuth Model) has delegation in azp/client_id even if not implicit (and repeat across table)?
• in "Workload or Agent Acting as Itself (Workload SSO)" I think "Requires workload or AI-agent-aware Resource Authorization Server" is not how'd I think about it. XAA is very good at duck typing. AS knows that if you get a token from a trusted signer and knows the sub, it will issue. it does not care about agents or workloads, or anything. the notion of trusted signature providers ("trust policy") might be more valuable imo, where the population of entities in the AS is in there

Section 3

Target audience (aud = Resource Authorization Server) to determine the trust relationship, token requirements, and delegation model
audience alone might not be enough for this. a notion of tenancy in the aud is required imo. this is not specific to agent/workload identity, just general

Make C. Workload Identity SSO (Acting as Self) a subtype of current model and closer to A.? Make it clear that it is the same thing and show the power of XAA duck typing :). Why do we differentiate C and D? I am not sure I'd catalog something as "ai agent" vs "workload" or not (beyond this spec). Some people think of agents as multiple workloads/clients, it is complicated. I would stick to workload. Moreover, agent makes it sound like it is acting one someone's behalf, but case D. is its own behalf.

The comment about propagating client_id/azp here applies. For single delegation chains the delegation is fairly obvious in the current mode.

Explicit delegation for chaining becomes useful in multi chains, so separate the single chain cases first imo

can you explain "Compatibility Mapping"?

Section 5.

Should we separate "Permissions must be the intersection of:" for the on behalf case and the for itself case? I think that would be simpler to understand

Also, not an expert on WIMSE. I'd make sure that wherever SCIM lands for agent/workload the same can be used, e.g. https://datatracker.ietf.org/doc/html/draft-abbey-scim-agent-extension-00. Discussed this with you, writing it down for other readers.