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

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

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 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 Section 6.3).¶

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 (Section 6.1) 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 (Section 6.3). How a Workload Identity Provider 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 Workload Identity Provider and Authorization Server: an administrator of the Authorization Server creates a Workload Identity Provider registration (Section 2), which records the Workload Identity Provider'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 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 (Section 6.2).¶

      Platform                    Authorization               Resource
      (Workload Identity          Server (AS)                 Server (RS)
       Provider; Agents)
            |                          |                          |
  (1)  [administrator registers the Workload Identity Provider]   |
            |                          |                          |
  (2)  [Platform creates Agent; nothing sent to AS or RS]         |
            |                          |                          |
  (3)       |--- POST /token --------->|                          |
            |    grant_type=jwt-bearer |                          |
            |    assertion=<WAG>       |                          |
            |    resource=<RS>         |                          |
            |<-- access token ---------|                          |
            |--- request + access token ------------------------->|

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 Workload Identity Provider, 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 Workload Identity Provider 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 Workload Identity Provider 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).¶

6. 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 Section 6.3). 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 [RFC7591] and yields no client identifier or credential.¶

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 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 ([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.¶

• 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 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 (Section 6.1); 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 (Section 6.3) 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.¶

• Error responses (Section 7) tell any presenter which Workload Identity Providers 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 ([RFC8725], Section 3.11).¶

10. IANA Considerations

This document has no IANA actions.¶

11. References

Acknowledgments

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

Authors' Addresses