]> Palo Alto Networks

sheigh@paloaltonetworks.com

Palo Alto Networks

joe@salowey.net

Zscaler

yrosomakho@zscaler.com

Security Workload Identity in Multi System Environments workload identity agent identity identifier metadata delegation This document specifies metadata attributes associated with a workload's identity that are used for auditing, authorization, accounting, and other purposes. It profiles existing claims for group membership, roles, and entitlements, with delivery either in JWT-based Workload Identity Credentials or through an authenticated workload metadata endpoint. The endpoint supports metadata retrieval for workloads using JWT-based or X.509-based credentials and disclosure according to the caller's authorization. An optional JWT claim or X.509 certificate extension identifies the metadata endpoint for the credential's subject. This document also defines the separation between identifier and metadata. It distinguishes workload attributes and durable principal associations from per-request delegation and grants such as scopes, and states the requirements that make the separation sound, including identifier uniqueness. The document applies to workloads generally, including services, batch and continuous integration jobs, serverless functions, and AI agents. Agentic use cases are discussed separately. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Workload Identity in Multi System Environments Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction An identifier denotes a workload. Metadata describes it. These are different things with different lifetimes, different authorities, and different exposure, and conflating them causes concrete harm. Deployments that need to authorize on a workload's group, role, or owner commonly encode those attributes in the identifier, producing identifiers of the form: Relying parties then parse the path and authorize on its components. This appears to work, and it is the path of least resistance because the identifier is the one field guaranteed to reach the relying party. It is nonetheless unsound, for reasons developed in : the identifier format does not promise parseable semantics, attributes and identifiers have different lifetimes, and the identifier is the most widely exposed field in the system. This document specifies the alternative. An identifier denotes the workload or workload instance selected by the deployment's identity model; attributes are carried as Workload Metadata rather than in its structure. This document profiles metadata carried in a JWT-based Workload Identity Credential, such as a WIMSE Workload Identity Token or a JWT-SVID, or retrieved from an authenticated metadata endpoint. Both delivery methods use the same metadata model and bind attributes to the complete Workload Identifier. The endpoint also supports workloads authenticated using X.509 credentials, for which this document defines no in-band metadata encoding. Either credential format can carry a reference to the metadata endpoint. Where suitable claims already exist, this document profiles them rather than defining new ones. Group, role, and entitlement claims are already registered with semantics drawn from SCIM , and delegation is already expressible . The separation between identifiers and workload attributes applies across workload types. A replicated service can change team membership without changing its identifier. A continuous integration (CI) job or a batch job can have a role independent of the worker on which it runs. A serverless function can retain its workload identifier across invocations, while a deployment requiring separate attribution can assign identifiers to individual instances. AI agents have the same needs, with additional considerations discussed in .

Scope In scope:

• the separation between identifier and metadata, and requirements enforcing it;
• metadata for workload group, role, and entitlements, and consideration of durable principal associations;
• how metadata is carried in JWT-based identity credentials or retrieved through an authenticated API;
• endpoint location, request and response formats, and authorization-dependent disclosure;
• a JWT claim and an X.509 certificate extension for identifying the metadata endpoint;
• metadata asserted by a credential issuer that exchanges credentials across trust domains;
• the identifier uniqueness requirements that the separation depends on.

Out of scope:

• the identifier format itself, which is ;
• defining new workload authentication mechanisms or selecting a mandatory-to-implement authentication binding;
• carrying metadata attributes themselves in X.509 credentials;
• independently signed metadata responses and their forwarding to other parties;
• how a relying party reaches an authorization decision from metadata;
• verification of the identity credentials, for which see , , and .

Conventions and Definitions 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. The terms Workload, Workload Instance, and Workload Identity Credential are used as defined in . Workload Identifier and Issuer are used as defined in . A workload can have multiple concurrent instances. A Workload Identifier can identify a logical workload or a particular instance, according to deployment policy; this document does not require a separate identifier for each process, replica, job, or invocation.

Workload Metadata:

Attributes of the workload or workload instance denoted by a Workload Identifier, distinct from that identifier, asserted for authorization, audit, accounting, and similar purposes.

Credential issuer:

The entity that issues a Workload Identity Credential, such as the Identity Server that issues a WIT (). It need not be the Issuer that assigns the Workload Identifier, nor the entity that determines Workload Metadata.

The Workload Identity Credentials discussed here include WIMSE Workload Identity Tokens (WITs) and Workload Identity Certificates (WICs), defined in , and SPIFFE JWT-SVIDs and X.509-SVIDs . SPIFFE refers to these objects as identity documents; this document uses "credential" throughout, consistent with WIMSE terminology.

The Separation Principle

Why Attributes Are Not Encoded in Identifiers The reasons below are independent: a solution that mitigates one still faces the others.

Path semantics are not guaranteed.

states that path contents are "deployment-specific and are interpreted according to the scheme, policy of the trust domain, as implemented by the issuer or issuers authorized for that trust domain", and requires that consumers "MUST compare and authorize Workload Identifiers using the complete URI, rather than relying only on individual components such as the path". A relying party parsing path components to recover a role depends on a trust domain's naming policy, not on anything the identifier format guarantees.

Lifetimes differ.

A Workload Identifier is stable; it is the thing audit records and authorization grants refer to over time. Attributes are mutable: a workload is reassigned to another team, its role narrows, its owner changes. Encoding a mutable attribute in a stable identifier forces a choice between two bad outcomes. Re-identifying the workload whenever an attribute changes breaks every grant and every historical audit record that named it. Leaving the identifier alone lets it assert something that is no longer true.

Cardinality multiplies.

Encoding n attributes produces an identifier space that is their cross product. Every combination of group, role, and owner becomes a distinct identifier requiring its own registration, its own grants, and its own policy entries.

Authorization becomes string matching.

Policy written against path prefixes couples authorization to a naming convention. Renaming a team silently changes who is authorized, and the coupling is invisible at both the policy and the naming end. advises consumers against exactly this, warning that prefix matching "may lead to incorrect authorization".

Exposure is maximal.

The identifier is the most widely visible field in the system. It appears in audit logs across every component on the call path, in certificate subject alternative names transmitted during TLS handshakes, and in diagnostic output. Attributes embedded there are disclosed wherever the identifier travels, which is everywhere. raises the same concern for descriptive paths generally. It is most acute for human identity; see .

Authority differs.

The authority competent to assign an identifier is not necessarily the authority competent to assert a role or a principal association. Encoding both in one string requires a single issuer to be authoritative for all of it.

WIMSE has already applied this reasoning to a narrower case. requires that where a deployment has several labels for one runtime, additional correlation "MUST NOT be encoded as a second workload identifier", directing deployments to additional claims instead. This document generalizes that reasoning from correlation data to workload attributes. PKIX addressed the same tension earlier, separating attributes from identity certificates into attribute certificates . The mechanism saw limited deployment, but the analysis holds and the separation it describes is the one specified here.

Content of the Workload Identifier A Workload Identifier MUST unambiguously denote the workload or workload instance selected by the deployment's identity model. Multiple instances MAY share an identifier when they are intended to be treated as the same service for authentication, authorization, and auditing, as specified in . A relying party SHOULD obtain the subject's group, role, or principal association from Workload Metadata rather than infer it from the identifier. If it is configured to obtain any of them from Workload Metadata, it MUST NOT infer that attribute from the identifier, even when the metadata is unavailable. Permissions and scopes are addressed in . An Issuer MAY use structured paths for administrative convenience, such as delegating naming authority within a trust domain or making identifiers readable to operators. Any such structure is defined by the trust domain's policy, not by the identifier format. A relying party SHOULD NOT base an authorization decision on part of a Workload Identifier unless that policy explicitly defines what the part means, consistent with .

Content of the Workload Identity Credential A Workload Identity Credential asserts a Workload Identifier and MAY assert Workload Metadata describing the workload or workload instance that identifier denotes. Metadata in a Workload Identity Credential is asserted by the credential issuer and inherits the credential's signature, its validity period, and its trust path. That is what distinguishes it from an attribute the workload asserts about itself at the application layer. A Workload Identity Credential MAY also identify a metadata endpoint for its subject, using the JWT claim in or the X.509 extension in . This reference locates an API; it does not itself carry the metadata returned by that API.

In-Band Metadata and API Retrieval Metadata in a JWT-based Workload Identity Credential reaches a relying party with the credential, avoiding a separate API call and a dependency on an available metadata service at decision time. However, additional claims increase token size (token bloat), are transmitted whenever that token is presented, and reflect the attributes asserted at credential issuance. This document defines no encoding for carrying these metadata claims in X.509 credentials (). Retrieval through the API in keeps metadata out of the credential, supports X.509-based deployments, and lets the service disclose different claims to different authorized callers. Attributes can be updated without reissuing credentials. Retrieval adds a network request, latency, and an availability dependency, and its freshness depends on the service's data sources (). The service can obtain metadata from stored records or derive it from authoritative information; this document does not require a separate pre-provisioned record for every workload. A deployment MAY use either method or both, for example carrying frequently used attributes in a JWT and retrieving additional attributes when needed. Claim semantics are independent of delivery; addresses differences between the assertions a relying party receives.

Workload Metadata

Reuse of Existing Claims This document does not define new claims for group, role, or permission where registered claims exist. registers groups, roles, and entitlements in the JSON Web Token Claims registry, referring for their definitions to . A Workload Identity Credential or metadata endpoint response expressing a workload's group, role, or entitlements MUST use those claims with the same meanings and value encodings.

Attribute	Claim	Source
Group membership	groups	,
Role	roles	,
Coarse entitlements	entitlements	,

Two aspects of this reuse need stating explicitly.

The subject is the workload.

motivates these claims in terms of the resource owner, citing "resource owner memberships in roles and groups" and "entitlements assigned to the resource owner", and defines them as attributes of a SCIM User. This document applies them to the subject of the Workload Identity Credential or metadata response, which is a workload or workload instance rather than a person. The registrations themselves are subject-neutral, so no conflict arises, but a relying party MUST interpret these claims as describing the workload or workload instance denoted by sub and MUST NOT interpret them as describing any associated principal ().

Value encoding is not fully determined.

defines all three as multi-valued complex attributes whose elements carry value, display, type, and primary sub-attributes. They differ in content rather than structure. specifies no vocabulary or syntax for roles and entitlements, expecting a role value to be "a String or label representing a collection of entitlements". For groups it defines canonical types "direct" and "indirect" and ties value and $ref to SCIM Group resources, which have no counterpart here. states that authorization servers "SHOULD encode the corresponding claim values according to the guidance defined in" and points to an example in which groups is an array of objects, but does not say whether an array of strings conforms. Until this is settled, credential issuers and metadata services SHOULD encode all three claims as arrays of strings, and a relying party SHOULD accept an array of objects bearing a value sub-attribute as equivalent to the array of those value strings. See item 2.

Values are otherwise trust-domain specific, and this document defines no vocabulary. A relying party MUST treat an unrecognized value as conveying no authority rather than as a wildcard.

Associated Principal A workload can have a durable association with a person, an organization, or another workload, such as an owner or operator. It can also act on behalf of a principal for a particular request. These are different relationships: an ownership or operational association does not itself confer authority to act on that principal's behalf. Some workloads operate autonomously and have no delegated principal for a request. requires each Workload Identity Credential to carry exactly one Workload Identifier, in sub for a WIT. An associated principal does not replace that identifier. The credential identifies the workload, even when a separate authorization artifact describes a delegation relationship. Applying the distinction of , per-request delegation belongs in the authorization context, such as an OAuth access token, rather than in Workload Metadata. provides mechanisms for expressing delegation in tokens. The particular access-token claims depend on the applicable authorization profile; the AI agent profile is discussed in . Whether a durable principal association is an attribute worth asserting as Workload Metadata, and how it should be represented, remains open. This document defines no claim for that association; see item 1. Where the associated principal is a person, asserting it is subject to .

Permissions and Scopes Deployments frequently want a workload's permissions in its Workload Identity Credential. This document distinguishes two cases and treats them differently, because they are not the same kind of statement. Attributes of the subject, such as group, role, and coarse entitlements, describe what the workload is. They are relatively stable, they are meaningful independent of any particular relying party, and the credential issuer is plausibly authoritative for them. These belong in the Workload Identity Credential or a metadata endpoint response per . Grants, such as scopes and fine-grained permissions, describe what the workload may do at a given resource at a given moment. They are relationship-specific, they change faster than an identity credential's lifetime, and the authority for them is the resource owner or an authorization server, not the credential issuer. Accordingly, a Workload Identity Credential MAY carry coarse entitlements per , but SHOULD NOT carry resource-specific scopes or fine-grained permissions. Where a deployment carries them anyway, a relying party MUST NOT treat them as authoritative for an authorization decision, and MUST obtain authorization from its own policy or from an authorization server. gives the reasoning. The same distinction applies to API responses. Retrieving metadata does not itself grant the target workload permission to access a resource, and the caller's permission to retrieve metadata does not confer authority to act as the target workload.

Identifier Uniqueness The separation principle depends on the identifier unambiguously denoting its subject at the granularity selected by the deployment. Where workloads intended to be separately authorized, revoked, or attributed share an identifier, metadata cannot restore the distinction: a relying party cannot establish whether workload-specific metadata describes the caller or a co-tenant. requires that issuers "MUST ensure uniqueness of all Workload Identifiers they assign"; and and advise against reassigning a retired identifier. Sharing is permitted only where the instances "are intended to be treated as the same workload for the purpose of authentication, authorization, and auditing" (). Replicas of a service can satisfy that condition; workloads requiring separate authorization or attribution do not satisfy it merely because they share an execution environment. If an identifier denotes a logical workload with multiple instances, metadata bound only to that identifier MUST describe that workload, rather than properties of one particular instance that do not apply to the others. What none of these address is the case that makes the requirement hard to meet in practice: platforms commonly issue a credential scoped to the execution environment rather than to the workload, such as an execution role assumed by every workload in a deployment, so the only subject available to a credential issuer is one shared by several workloads that require distinct identities. Therefore: A credential issuer MUST NOT use the subject of a platform-provided execution credential as a Workload Identifier where that credential is, or may become, available to workloads or instances that require distinct identities under the deployment's identity model. Where the platform offers only such a credential, a credential issuer MUST determine which workload or instance is requesting a credential, by a means the workload does not control, and MUST issue a Workload Identity Credential asserting the corresponding Workload Identifier rather than passing the shared execution credential through. The execution credential MAY be an input to that determination as evidence of the execution environment; it MUST NOT be the sole input. These requirements do not prohibit a shared credential for instances intentionally treated as the same workload.

Agentic Use Cases AI agents are workloads to which the metadata model in this document applies. An agent may run as a long-lived service, an ephemeral task, or multiple concurrent instances. Its group membership, roles, and entitlements describe the agent identified by the credential. Per-request delegation is a separate relationship, as discussed in .

Autonomous operation:

An agent performing scheduled reconciliation can operate under its own workload identity and authorization. An owner or operator association, if asserted, does not imply that each action is performed on that principal's behalf.

Delegated operation:

An assistant can act on behalf of a human or another workload for a particular request. Its Workload Identity Credential still identifies the agent, while a separate authorization context expresses the delegation. The agent's groups and roles do not become those of the delegating principal. describes an OAuth profile in which the agent's identifier appears in the access token's client_id, and the user or system on whose behalf it acts appears in sub. That profile does not change the subject of the agent's Workload Identity Credential.

Shared execution environments:

A platform can host several agents in the same process, container, or execution role. Agents that require separate authorization or attribution need distinct identifiers under ; shared infrastructure alone does not establish that they are the same workload. Conversely, replicas or sessions intentionally treated as instances of the same agent need not acquire distinct identifiers solely because they are separate executions.

requires an agent participating in that framework to be assigned exactly one WIMSE identifier. That requirement belongs to the agent framework; this document follows the general workload and instance identity model of .

Metadata and Endpoint References in Workload Identity Credentials

JWT-Based Credentials Metadata is carried as claims in the JWT claims set, using the claims in . No new mechanism is required, and the rules for doing so are already established: permits additional claims in a WIT, requires that a recipient ignore claims it does not understand, discourages private claim names, and requires that claims used outside closed environments be registered with IANA. Because the claims in are already registered, a Workload Identity Credential expressing workload group, role, or entitlements satisfies those rules without further action.

Metadata URI Claim This document defines the optional metadata_uri claim for JWT-based Workload Identity Credentials, including WITs. Its value MUST be a single JSON string containing the URI of a workload metadata API endpoint for the subject identified by the credential's sub claim. The URI MUST satisfy . It identifies an API endpoint, not a complete request URI: the client adds the subject identifier as the sub query parameter according to . The claim is carried in the signed JWT claims set. A client MUST validate the credential according to its applicable profile before using this claim for endpoint selection (). The claim MAY appear whether or not the credential also carries metadata attributes. Its absence does not imply that metadata is unavailable; the other location mechanisms in remain applicable. This document requests registration of the claim in .

Examples The following non-normative examples show Workload Identity Credentials for the reconciliation service that names with an attribute-bearing identifier. Its replicas share a workload identifier and the same workload metadata. In each example, the identifier is opaque and the attributes appear only as claims. A WIT, whose JOSE header carries "typ": "wit+jwt": The cnf claim is mandatory in a WIT and binds the credential to the workload's key; a WIT has no aud claim and cannot be used as a bearer token (). The same workload's JWT-SVID is instead audience-restricted and carries no confirmation claim: The metadata is identical across these two examples. Two properties illustrate what the separation buys. Reassigning the workload to another team changes groups and leaves sub untouched, so every existing grant and every historical audit record that named the workload remains valid and remains accurate. And a relying party that is not authorized to learn the workload's role can be issued a credential omitting roles, without changing the workload's identifier, because the identifier no longer carries it. Both examples also identify the same metadata endpoint. A client selecting that endpoint appends the respective credential's complete sub value; it does not treat the two identifier schemes as interchangeable.

X.509-Based Credentials X.509 certificates have no JWT claims set. This document defines an extension for locating a metadata endpoint, but no encoding for carrying the metadata attributes themselves in X.509 credentials. defines the Workload Identity Certificate, which carries the Workload Identifier in a single URI SubjectAltName. Attributes cannot be carried in a second URI SAN: requires that additional correlation "MUST NOT be encoded as a second workload identifier in the same WIT or WIC". For an X.509-SVID the constraint is stronger still: requires a validator to reject any certificate bearing more than one URI SAN, whatever its contents. Metadata must go somewhere a relying party will not mistake for an identifier.

SubjectAltName URI Metadata Extension An X.509-based Workload Identity Credential MAY contain the SubjectAltName URI Metadata extension defined below. The extension identifies a workload metadata API endpoint for the workload denoted by the certificate's single URI SubjectAltName. It is a separate certificate extension, not an additional SubjectAltName entry, and does not change the Workload Identifier. The extension MUST be non-critical, so clients that do not support metadata retrieval can ignore it under the processing rules in . The following ASN.1 uses the EXTENSION information object class defined in : The extnValue OCTET STRING contains the DER encoding of MetadataURI, as required by . The value MUST contain a single URI satisfying . The URI is represented using ASCII characters, as required by IA5String. The OID allocation is requested in ; TBD is a placeholder for that allocation. A client MUST validate the credential according to its applicable profile before using this extension for endpoint selection. The client uses the complete workload URI SAN value as the sub query parameter according to . The extension applies only to the subject of the certificate containing it; it is not inherited from a CA certificate. This document defines no mapping for certificates containing multiple URI SAN values.

Example The following illustrative certificate includes the optional endpoint reference: After authenticating the workload using this certificate, a relying party can request metadata for the complete URI SAN value from the endpoint in . It authenticates the metadata request using its own workload credentials. A certificate without this extension can still be used with an endpoint located through trusted configuration or the default URI in .

Workload Metadata Endpoint The workload metadata endpoint is an HTTPS API that returns claims about a workload or workload instance. The caller and the subject of the query are distinct roles: for example, workload B can authenticate to the endpoint to retrieve metadata about workload A. The service authenticates B and authorizes B's access to A's metadata. A caller MAY also request its own metadata, subject to the same authorization checks. The metadata service can be operated by a credential issuer or by a separate authority trusted to provide metadata for the relevant workloads and claims. Knowledge of a Workload Identifier, or possession of another workload's public credential, does not grant access to its metadata.

Endpoint Location and Trust A client MUST select a metadata endpoint for the requested subject in the following order:

1. An endpoint URI explicitly configured out of band for that subject or its namespace.
2. The endpoint URI carried in a validated Workload Identity Credential for that subject, using metadata_uri () or the SubjectAltName URI Metadata extension ().
3. The default URI described below, when the conditions for its use are satisfied.

Credential validation precedes use of a credential-carried URI. When using such a URI, the subject used in the request MUST be the complete Workload Identifier from that credential. Considerations about the credential issuer's authority to nominate a metadata service are discussed in . A deployment or trust domain MAY configure its workload metadata endpoint URI out of band. This configuration MUST be obtained through a trusted mechanism and MUST associate the endpoint with the Workload Identifier namespaces and claims for which it is authoritative. The endpoint can use a different host from the trust domain, for example https://metadata.example.net/workload-info. An explicitly configured URI takes precedence over both a credential-carried URI and the default URI. A credential-carried URI can likewise identify an endpoint on a different host from the trust domain. In the absence of both an explicitly configured URI and a URI in the validated credential being used, a client MAY use the following default URI when the trust domain is a valid fully qualified DNS name and deployment policy trusts that domain's HTTPS service to provide the requested workload metadata: /.well-known/workload-metadata ]]> The well-known URI uses HTTPS on its default port and follows . The client's trust configuration MUST authorize this mapping before the client contacts the endpoint or presents credentials. DNS resolution or a valid TLS certificate alone does not establish authority to assert workload metadata. Where a trust domain is not a valid fully qualified DNS name, or this default mapping is not trusted, a client without an explicitly configured or credential-carried URI MUST treat the endpoint as unavailable. It MUST NOT derive an endpoint from the workload path or an unvalidated credential. A selected endpoint that is invalid, disallowed by local policy, or unavailable MUST NOT cause automatic fallback to a lower-precedence location mechanism. If multiple validated credentials for the same subject carry different endpoint URIs, the client MUST resolve the choice through explicit local policy or treat the endpoint as unavailable. The association with a namespace includes the Workload Identifier scheme. Identifiers using different schemes MUST NOT be treated as interchangeable merely because their trust domains or paths match. A service at the default URI can serve multiple authorized namespaces and distinguishes them using the complete identifier in the request.

Endpoint URI Requirements Endpoint URIs, whether configured out of band or carried in a credential, MUST be absolute HTTPS URIs without user information or a fragment. They MAY contain fixed query parameters, but MUST NOT contain a sub parameter; the client adds that parameter for each request as described in . An endpoint URI MUST NOT contain credentials or other secrets. Clients MUST authenticate the server using the configured trust anchors and expected server identity for the endpoint. Clients MUST NOT automatically follow redirects. An alternative endpoint requires updated trusted configuration or a newly validated credential, subject to the precedence rules in .

Authentication and Authorization The endpoint MUST authenticate the caller using WIMSE workload authentication before returning metadata. This document does not select a mandatory authentication binding. Deployments can use mutual TLS , HTTP Message Signatures , or a WIT with a Workload Proof Token , according to deployment configuration. The service MUST authorize disclosure for the authenticated caller, the requested subject, and each claim it returns. The same request from different callers MAY return different subsets of claims. The authorization policy and any grouping of claims into access levels are deployment-specific.

Metadata Request A client retrieves metadata using HTTP GET as defined in . The request MUST contain exactly one query parameter named sub, whose value is the complete Workload Identifier of the subject. The client MUST percent-encode the value as a URI query parameter using . Only unreserved characters can remain unencoded in the value; percent signs already present in the identifier are encoded as %25. If the endpoint has fixed query parameters, the client appends sub to them using &; otherwise it starts the query with ?sub=. The service decodes the parameter value once to recover the identifier and MUST NOT interpret its path as a set of claims. The client MUST NOT send request content with this GET request. For example, a request for wimse://example.com/workload/a7f3c1a24b904d61 uses the following request target. The caller is authenticated using the configured WIMSE binding; authentication-specific headers, if any, are omitted from this example. If the client instead selects https://metadata.example.net/workload-info from the WIT example in , its request uses the same subject parameter at that endpoint:

Metadata Response A successful response MUST use status code 200 and media type application/json. The response body MUST be a UTF-8 JSON object , with claims directly at the top level and no wrapping metadata object. Claim values retain their defined types, including arrays and objects where applicable. Member names MUST be unique. The response MUST contain a string-valued sub exactly equal to the complete identifier recovered from the request, using case-sensitive string comparison. The client MUST verify this equality and MUST NOT use a response with a missing, invalid, or mismatched sub. The remaining members are claims the caller is authorized to receive, using . Clients MUST ignore claims they do not understand. A claim that is unavailable or withheld MUST be omitted; omission MUST NOT be interpreted as a negative assertion, an empty value, or deletion of a previously received claim. For example, an omitted groups member does not assert that the workload has no groups, whereas "groups": [] asserts an empty group membership list. A response containing only sub is permitted when the caller is authorized to learn that the subject exists but no other claims are available for disclosure. Missing claims required by an authorization policy MUST NOT be treated as satisfying that policy. For a caller authorized to receive group membership and roles, a response might be: A different caller authorized to receive only group membership might receive: The missing roles member in the second response says nothing about the workload's roles. The response is protected by the authenticated HTTPS exchange; it is not a signed assertion for forwarding to another party and is not evidence that the subject participated in this exchange. The relying party authenticates the subject separately when its application requires that proof.

Errors and Caching Authentication failures are handled according to the selected WIMSE authentication binding. For authenticated requests, the endpoint uses HTTP status codes as follows:

• 400 (Bad Request) for a missing, repeated, or invalid sub parameter;
• 403 (Forbidden) when the caller is not authorized to use the metadata endpoint at all;
• 404 (Not Found) when the subject is unknown or the caller is not authorized to learn whether it exists. These cases MUST NOT be distinguished in the response status or body;
• 503 (Service Unavailable) when a temporary failure prevents the service from obtaining the metadata needed to process the request.

Errors MUST NOT disclose withheld claims. Implementations SHOULD also avoid revealing subject existence through differences in response timing. Other HTTP errors retain their meanings in . All HTTP responses from this endpoint, including errors, MUST include Cache-Control: no-store (). In addition to HTTP cache handling, clients MUST NOT use retrieved metadata for any authorization decision other than the one for which it was obtained. This does not preclude retaining records for audit purposes, subject to .

Consistency Across Delivery Methods Claims have the same semantics whether carried in a JWT or returned by the metadata endpoint. The same subject can have different disclosed claim subsets in different credentials and API responses. That an X.509 credential carries no metadata does not mean JWTs or API responses for the same subject must omit it. Different values can also reflect changes since a credential was issued. A relying party using more than one source MUST apply an explicit policy identifying the trusted authority and freshness requirements for each claim used in authorization. It MUST NOT assume that an API response overrides a credential solely because it was received later, or combine claim values from different assertions to obtain a more permissive result. Where conflicting assertions cannot be resolved by that policy, the relying party MUST NOT use the conflicting claim to grant access. Omission does not resolve a conflict or revoke a previously asserted value; nor does it make an older value sufficiently fresh for the current decision. If required metadata cannot be obtained from an acceptable source, access depending on that metadata MUST NOT be granted.

Metadata Across Credential Exchange A credential issuer can accept a Workload Identity Credential issued in another trust domain and issue its own in exchange, for example a cross-platform authentication service that exchanges a platform-provided X.509 credential for a credential in its own trust domain. For JWT-based credentials, defines one protocol for such an exchange. The exchanging credential issuer MAY obtain metadata from the other trust domain, either from the presented credential or from that trust domain's metadata endpoint. According to its own policy, it MAY assert all, some, or none of that metadata, add claims, or modify values. It MAY make the result available in a JWT-based credential it issues (), through its own metadata endpoint, or both. Whatever its origin, metadata the exchanging credential issuer asserts is its own assertion and carries its authority, not the other trust domain's (). A relying party evaluates it according to the trust it places in the exchanging credential issuer, under the source-selection rules in ; it cannot infer what the other trust domain asserted. The exchanging credential issuer accordingly takes on the obligations of a credential issuer in and, where it operates a metadata endpoint, those of a metadata service in .

Relationship to Other Work The RFCs this document profiles are described where they are used. What follows locates it among the drafts it neighbors.

:

Defines the identifier. This document defines what does not go in it and where those attributes go instead. It introduces no new identifier syntax.

:

Provides the architectural frame and the definitions of Workload, Workload Instance, and Workload Identity Credential used in this document.

:

Normative. Defines the WIT and WIC used to authenticate workloads, fixes sub in a WIT as the Workload Identifier, and sets the rules for adding claims to a WIT that profiles. Workloads authenticated using either credential format can be subjects of metadata retrieval.

, , and :

Describe WIMSE authentication bindings that deployments can use for the metadata endpoint. leaves the selection of a binding to deployment configuration.

:

The WIMSE framework for AI agent identity. It establishes identifier and OAuth authorization requirements for agents participating in that framework. This document defines metadata for workloads generally, including those agents; describes the relationship without imposing the agent framework on other workloads.

Security Considerations

Dependence on Identifier Uniqueness Metadata is bound to its subject through the identifier asserted in the credential or API response, so the reasoning here rests on . Sharing an identifier among workloads or instances that require distinct identities does two kinds of damage. Metadata can describe a different subject from the caller, and grants made to the shared identifier can accrue to all its holders. Instances intentionally sharing a workload identity are treated as the same subject; metadata bound only to that identifier cannot distinguish them for authorization or attribution.

Strength of the Issuance Decision A credential issuer asserting metadata is making a claim it must be competent to make. If it distinguishes workloads, or determines their group and role, on properties the workload controls (a self-reported name, a command-line argument, a writable filesystem path, an executable name it can choose), then any workload able to reach the credential issuer can obtain another workload's identifier and metadata. This converts a shared-identifier problem into an impersonation problem, which is worse, because the audit record then positively names the wrong workload. A credential issuer MUST NOT determine a Workload Identifier or Workload Metadata solely from properties the requesting workload self-reports. Beyond that, credential issuers SHOULD determine both from properties the workload cannot alter within its own privilege level. This document does not define what qualifies, since the available properties depend on the platform and range from hardware-rooted attestation through kernel-observed process properties to orchestrator-asserted labels not under the deployer's control. Whichever a credential issuer relies on is security-relevant configuration and warrants the same review as policy. That requirement constrains the workload, not its deployer. Where a credential issuer maps a deployment-time record (such as an orchestrator label or workload annotation) to an authorization-relevant attribute, permission to write that record is permission to grant that attribute. Deployments SHOULD restrict such write access as tightly as the corresponding authorization grant, or determine attributes from properties the deployer cannot write. A deployer can place a workload only in execution environments the platform authorizes them to access. The namespace a pod runs in, the project a cloud workload is deployed to, and the identity pool from which it obtains a credential are all properties the platform assigns and the workload cannot self-report. A credential issuer MAY use such properties as selectors from which to derive Workload Metadata. Where a property is shared across workloads, it MUST NOT be the sole input to identifier determination (); it MAY inform which metadata the credential issuer asserts for workloads that share the environment. For finer granularity within a shared environment, platform-assigned execution environment credentials (such as IAM execution roles, managed identities, or service accounts) can distinguish individual workloads. A credential issuer MAY use such a credential as a selector for metadata derivation; any use of its subject as a Workload Identifier MUST satisfy . Deployments SHOULD confirm that the privilege required to assign such a credential exceeds the privilege required to deploy the workload.

Metadata Service Authority and Request Protection A metadata service MUST obtain authorization-relevant attributes from sources it is trusted to use for the subject and claims concerned. It MUST NOT accept claims solely on the basis that a caller or the subject workload self-reports them. The considerations about writable deployment records and metadata derivation in apply equally to metadata services. An authenticated response establishes which service supplied the claims; it does not by itself establish that the service is authoritative for them. Clients MUST apply the authority and source-selection policy in and verify the response subject in before using returned claims. The target identifier in a request is a lookup key, not a URI to fetch. A service MUST NOT dereference that identifier to obtain metadata without a separately trusted configuration for the source. Clients and services SHOULD apply network access restrictions appropriate to their deployment to prevent metadata lookups from becoming a means of making requests to unintended destinations. The configured endpoint precedence and redirect restrictions in also prevent disclosure of credentials or query subjects to untrusted endpoints. The WIMSE authentication binding and HTTPS transport MUST together protect the association between the authenticated caller and the actual metadata request, including its method and target with the sub query parameter. When an intermediary terminates authentication, the service MUST rely only on a trusted binding of the original caller to that request. Forwarding an unauthenticated caller-identity header is not such a binding. Rate limits and request-size limits SHOULD be applied to reduce enumeration and denial-of-service risks.

Credential-Carried Endpoint References A validated credential authenticates the issuer's statement about the metadata endpoint for its subject. Trust in an issuer for workload authentication does not by itself establish that the issuer is competent to nominate a metadata service. Deployment policy can distinguish these roles and determine which issuers can nominate sources for particular subjects and claims. An endpoint reference in one credential does not establish the service's authority for an entire trust domain. The credential's signature protects the endpoint reference, not the metadata subsequently returned by the service. The latter is protected by the authenticated HTTPS exchange and evaluated under the authority and freshness policy in . The credential issuer and metadata service can be different entities; a reference does not make the API response an assertion signed by the credential issuer. Even a signed URI can direct a client to an unintended destination if a credential issuer accepts an arbitrary URI from a workload or its deployer. Issuance controls and client network access policies help prevent server-side request forgery and disclosure of query subjects or caller credentials. Validation of the subject's credential is not, on its own, a reason for the client to present its own authentication material to any host named in that credential. The URI and redirect restrictions in complement these controls. An endpoint reference remains visible to recipients of the credential and can expose deployment structure, even when the metadata service restricts access to the attributes. Changing a reference requires credential reissuance, whereas the metadata at that endpoint can change independently. Deployments can keep an old endpoint available while credentials referring to it remain valid or use an out-of-band override to direct clients to a replacement.

Workload Identity Credentials as Capabilities Metadata that expresses authority converts an identity credential into a capability. Three consequences motivate . They hold whether or not the credential is a bearer token: a WIT is bound to the workload's key and cannot be used as one (), while a JWT-SVID is presented as one .

Lifetime mismatch:

A permission revoked at the authorization server remains asserted by every unexpired credential carrying it. Workload Identity Credential lifetimes are chosen for identity freshness, not for permission freshness.

Two authorities:

If both the Workload Identity Credential and the relying party's policy assert what a workload may do, the effective policy is whichever is consulted, and the deployment has two sources of truth for one decision.

Blast radius:

An identity credential is presented to every relying party the workload contacts. A credential enumerating permissions discloses the workload's full authority to each of them, including those with no need to know it.

Attribute Staleness In-band metadata reflects the assertions made at credential issuance. A still-valid credential can therefore carry an attribute that has since changed. Deployments requiring fresher attributes can use shorter credential lifetimes or require retrieval from the metadata endpoint for the relevant claims. Retrieval avoids waiting for credential renewal, but a metadata service can itself depend on delayed or replicated data sources; no-store does not guarantee real-time updates at those sources. Deployments MUST establish acceptable freshness for claims used in authorization and MUST NOT use data known to exceed those limits. If policy requires an API lookup and that lookup fails, the relying party MUST NOT silently fall back to older in-band metadata. The source-selection and conflict rules in apply even when both the credential and endpoint response are authentic. Retrieval does not renew, revoke, or establish the validity of a Workload Identity Credential.

Privacy Considerations Asserting an associated human principal per can disclose a person's identifier to relying parties and their audit systems. Credential issuers and metadata services SHOULD disclose such associations only to parties that require them and SHOULD prefer opaque pseudonymous identifiers to directly identifying values such as email addresses. In-band attributes are exposed to each relying party to which the credential is presented. A JWT-SVID can be narrowed by audience restriction, and recommends a single narrowly scoped aud value. A WIT has no aud claim, so issuing different WITs does not itself enforce recipient-specific disclosure. Deployments SHOULD omit sensitive attributes from credentials shared across relying parties and use the metadata endpoint's authorization-dependent disclosure where appropriate. This consideration also applies to organizational information such as group membership and roles. API retrieval reveals the queried workload identifier to the metadata service, allowing it to observe which callers are interested in which workloads. With GET, identifiers also appear in request URIs and can be retained in access logs by clients, servers, and intermediaries. Deployments SHOULD minimize and protect such logs, including audit records of returned claims. HTTPS protects the exchange in transit but does not conceal its contents from its endpoints or TLS-terminating intermediaries. The subject-existence protections and no-store requirement in limit additional disclosure through errors and caches.

IANA Considerations

JSON Web Token Claim Registration This document requests registration of the following entry in the "JSON Web Token Claims" registry established by :

Claim Name:

metadata_uri

Claim Description:

Workload metadata API endpoint URI for the subject identified by the token.

Change Controller:

IETF

Reference:

of this document

X.509 Certificate Extension Registration This document requests an object identifier allocation in the "SMI Security for PKIX Certificate Extension" registry, under the id-pe arc (1.3.6.1.5.5.7.1):

Decimal	Description	Reference
TBD	id-pe-sanuri-metadata	of this document

The allocated value replaces TBD in the ASN.1 definition in .

Well-Known URI Registration This document requests registration of the following entry in the "Well-Known URIs" registry established by :

URI suffix:

workload-metadata

Change controller:

IETF

Specification document(s):

of this document

Status:

permanent

References Normative References Ping Identity CyberArk Defakto Security Intuit Zscaler The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones up to complex multi-service, multi-cloud, multi- tenant deployments. This document defines the credentials that workloads use to represent their identity. They can be used in various protocols to authenticate workloads to each other. To use these credentials, workloads must provide proof of possession of the associated private key material, which is covered in other documents. This document focuses on the credentials alone, independent of the proof-of- possession mechanism. This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner. The System for Cross-domain Identity Management (SCIM) specifications are designed to make identity management in cloud-based applications and services easier. The specification suite builds upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model as well as binding documents to provide patterns for exchanging this schema using HTTP. This document provides a platform-neutral schema and extension model for representing users and groups and other resource types in JSON format. This schema is intended for exchange and use with cloud service providers. Zscaler Palo Alto Networks This document defines a canonical identifier for workloads, referred to as the Workload Identifier. A Workload Identifier is a URI that uniquely identifies a workload within the context of a specific trust domain. This identifier can be embedded in Workload Identity Credentials, including X.509 certificates and JWT-based tokens, to support authentication, authorization, and policy enforcement across diverse systems. The Workload Identifier format ensures interoperability, facilitates secure identity federation, and enables consistent identity semantics. 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. 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 memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. This document obsoletes RFC 7234. Informative References SPIFFE Project n.d. SPIFFE Project n.d. 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. Palo Alto Networks Zscaler University of the Bundeswehr Munich The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as software executing for a specific purpose, potentially comprising one or more running instances. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPsec, and WWW security applications. This document obsoletes RFC 3281. [STANDARDS-TRACK] Defakto Security AWS Zscaler Ping Identity OpenAI Okta This document proposes best practices for authentication and authorization of AI agent interactions. It leverages existing standards such as the Workload Identity in Multi-System Environments (WIMSE) architecture and OAuth 2.0 family of specifications. Rather than defining new protocols, this document describes how existing and widely deployed standards can be applied or extended to establish agent authentication and authorization. By doing so, it aims to provide a framework within which to use existing standards, identify gaps and guide future standardization efforts for agent authentication and authorization. Palo Alto Networks Zscaler The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones to complex multi-service, multi-cloud, multi-tenant deployments. This document profiles a workload authentication based on X.509 workload identity certificates using mutual TLS (mTLS). Palo Alto Networks Intuit The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones to complex multi-service, multi-cloud, multi-tenant deployments. This document defines one of the mechanisms to provide workload authentication, using HTTP Signatures. While only applicable to HTTP traffic, the protocol provides end-to-end protection of requests (and optionally, responses), even when service traffic is not end-to-end encrypted, that is, when TLS proxies and load balancers are used. Authentication is based on the Workload Identity Token (WIT). Ping Identity Defakto Security The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from basic deployments to complex multi-service, multi-cloud, multi-tenant systems. This document specifies the Workload Proof Token (WPT), a mechanism for workloads to prove possession of the private key associated with a Workload Identity Token (WIT). The WPT is a signed JWT that binds the workload's authentication to a specific HTTP request, providing application-layer proof of possession for workload-to-workload communication. This specification is designed to work alongside the WIT credential format defined in draft-ietf- wimse-workload-creds and can be combined with other WIMSE protocols in multi-hop call chains.

Open Issues To be resolved with the working group, and removed before publication.

1. Whether a durable principal association belongs in Workload Metadata (). Per-request delegation is separate from workload metadata. What remains is whether ownership or operational associations with a person, organization, or another workload are attributes worth asserting, how to distinguish those relationships, and whether they justify new registered claims. Associations with people also require the privacy analysis in .
2. Value encoding for groups, roles, and entitlements (). defines all three as multi-valued complex attributes whose elements carry a value sub-attribute, and defers to that encoding without saying whether an array of strings conforms. The interim rule in (emit strings, accept objects with a value sub-attribute) departs from the object form points to, and is in tension with the requirement in to use the same value encodings as the registered claims. It needs either confirming or replacing, and the question may be better raised against than answered here.
3. Independently signed metadata responses. The API response is currently protected by the authenticated HTTPS exchange. A separately signed object would need rules for issuer trust, subject binding, audience, lifetime, replay, and use by parties other than the original caller.
4. Caching retrieved metadata. Whether to allow bounded reuse, and how cache lifetimes, caller authorization changes, and different disclosed subsets would interact. This version uses no-store and does not allow reuse for later authorization decisions ().

Acknowledgments This document restates for workload identity an argument the PKIX community made in , and that already makes for workload identifiers. The authors thank the WIMSE working group for the discussion that prompted it. The authors thank Russ Housley for his guidance on the SubjectAltName URI Metadata certificate extension and its ASN.1 definition.