Workload Authorization Grant

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 4 February 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Agent platforms increasingly host many agent instances per customer, created and retired at the cadence at which the customer organizes its work -- per channel, repository, or pipeline. An individual agent may persist for weeks or months, but the person creating it is typically not the person authorized to provision credentials at the resource servers it will access. Per-agent credentials are therefore not issued in practice, and deployments collapse to a single credential shared across all agents of an installation -- the pattern [AIMS], Section 7, identifies as an antipattern -- at the cost of any attribution of an individual agent's actions at the resource server.¶

Existing workload identity federation [WIMSE-ARCH] addresses an analogous problem between an organization's workloads and infrastructure providers, but its claim and policy semantics are defined per provider rather than portably, and it has not been applied between agent platforms and SaaS resource servers. The Model Context Protocol's proposed Workload Identity Federation extension [MCP-WIF] defines the corresponding wire mechanics for MCP servers; this profile is intended to be interoperable with it.¶

This document specifies a profile of [AIMS] for that deployment pattern. Agent platforms are the motivating deployment, and the terminology throughout uses "Agent"; the mechanism itself is not agent-specific and applies to any platform hosting workloads that need federated access to third-party resource servers. The mechanism is called the Workload Authorization Grant (WAG): a platform-signed JWT authorization grant asserting a workload's identity and platform-asserted properties. Trust in the platform's issuer is established once, by reference, and thereafter agents are accepted on first presentation with no per-agent registration step.¶

A design goal of this profile is a minimal adoption path for services that already operate an OAuth deployment: supporting it requires changes only at the authorization server's token endpoint, which accepts the JWT authorization grant from allowlisted issuers. The access tokens the authorization server issues are unchanged in format and semantics, and resource servers continue to trust their authorization server exactly as they do today.¶

2. Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

Agent Platform ("Platform"):

The service that hosts Agents and operates the per-tenancy issuers that vouch for them.¶

Agent:

A hosted workload with its own Agent Identifier, context, and configuration.¶

Agent Property:

A Platform-asserted attribute carried as a claim in the authorization grant.¶

Authorization Server (AS):

The OAuth authorization server at which Agents present authorization grants and obtain access tokens; commonly, but not necessarily, operated by the same vendor as the Resource Server it protects.¶

Resource Server (RS):

The service holding customer resources, accessed with the access tokens the Authorization Server issues.¶

Enterprise IdP:

The customer's identity provider (optional).¶

Customer Administrator:

The human who performs one-time trust establishment.¶

3. Deployment Model

TODO: diagram. One-time trust establishment by the Customer Administrator (Section 6); agent creation by end users with no interaction with the Resource Server (Section 7); per-request JWT authorization grant (Section 5).¶

4. Agent Identity Model

An Agent's identity has three units: the tenancy's issuer, which signs assertions about the Agent; the Agent Identifier, opaque, unique within the issuer, immutable, and never reassigned, carried as the assertion's sub (Section 5); and claims, carrying everything else (Section 8). Renaming an Agent MUST NOT change its Agent Identifier. Resource Servers MUST NOT parse or pattern-match the Agent Identifier for authorization; single-agent policy is an exact match on it.¶

The Agent Identifier MAY be, and is RECOMMENDED to be, a Workload Identifier URI [WIMSE-ID] with an opaque path; a bare opaque string is also permitted. URI form costs no opacity -- the path remains meaningful only to the issuing Platform -- and carries the trust boundary inside the identifier's authority component, which is what relying parties that evaluate only subject and audience need (Section 11). When the Agent Identifier is a URI, the Authorization Server validates its authority component against the allowlisted issuer's tenancy once, at token issuance; Resource Servers treat the complete identifier as an opaque, exact-match string regardless of form and MUST NOT derive trust from its components.¶

5. Authorization Grant

The Agent obtains access tokens from the Authorization Server by presenting a JWT as an authorization grant per [RFC7523], Section 2.1, issued by the Platform as a third party in the sense of [RFC7521], Section 3. The token request carries grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer, the JWT in the assertion parameter, and the target resource in the resource parameter [RFC8707]. This profile deliberately does not specify the OAuth client identity or attach semantics to client_id. In the simplest deployment the token request is made without client authentication. Deployments MAY layer client authentication on top -- for example, the Platform authenticating as an OAuth client in its own right with a Client ID Metadata Document [CIMD] and a private_key_jwt client assertion -- a composition that becomes natural when the authorization grant's issuer is the customer's Enterprise IdP rather than the Platform (obtained, e.g., by token exchange [RFC8693] with the IdP). This document intentionally leaves that composition open rather than fully specifying it (Section 11).¶

POST /token HTTP/1.1
Host: as.saas.example
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&assertion=eyJhbGciOiJFUzI1NiIsImtpZCI6IjIwMjYtMDctMTQi...
&resource=https%3A%2F%2Fapi.saas.example%2F

{
  "iss": "https://acme.agents.platform.example",
  "sub": "wimse://acme.agents.platform.example/agent/7f3d9a2e",
  "aud": ["https://as.saas.example",
          "https://as.saas.example/token"],
  "exp": 1785271980,
  "iat": 1785271680,
  "jti": "7d0f5a2b-93c8-4f0e-9c33-1b6a0e6d5f10",
  "name": "Support Triage Agent",
  "namespace": "acme/support",
  "groups": ["support-eng"],
  "roles": ["responder"],
  "ctx": "channel:C0123456789"
}

6. Trust Establishment

The Customer Administrator once records, at the Authorization Server, an allowlist entry binding one issuer to one tenancy: the issuer identifier, from which the issuer's metadata and JWK Set location are discovered per [OIDC-DISCOVERY] (retrieved over https [RFC9525]), and the tenancy's initial Property-to-permission mapping for the Resource Server (Section 8). Establishment is by reference; no keys or secrets are transferred, and key rotation is by JWK Set update alone. Platforms serving multiple customers MUST use a distinct issuer per tenancy: the issuer is the trust boundary the allowlist expresses, and a shared issuer would move tenancy enforcement into claim evaluation at every Authorization Server -- including relying parties that can evaluate only subject and audience (Section 11). The proposed MCP Workload Identity Federation extension [MCP-WIF] recommends (SHOULD) that authorization servers rely only on issuing keys bound to a single tenant; this profile deliberately tightens that boundary to a per-tenancy issuer MUST.¶

Multi-issuer operation is scoped by issuer throughout. An Authorization Server MUST resolve and cache keys per allowlist entry and MUST NOT merge key sets across issuers, and it MUST interpret sub and jti only within the scope of the presenting iss. A Resource Server that keeps a Property-to-permission mapping (Section 8) likewise scopes it by iss. An Agent Identifier is unique within its issuer, not globally: policy and audit records are keyed on the (iss, sub) pair, or on the complete URI-form identifier, which carries the tenancy in its authority component.¶

7. Agent Instantiation

Creating an Agent is Platform-internal and MUST NOT require any ahead-of-time interaction with the Resource Server, the Authorization Server, an Enterprise IdP, or the Customer Administrator. The Authorization Server first learns that an Agent exists when the Agent presents its first authorization grant: it MUST accept a previously-unseen Agent Identifier presented as sub under an allowlisted issuer, and authorization -- at the Authorization Server and the Resource Server alike -- is via Section 8, never identifier structure. Agents are not dynamically registered clients [RFC7591].¶

Optionally, a Platform MAY project Agents into an Enterprise IdP (e.g., as [SCIM-AGENT] resources) for inventory and lifecycle governance. Such projection MUST NOT be required ahead of time: performing it just in time, including synchronously during first token issuance, is acceptable. TODO: BYO-IdP deployment model.¶

8. Agent Properties and Authorization

TODO. Initial standard property claims: name, a human-readable display name as in an OpenID Connect ID Token [OIDC-CORE] (mutable, and never a key for authorization or attribution -- that is the Agent Identifier); namespace, groups, roles, and an optional ctx naming the collaboration context; additional attributes use collision-resistant claim names per [RFC7519], Section 4.3. TODO: whether an Agent needs a human-usable, "@"-referenceable address within the Platform, analogous to sharing a document with an email address, distinct from both name and the opaque Agent Identifier; noted here, deliberately unsolved. A Resource Server keeps a local, administrator-controlled mapping from Property predicates to permissions; possession of a Property is not itself authorization. Deny semantics do not travel. TODO: worked example.¶

9. Attribution

TODO. The Authorization Server logs jti at token issuance; Resource Servers log the Agent Identifier (sub) and referenced Properties; internal fan-out via [TXN-TOKENS] rather than forwarding the access token.¶

10. Retirement and Lifecycle

Retirement is expressed by cessation: the Platform stops signing assertions for a retired Agent, so residual access is bounded by the remaining lifetime of any outstanding assertion plus the lifetime of any access token already issued. Assertion and access-token lifetimes SHOULD be chosen with this bound in mind. No signal yet informs an Authorization Server that an Agent Identifier is permanently retired; that gap is shared with neighboring workload identity ecosystems, whose common baseline is likewise short credential lifetimes plus ceasing issuance (Section 11).¶

Broader lifecycle management is out of scope for this document. In particular, resources that come to be owned by an Agent (documents, records, long-lived artifacts) need succession planning when the Agent is retired; this profile makes the retirement event's access consequences legible, but does not manage its downstream effects.¶

11. Open Issues

• Relying parties that authorize only on subject and audience (e.g., cloud IAM federation trust policies) and cannot evaluate Property predicates; URI-form Agent Identifiers (Section 4) carry the tenancy inside the identifier for this case, but the residual gap is unassessed.¶

• Proof-of-possession: the authorization grant is bearer; see Section 5.¶

• Issuer placement: issuer operated by the Platform versus by the Enterprise IdP, with the Platform obtaining assertions by token exchange [RFC8693] with the IdP; client authentication is redundant in the former case and load-bearing in the latter; what, if anything, client_id means in each case.¶

• Staleness and retirement signaling in place of per-agent revocation (issuer- or Property-scoped epoch versus event push versus lifetime alone, Section 10); a gap shared with neighboring workload identity ecosystems.¶

• Addressing: whether an Agent needs a human-usable, "@"-referenceable address (to share a resource with an agent the way one shares with an email address), distinct from the display name and the Agent Identifier.¶

12. Security Considerations

TODO: unseen agent identifiers under trusted issuers; issuer allowlist as the trust boundary; tenant confusion at multi-issuer Authorization Servers (Section 6); bearer-assertion theft and assertion lifetime; Platform as root of trust; credential non-exposure to the model; automated trust establishment.¶

13. IANA Considerations

This document has no IANA actions at this time; provisional claim names (Section 8) may be registered in a future revision.¶

14. References

Acknowledgments

The author thanks Kevin Kelley, Aaron Parecki, Brian Campbell, Pieter Kasselman, Nick Steele, Emily Lauber, and Maxwell Gerber for discussions that shaped this document. This profile builds directly on the Agent Identity Management System framework [AIMS] and would not exist without it. Further acknowledgments will be added in a future revision.¶

Author's Address