Summary

  • Revision 07 says each JWT must not carry more than one audience unless the platform cannot issue multiple credentials or the workload cannot influence the audience. Revision 06 said a JWT should carry only one.
  • The security mechanism is receiver-to-receiver impersonation: every party holding a reusable bearer token can present it to every other party that accepts it.
  • A capability–exception receipt should record why separation is impossible, the complete receiver graph, token lifetime and reach, validation at each receiver, compensating controls, review time and the condition for ending the exception.

Imagine a Pod using one projected service-account token twice. It presents the token to the Kubernetes API server for an infrastructure operation. It also presents the same token to an external identity provider to obtain a different access token. Both receivers are legitimate. Both now hold the bearer credential. If its audience permits both uses, the external identity provider can present it to the API server and appear to be the workload.

No interception is required for that path. No log has to leak. No attacker has to break the issuer. A receiver that was meant to authenticate the workload becomes able to impersonate it at another receiver because the credential itself does not preserve the boundary between them.

That is the central operational change in draft-ietf-wimse-workload-identity-practices-07, uploaded on 22 September 2026. The document remains an active Internet-Draft intended as Informational. Datatracker shows AD Evaluation::AD Followup, with Charles Eckel as the action holder. That is a review state—not an approval, an RFC number, a deployment report or a finding that any named platform is non-compliant.

The modal verb changed because the trust graph did not

Revision 06 gave the right direction. Its general requirements said credentials should be scoped as narrowly as possible and, where a platform supported multiple credentials, a workload should obtain a distinct credential for each resource or identity provider. Its audience section said each JWT should carry only a single audience.

Revision 07 makes the boundary normative. Credentials MUST be scoped as narrowly as possible. A credential used to access a platform resource MUST be scoped to that resource. A credential used for federation MUST name the identity provider as its sole audience. Each JWT MUST NOT carry more than one audience, subject to a defined capability exception.

The change from SHOULD to MUST is not cosmetic typography. A recommendation allows an implementation to choose another path after weighing circumstances. A requirement makes separation the default condition that the exception must explain. The draft also adds the missing mechanism: if several relying parties appear in the same aud claim, any one can present the token to another and potentially obtain unintended access.

An audience is therefore not merely routing metadata for a validator. It is a list of places where a bearer credential can speak. Every additional place is also another holder capable of replaying the credential wherever else it is accepted.

Kubernetes makes the boundary concrete

Kubernetes can issue multiple projected service-account tokens, each with a custom audience and lifetime. Revision 07 uses that capability to separate three paths: access to the API server, access to another resource inside the cluster and federation with an external identity provider. The tokens for those paths must be different and must have different audiences.

This is a stronger statement than “the API server checks aud.” Validation at one receiver cannot protect another receiver if both accept the same bearer material. The external identity provider may validate issuer, signature, expiry and audience exactly as configured and still possess a token that the API server will accept. Each local check can pass while the system boundary fails.

The same pattern appears in the draft's SPIFFE example. A JWT-SVID for an internal resource and a JWT-SVID for federation must be different tokens with different audiences. In the cloud-provider pattern, revision 06 said a workload should obtain separate credentials and should not reuse the internal credential for an external security token service. Revision 07 says it must obtain separate credentials and must not reuse the internal credential. The receiver graph is the invariant across platforms.

The exception names a capability deficit, not an equivalent design

The draft does not pretend every platform can satisfy the rule. Some issue only one credential per workload. Some do not allow the workload to influence audience. Revision 07 permits the single-audience requirement to yield when multiple credentials cannot be obtained or the audience cannot be influenced.

That clause is easy to misread as a convenience escape. The surrounding text says the opposite. A deployment using one credential across contexts cannot rely on audience scoping to contain compromise. It must keep the credential lifetime as short as the platform allows, restrict which components can reach it and treat every recipient as capable of impersonating the workload at every other accepting recipient.

The result is not “compliant enough” in the sense of equivalent isolation. It is a different risk state. The receiver graph becomes larger, and control moves from cryptographic audience separation to time, component access, network paths, validation discipline and detection. Those controls can be reasonable, but they must be visible as compensation for a missing capability.

Revision 07 applies similar honesty to proof of possession. Where neither platform nor relying party supports it, compensating controls move from SHOULD to MUST: shorter token lifetimes, stricter audience scoping and additional network controls. A bearer token remains usable by whoever holds it. Shortening its life reduces the window; it does not make the token sender-bound.

Preserve the exception at the point of use

A capability–exception receipt would keep one deployment decision from dissolving into a generic platform label.

Receipt field Evidence to retain
Issuer capability Platform, issuer and exact version; ability to issue multiple credentials
Audience control Whether the workload can request or influence aud, with API or configuration evidence
Intended use Platform API, internal resource, federation or external resource
Credential identity Non-secret fingerprint or generation identifier, never the bearer value
Receiver graph Every accepting receiver and every path on which one receiver could present to another
Lifetime Requested and issued TTL, renewal behaviour and invalidation path
Reach Components, mounts, sidecars, proxies, logs and egress paths able to access or carry it
Validation Issuer, audience, type, proof-of-possession and network checks at each receiver
Exception The missing platform capability and why separation cannot be obtained
Compensation Shorter lifetime, component restriction, network controls, monitoring and alerting
Review Owner, decision time, next review, correction trigger and exit condition

The token fingerprint must be non-secret and one-way. The receipt is not a reason to store a bearer credential beside a change ticket. Its purpose is to bind a risk decision to the credential generation, receivers and controls that decision actually covered.

It should also distinguish “cannot” from “did not.” If the issuer supports separate credentials but an integration reused one for convenience, the capability exception does not describe the deployment. If a later platform release adds audience control, the exit condition has arrived. An exception without a review time can silently become architecture.

This article is deliberately narrower than BTW's earlier account of the eight proofs between workload bootstrap and outcome. That piece maps the full chain from platform evidence to resource result. Revision 07 creates a sharper question inside one link of that chain: which receivers can make this exact bearer token speak, and to whom?

Sources and limits

The primary evidence is the revision 07 Datatracker record, the document history, the immutable revision 07 text and the comparison revision 06 text. Prior BTW context is A Workload Credential Is Not the Workload. The distinction between a coordination artifact and operational reality follows the implementation discipline set out in Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption.

These sources establish document state, normative text and security mechanism. They do not establish a real-world incident, a complete implementation census or non-compliance by any named operator. The receipt is an editorial proposal, not a requirement in the WIMSE draft.