Network Working Group P. Carleton, Ed. Internet-Draft Anthropic Intended status: Informational N. Steele Expires: 26 March 2027 OpenAI A. Parecki Okta A. Schwenkschuster Defakto Security B. Campbell Ping Identity 22 September 2026 Workload Authorization Grant draft-carleton-workload-authz-grant-01 Abstract This document defines the Workload Authorization Grant (WAG), by which a workload hosted on a platform -- an AI agent is the motivating case -- obtains access tokens from a third party's OAuth authorization server without requiring an administrator to perform a per-workload provisioning step. Each workload is identified by an opaque identifier that is never reassigned. The platform signs a JWT authorization grant ([RFC7523]) that names one workload, and the workload presents it at the token endpoint of an authorization server that has been configured, once, to trust that platform. The authorization server does not reject a workload because it has not seen it before. The workload's access is determined by the authorization server's own policy, which may consult claims the platform asserts about the workload. This document covers workloads acting on their own behalf. Access on behalf of a user or other principal is out of scope, though the grant is intended to compose with delegation mechanisms in which the workload is the actor. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-carleton-workload-authz- grant/. Source for this draft and an issue tracker can be found at https://github.com/pcarleton/draft-carleton-workload-authz-grant. Note to Readers Carleton, et al. Expires 26 March 2027 [Page 1] Internet-Draft WAG September 2026 This note is to be removed before publishing as an RFC. This document is an early, exploratory individual draft, published to solicit discussion of the deployment pattern it describes. It is not a working group document, does not describe a shipped or committed design, and does not represent a position or roadmap of the editors' employers. Every aspect of it is subject to change or withdrawal, including whether this mechanism should be specified in a separate document at all. Issues and pull requests: https://github.com/pcarleton/draft-carleton-workload-authz-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 26 March 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Agent Identity . . . . . . . . . . . . . . . . . . . . . . . 5 Carleton, et al. Expires 26 March 2027 [Page 2] Internet-Draft WAG September 2026 5. Workload Authorization Grant . . . . . . . . . . . . . . . . 5 5.1. JWT Syntax . . . . . . . . . . . . . . . . . . . . . . . 6 6. Platform Registration . . . . . . . . . . . . . . . . . . . . 6 6.1. Issuer Keys . . . . . . . . . . . . . . . . . . . . . . . 7 6.2. Permissions . . . . . . . . . . . . . . . . . . . . . . . 7 6.3. Multi-Tenancy . . . . . . . . . . . . . . . . . . . . . . 8 7. Error Responses . . . . . . . . . . . . . . . . . . . . . . . 8 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction Agent platforms host many agents per customer, instantiated and torn down as appropriate for the context of the customer's work environment -- one per channel, repository, or pipeline. Registering each agent individually at the Authorization Servers it uses is impractical and creates a heavy maintenance burden. In practice every agent of an installation ends up sharing one credential, at the cost of any attribution of an individual agent's actions. A platform that hosts many workloads -- an agent platform is a motivating case -- needs each workload to obtain an access token at third-party services without requiring an administrator to perform a per-workload provisioning step. This document defines one grant for that: a JWT authorization grant [RFC7523] signed by the platform and naming one workload, presented at the token endpoint of an authorization server that has been configured, once, to trust that platform. It specifies the grant, and that workloads are trusted based on the platform registration, allowing a previously unseen workload to receive an access token. How trust in a platform is established and what a workload may do are left to deployments. Carleton, et al. Expires 26 March 2027 [Page 3] Internet-Draft WAG September 2026 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. Platform: the party that creates workloads ("Agents") and signs assertions about them; the sending end of one trust relationship with an Authorization Server. Where a provider serves several customer organizations under one issuer identifier, each customer's partition is a separate Platform (Section 6.3). Platform registration: an Authorization Server's record of one Platform it trusts: the Platform's issuer identifier, its keys (Section 6.1) and, where several Platforms share that issuer identifier, the name of a claim and the value the claim carries for this Platform (Section 6.3). How a Platform registration comes to exist is out of scope (note: this is not a client registration [RFC7591] and yields no client identifier or credential). Authorization Server, Resource Server: as in [RFC6749]. Where an Authorization Server serves several customer organizations under one issuer identifier, each customer's partition is a separate Authorization Server (Section 6.3). 3. Overview 1. Once per Platform and Authorization Server: an administrator of the Authorization Server creates a Platform registration (Section 2), which records the Platform's issuer identifier and how to obtain its keys (Section 6.1). Nothing about individual Agents is exchanged. 2. Per Agent: the Platform creates an Agent and assigns it an Agent Identifier (Section 4). Nothing is sent to the Authorization Server or the Resource Server. 3. Per access: the Agent presents a Workload Authorization Grant in an ordinary OAuth token request. The Authorization Server matches it to a Platform registration, verifies it under that Platform's keys, allowing for previously unseen sub values, and issues an access token under its own policy (Section 6.2). Carleton, et al. Expires 26 March 2027 [Page 4] Internet-Draft WAG September 2026 Platform Authorization Resource (issuer; Agents) Server (AS) Server (RS) | | | (1) [administrator creates a Platform registration] | | | | (2) [Platform creates Agent; nothing sent to AS or RS] | | | | (3) |--- POST /token --------->| | | grant_type=jwt-bearer | | | assertion= | | | resource= | | |<-- access token ---------| | |--- request + access token ------------------>| Figure 1: One-time Platform registration, then per-request grants 4. Agent Identity An Agent is identified by its Agent Identifier, carried as the sub claim in the assertion. The Agent Identifier is opaque and immutable; it MUST be unique among all Agent Identifiers issued under the same Platform, MUST NOT be reassigned to a different Agent, and is compared as a case-sensitive string [RFC7519], Section 2. An Authorization Server MUST associate records for an Agent with its Platform and sub value, never on its sub value alone. 5. Workload Authorization Grant An Agent obtains an access token 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]. The resource parameter [RFC8707] is RECOMMENDED; an Authorization Server SHOULD restrict the audience of the access token it issues to that resource and MAY refuse a request that lacks it with invalid_target ([RFC8707], Section 2). An Agent MAY make the token request without client authentication ([RFC7523], Section 3.1), and this specification attaches no meaning to client_id. An Authorization Server MUST NOT require a client registration per Agent. Assertions SHOULD be short-lived. The Authorization Server MUST NOT issue refresh tokens for this grant and SHOULD NOT issue access tokens that outlive the assertion by a significant period ([RFC7521], Section 4.1). Carleton, et al. Expires 26 March 2027 [Page 5] Internet-Draft WAG September 2026 5.1. JWT Syntax iss REQUIRED - The issuer identifier of the Platform's issuer (Section 6.1): a URL using the https scheme with no query or fragment component, as for issuer in [RFC8414], Section 2. sub REQUIRED - The Agent Identifier (Section 4). aud REQUIRED - Identifies the Authorization Server: its issuer identifier [RFC8414], as a single value, as in [IDJAG], Section 3.1. An Authorization Server MUST accept its issuer identifier as the audience; it MAY also accept its token endpoint URL, which [RFC7523BIS] continues to permit for authorization grants. exp, iat, jti REQUIRED - As defined in [RFC7519]. scope OPTIONAL - A space-separated list of scopes ([RFC6749], Section 3.3) the Platform asserts for this request, as in [IDJAG], Section 3.1. The Authorization Server decides under its own policy which of them to grant, and MAY grant a subset ([IDJAG], Section 4.4.1). The assertion is signed under a key configured from the Platform (see Section 6.1) and MAY carry further claims about the Agent. An Authorization Server that publishes metadata [RFC8414] SHOULD list the urn:ietf:params:oauth:grant-type:jwt-bearer grant type in grant_types_supported. { "iss": "https://acme.agents.platform.example", "sub": "agent/7f3d9as3", "aud": "https://as.saas.example", "exp": 1785271980, "iat": 1785271680, "jti": "7d0f5a2b-93c8-4f0e- 9c33-1b6a0e6d5f10", "scope": "issues:read issues:write" } 6. Platform Registration Prior to presenting a WAG to an Authorization Server, an administrator registers the Platform at the Authorization Server. During this registration step, the Authorization Server obtains the Platform's issuer identifier, the issuer's key, and tenant information (see Section 6.3). The Authorization Server also decides on authorization policy for the Platform including optionally mapping claims provided by the platform to permissions. The specifics of this registration step are outside the scope of this document. It is not a client registration [RFC7591] and yields no client identifier or credential. Carleton, et al. Expires 26 March 2027 [Page 6] Internet-Draft WAG September 2026 6.1. Issuer Keys As part of a Platform registration, the Authorization Server needs to record an issuer identifier and obtain the public keys associated with that issuer. A Platform may provide its public key via: a JWK Set [RFC7517] entered directly, a JWK Set URL the Authorization Server fetches over HTTPS [RFC9525], or the jwks_uri in metadata the issuer publishes under its issuer identifier ([RFC8414], Section 3 or [OIDC-DISCOVERY]). An Authorization Server that uses issuer metadata MUST NOT use a document whose issuer value is not identical to the registration's issuer identifier ([RFC8414], Section 3.3). A Platform SHOULD publish its keys at a URL, so that keys can rotate without administrator action. On each assertion the Authorization Server finds the Platform registration the assertion matches: iss equals the registration's issuer identifier by Simple String Comparison ([RFC7523], Section 3) and, where the registration names a claim (Section 6.3), the assertion carries that claim with the registered value. An Authorization Server MUST ensure that an assertion can match at most one of its Platform registrations. The Authorization Server MUST reject an assertion that matches no Platform registration, MUST verify the signature only under a key configured or retrieved for the matched registration's issuer identifier - never under key material or key locations carried in the assertion ([RFC8725], Section 3.8 and [RFC8725], Section 3.10) - and MUST interpret sub and jti only within the scope of the matched Platform registration. 6.2. Permissions During Platform registration, the Authorization Server sets local policy for what permissions to assign an access token given in return for a WAG. This policy MAY involve consulting claims the Platform asserts about the Agent in the WAG. A claim is an assertion by the Platform, meaningful only within the context of that Platform, and an Authorization Server MUST NOT assume that a similarly named value from another Platform means the same thing. The specific claims a Platform provides, and what permissions an Authorization Server decides to grant are outside the scope of this document. Carleton, et al. Expires 26 March 2027 [Page 7] Internet-Draft WAG September 2026 6.3. Multi-Tenancy In many cases, a deployment (Platform or AS/RS) will partition its infrastructure by customer organizations, or tenants. For the purposes of this document, a Platform and Authorization Server / Resource Server refers to a single partition belonging to a single organization (Section 2). A Platform that knows the organization's identifier at the Authorization Server can carry it in the assertion, as the aud_tenant claim of [IDJAG], Section 3.1 does; this document does not require it. Where each Platform has its own issuer identifier, the issuer identifier alone identifies the Platform and nothing further in this section applies. Where several Platforms share one issuer identifier, a claim in the assertion tells them apart. Existing issuers use different claims for this, so this document does not fix the claim's name: the Platform registration includes the claim and the value it carries for that Platform, and the Authorization Server applies both when matching an assertion (Section 6.1). An assertion that lacks the named claim, or carries another value, does not match that registration. It is RECOMMENDED that deployments use dedicated issuers for partitions. If that's not possible, it is RECOMMENDED to use the tenant claim ([IDJAG], Section 3.1) in order to simplify interoperability. How an Authorization Server determines whether a Platform needs a differentiating claim, and which, is left to be discovered out of band of this specification. 7. Error Responses When a token request fails, the Authorization Server SHOULD indicate in error_description ([RFC6749], Section 5.2) who must act: an administrator of the Authorization Server, if the Platform is not trusted or the Agent holds no permission for the request; or the Platform, if the assertion is invalid. An untrusted Platform or an invalid assertion yields invalid_grant ([RFC7523], Section 3.1); a missing permission yields invalid_scope or invalid_target ([RFC8707]) where a specific scope or resource is refused, otherwise invalid_grant. When an action can be taken to resolve the issue, the Authorization Server SHOULD include a link in error_uri. 8. Open Issues * Agent ownership: see issue #13. Carleton, et al. Expires 26 March 2027 [Page 8] Internet-Draft WAG September 2026 * Proof of possession: the grant is a bearer assertion and no client authentication is required; whether to name a hardening (sender- constrained access tokens, authenticating the presenting instance, or the Platform authenticating as a client) and which, if any, to require. * JWT type: whether to define an explicit typ for this grant ([RFC8725], Section 3.11), so that another kind of JWT signed by the same issuer for the same audience cannot be taken for it. * Replay: whether an Authorization Server is required to reject a jti it has already accepted while the assertion is still valid, or whether that stays optional as in [RFC7523], Section 3. 9. Security Considerations This revision lists the considerations it is aware of; a fuller treatment will follow. * Agents are accepted on their first assertion, so the set of acceptable Agents grows at the Platform with no action at the Authorization Server, and each new Agent creates state there; an Authorization Server can cap new Agents per Platform registration. * The assertion is a bearer credential: a short lifetime, its aud and, where the Authorization Server enforces it, single use by jti bound what a stolen assertion is worth. * Keys are held per issuer identifier, so that one issuer's key never verifies another's assertion (Section 6.1); whoever controls an issuer identifier, or the DNS name under it, controls what every trusting Authorization Server accepts. * Platforms under a shared issuer identifier share its keys, so the claim that tells them apart (Section 6.3) is only as trustworthy as the party signing for all of them, and a Platform registration for a shared issuer identifier that names no claim trusts every Platform under it. * Where one Authorization Server serves several organizations, a Platform registration created by the wrong organization routes another organization's Agents to it; who may register a given Platform is out of scope. * Error responses (Section 7) tell any presenter which Platforms an Authorization Server trusts, and error_uri hands a link to an unauthenticated presenter. Carleton, et al. Expires 26 March 2027 [Page 9] Internet-Draft WAG September 2026 * This document defines no explicit JWT type, so an issuer that signs other kinds of JWT for the same audience risks one being taken for this grant ([RFC8725], Section 3.11). 10. IANA Considerations This document has no IANA actions. 11. References 11.1. Normative References [OIDC-DISCOVERY] Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID Connect Discovery 1.0 incorporating errata set 2", December 2023, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7521] Campbell, B., Mortimore, C., Jones, M., and Y. Goland, "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521, May 2015, . [RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Carleton, et al. Expires 26 March 2027 [Page 10] Internet-Draft WAG September 2026 [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . [RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, February 2020, . [RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, . [RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, November 2023, . 11.2. Informative References [IDJAG] Parecki, A., McGuinness, K., and B. Campbell, "Identity Assertion JWT Authorization Grant", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-assertion-authz- grant-04, 21 May 2026, . [RFC7523BIS] Jones, M. B., Campbell, B., Mortimore, C., and F. Skokan, "Updates to OAuth 2.0 JSON Web Token (JWT) Client Authentication and Assertion-Based Authorization Grants", Work in Progress, Internet-Draft, draft-ietf-oauth- rfc7523bis-11, 28 April 2026, . [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015, . [RFC8628] Denniss, W., Bradley, J., Jones, M., and H. Tschofenig, "OAuth 2.0 Device Authorization Grant", RFC 8628, DOI 10.17487/RFC8628, August 2019, . Carleton, et al. Expires 26 March 2027 [Page 11] Internet-Draft WAG September 2026 Acknowledgments The editors thank Pieter Kasselman, Karl McGuinness, Kevin Kelley, Emily Lauber, and Maxwell Gerber for discussions that shaped this document. Authors' Addresses Paul Carleton (editor) Anthropic Email: paulc@anthropic.com Nick Steele OpenAI Email: steele@openai.com Aaron Parecki Okta Email: aaron@parecki.com Arndt Schwenkschuster Defakto Security Email: arndts.ietf@gmail.com Brian Campbell Ping Identity Email: bcampbell@pingidentity.com Carleton, et al. Expires 26 March 2027 [Page 12]