]> Anthropic

paulc@anthropic.com

OpenAI

steele@openai.com

Okta

aaron@parecki.com

Defakto Security

arndts.ietf@gmail.com

Ping Identity

bcampbell@pingidentity.com

sec agent identity workload identity workload authorization grant jwt authorization grant 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 () 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 Status information for this document may be found at . Source for this draft and an issue tracker can be found at . Note to Readers 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.

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 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.

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 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 (). Platform registration: an Authorization Server's record of one Platform it trusts: the Platform's issuer identifier, its keys () and, where several Platforms share that issuer identifier, the name of a claim and the value the claim carries for this Platform (). How a Platform registration comes to exist is out of scope (note: this is not a client registration and yields no client identifier or credential). Authorization Server, Resource Server: as in . Where an Authorization Server serves several customer organizations under one issuer identifier, each customer's partition is a separate Authorization Server ().

Overview

1. Once per Platform and Authorization Server: an administrator of the Authorization Server creates a Platform registration (), which records the Platform's issuer identifier and how to obtain its keys (). Nothing about individual Agents is exchanged.
2. Per Agent: the Platform creates an Agent and assigns it an Agent Identifier (). 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 ().

One-time Platform registration, then per-request grants | | | grant_type=jwt-bearer | | | assertion= | | | resource= | | |<-- access token ---------| | |--- request + access token ------------------>| ]]>

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 . An Authorization Server MUST associate records for an Agent with its Platform and sub value, never on its sub value alone.

Workload Authorization Grant An Agent obtains an access token by presenting a JWT as an authorization grant per , issued by the Platform as a third party in the sense of . 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 . The resource parameter 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 (). An Agent MAY make the token request without client authentication (), 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 ().

JWT Syntax

iss

REQUIRED - The issuer identifier of the Platform's issuer (): a URL using the https scheme with no query or fragment component, as for issuer in .

sub

REQUIRED - The Agent Identifier ().

aud

REQUIRED - Identifies the Authorization Server: its issuer identifier , as a single value, as in . An Authorization Server MUST accept its issuer identifier as the audience; it MAY also accept its token endpoint URL, which continues to permit for authorization grants.

exp, iat, jti

REQUIRED - As defined in .

scope

OPTIONAL - A space-separated list of scopes () the Platform asserts for this request, as in . The Authorization Server decides under its own policy which of them to grant, and MAY grant a subset ().

The assertion is signed under a key configured from the Platform (see ) and MAY carry further claims about the Agent. An Authorization Server that publishes metadata 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" }

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 ). 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 and yields no client identifier or credential.

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 entered directly, a JWK Set URL the Authorization Server fetches over HTTPS , or the jwks_uri in metadata the issuer publishes under its issuer identifier ( or ). An Authorization Server that uses issuer metadata MUST NOT use a document whose issuer value is not identical to the registration's issuer identifier (). 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 () and, where the registration names a claim (), 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 ( and ) - and MUST interpret sub and jti only within the scope of the matched Platform registration.

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.

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 (). A Platform that knows the organization's identifier at the Authorization Server can carry it in the assertion, as the aud_tenant claim of 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 (). 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 () 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.

Error Responses When a token request fails, the Authorization Server SHOULD indicate in error_description () 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 (); a missing permission yields invalid_scope or invalid_target () 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.

Open Issues

• Agent ownership: see issue #13.
• 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 (), 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 .

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 (); 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 () 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 () tell any presenter which Platforms an Authorization Server trusts, and error_uri hands a link to an unauthenticated presenter.
• 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 ().

IANA Considerations This document has no IANA actions.

References Normative References The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint; general processing rules are also specified. The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions and to provide alternative client authentication mechanisms. Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations. This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication. This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access. JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with Internet Public Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions. This document obsoletes RFC 6125. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. The OAuth 2.0 device authorization grant is designed for Internet- connected devices that either lack a browser to perform a user-agent- based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources by using a user agent on a separate device. Self-Issued Consulting Ping Identity Disney Okta This document updates RFC7521, RFC7522, RFC7523 and RFC9126 with respect to the treatment of audience values in OAuth 2.0 Client Assertion Authentication and Assertion-based Authorization Grants to address a security vulnerability identified in the previous requirements for those audience values in multiple OAuth 2.0 specifications. Okta Independent Ping Identity This specification provides a mechanism for an application to use an identity assertion to obtain an access token for a third-party API by coordinating through an identity provider that the downstream Resource Authorization Server already trusts for single sign-on (SSO), using Token Exchange [RFC8693] and JWT Profile for OAuth 2.0 Authorization Grants [RFC7523]. This pattern is informally referred to as Cross-App Access (XAA).

Acknowledgments The editors thank Pieter Kasselman, Karl McGuinness, Kevin Kelley, Emily Lauber, and Maxwell Gerber for discussions that shaped this document.