]> 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. A Workload Identity Provider operated by 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 Workload Identity Provider. 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 Workload Identity Provider 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's Workload Identity Provider and naming one workload, presented at the token endpoint of an authorization server that has been configured, once, to trust that Workload Identity Provider. It specifies the grant, and that workloads are trusted based on the Workload Identity Provider registration, allowing a previously unseen workload to receive an access token. How trust in a Workload Identity Provider 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 instantiates and manages the lifecycle of workloads ("Agents"). Workload Identity Provider: the component of the Platform that issues Workload Authorization Grants. Where a provider serves several customer organizations under one issuer identifier, each customer's partition must be uniquely identified (see ). Workload Identity Provider registration: an Authorization Server's record of one Workload Identity Provider it trusts: the Workload Identity Provider's issuer identifier, its keys () and, where several Workload Identity Providers share that issuer identifier, the name of a claim and the value the claim carries for this Workload Identity Provider (). How a Workload Identity Provider 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 Workload Identity Provider and Authorization Server: an administrator of the Authorization Server creates a Workload Identity Provider registration (), which records the Workload Identity Provider'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 obtains a Workload Authorization Grant from the Workload Identity Provider and presents it in an ordinary OAuth token request. The Authorization Server matches it to a Workload Identity Provider registration, verifies it under that Workload Identity Provider's keys, allowing for previously unseen sub values, and issues an access token under its own policy ().

One-time Workload Identity Provider registration, then per-request grants | | | | |--- POST /token --------->| | | | 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 Workload Identity Provider, 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 Workload Identity Provider 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 Workload Identity Provider 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 (). Where a token type identifier is needed for a Workload Authorization Grant, the value urn:ietf:params:oauth:token-type:wag () is used; for example, a Workload Identity Provider that issues Workload Authorization Grants by token exchange would use it as requested_token_type and issued_token_type. How an Agent obtains a Workload Authorization Grant is otherwise out of scope.

JWT Syntax The typ JOSE Header Parameter () of the JWT MUST be oauth-wag+jwt (), as recommended by . A Workload Identity Provider MUST NOT use this type for any other kind of JWT. The JWT Claims Set contains:

iss

REQUIRED - The issuer identifier of the Workload Identity Provider (): 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 Workload Identity Provider asserts for this request, as in . The Authorization Server decides under its own policy which of them to grant, and MAY grant a subset ().

nickname

OPTIONAL - A human-readable nickname for the Agent, for display only and never an input to authorization (). Issuers SHOULD limit nickname to 64 characters; recipients MAY truncate it for display or ignore it.

The assertion is signed under a key configured from the Workload Identity Provider (see ) and MAY carry further claims about the Agent. See for details on how an Authorization Server advertises support for this grant. The following is a non-normative example of a JWT header and claims set, as the Agent in would present it to the ticket tracker:

Workload Identity Provider Registration Prior to presenting a WAG to an Authorization Server, an administrator registers the Workload Identity Provider at the Authorization Server. During this registration step, the Authorization Server obtains the Workload Identity Provider's issuer identifier, the issuer's key, and tenant information (see ). The Authorization Server also decides on authorization policy for the Workload Identity Provider including optionally mapping claims provided by the Workload Identity Provider 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 Workload Identity Provider registration, the Authorization Server needs to record an issuer identifier and obtain the public keys associated with that issuer. A Workload Identity Provider 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 Workload Identity Provider SHOULD publish its keys at a URL, so that keys can rotate without administrator action. On each assertion the Authorization Server finds the Workload Identity Provider 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 registrations. The Authorization Server MUST reject an assertion whose typ header is not oauth-wag+jwt (), comparing as described in , MUST reject an assertion that matches no 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 registration.

Permissions During Workload Identity Provider 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, other than nickname, that the Workload Identity Provider asserts about the Agent in the WAG. A claim is an assertion by the Workload Identity Provider, meaningful only within the context of that Workload Identity Provider, and an Authorization Server MUST NOT assume that a similarly named value from another Workload Identity Provider means the same thing. The specific claims a Workload Identity Provider provides, and what permissions an Authorization Server decides to grant are outside the scope of this document.

Permissions Example This example is non-normative. It illustrates one shape the permission decision can take.

• The Workload Identity Provider is configured to include a claim such as "roles": ["databases-team"] in its assertions.
• An administrator configures the Platform so that members of the databases team can create Agents that have that role.
• Each Authorization Server has its own concept of groups, roles, and permissions, and its administrator configures what access to grant based on a roles claim containing databases-team.
• At a ticket tracker, the role is mapped to less than the team itself has: reading tickets, and writing comments on them, in projects associated with the team.
• At a log service, the role is mapped to exactly the access the team has.
• A member of the team creates an Agent with a nickname "Database Migration helper". On its first assertion at either Authorization Server, the Agent receives an access token with the permissions mapped there, without further registration.
• A different member of the team creates an Agent with a nickname "Latency optimizer". On its first assertion it also receives an access token with the mapped permissions without further registration.

The claim names are used for illustrative purposes only. Inclusion of such claims is optional, and Workload Identity Providers may define specific claims depending on their deployment, supported access control models and ecosystem.

Multi-Tenancy In many cases, a deployment (Workload Identity Provider or AS/RS) will partition its infrastructure by customer organizations, or tenants. For the purposes of this document, a Workload Identity Provider and Authorization Server / Resource Server refers to a single partition belonging to a single organization (). A Workload Identity Provider 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 Workload Identity Provider has its own issuer identifier, the issuer identifier alone identifies the Workload Identity Provider and nothing further in this section applies. Where several Workload Identity Providers 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 Workload Identity Provider registration includes the claim and the value it carries for that Workload Identity Provider, 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 Workload Identity Provider 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 Workload Identity Provider is not trusted or the Agent holds no permission for the request; or the Platform, if the assertion is invalid. An untrusted Workload Identity Provider 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.

Authorization Server Metadata An Authorization Server that publishes metadata SHOULD include the value urn:ietf:params:oauth:grant-profile:wag () in its authorization_grant_profiles_supported metadata parameter (). An Authorization Server that includes this value MUST also include urn:ietf:params:oauth:grant-type:jwt-bearer in grant_types_supported. The following is a non-normative example of Authorization Server metadata advertising support for this specification:

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.
• 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 Workload Identity Provider 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.
• Workload Identity Providers 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 Workload Identity Provider registration for a shared issuer identifier that names no claim trusts every Workload Identity Provider under it.
• Where one Authorization Server serves several organizations, a Workload Identity Provider registration created by the wrong organization routes another organization's Agents to it; who may register a given Workload Identity Provider is out of scope.
• The nickname claim is free text set at the Platform: it is not unique, can change, and can imitate another Agent or a person, including with visually similar characters. It MUST NOT be used in an authorization decision or as an identifier, by the Authorization Server or by any party it passes the nickname to; says what identifies an Agent.
• Error responses () tell any presenter which Workload Identity Providers an Authorization Server trusts, and error_uri hands a link to an unauthenticated presenter.

IANA Considerations

Media Types This section registers oauth-wag+jwt, a new media type in the "Media Types" registry in the manner described in . It can be used to indicate that the content is a Workload Authorization Grant.

OAuth URI Registration This section registers urn:ietf:params:oauth:token-type:wag in the "OAuth URI" subregistry of the "OAuth Parameters" registry .

• URN: urn:ietf:params:oauth:token-type:wag
• Common Name: Token type URI for a Workload Authorization Grant
• Change Controller: IETF
• Specification Document: This document

This section registers urn:ietf:params:oauth:grant-profile:wag in the "OAuth URI" subregistry of the "OAuth Parameters" registry , for use in the authorization_grant_profiles_supported metadata parameter ().

• URN: urn:ietf:params:oauth:grant-profile:wag
• Common Name: Authorization grant profile identifier for a Workload Authorization Grant
• Change Controller: IETF
• Specification Document: of this document

References Normative References This second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS-TRACK] 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] This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. 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. This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. IANA IANA 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 OAuth 2.0 Token Exchange (RFC 8693) and the JWT Profile for OAuth 2.0 Authorization Grants (RFC 7523). 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.