Summary

  • draft-ietf-wimse-workload-identity-practices-06 describes a practical move away from directly managed long-lived secrets toward platform-issued, short-lived and audience-restricted credentials.
  • A valid credential proves only defined parts of an authentication exchange; it does not by itself prove the exact live workload, exclusive key custody, complete revocation, correct authorization, request execution or the intended result.

The credential is a boundary, not a biography

The most useful thing about the IETF WIMSE Working Group’s Workload Identity Practices draft is its refusal to pretend that all platforms look alike. Kubernetes, cloud metadata services, SPIFFE, CI/CD systems and service meshes reach a similar operating pattern by different routes: a platform observes something about a workload, issues a credential, and lets that credential be used directly or exchanged for another one at an identity provider.

That pattern removes an old and expensive burden. An application no longer needs a static client secret copied into configuration, rotated by a separate procedure and left available for theft between rotations. The platform can instead issue a credential with a narrow audience and a short lifetime. The workload can present it to an external security-token service and receive an access credential appropriate to the target.

But the improvement is easy to overstate. A signed credential is not a complete biography of the process holding it. It is an issuer’s assertion under a defined validation policy. The Datatracker record is equally important here: revision 06 is an active Internet-Draft, intended Informational, submitted to the IESG and currently in “AD Evaluation::Revised I-D Needed.” It is work in progress, not an RFC, a certification programme or evidence that any operator has deployed the practices correctly.

The operational question is therefore not whether workload identity is good. It is what fact each artifact can establish, and what remains unproved after it succeeds.

Proof one: what the platform observed

The generic flow begins after a platform verifies the workload environment and attributes. That sentence contains the first control surface. Which attributes were observed? Were they machine-global, process-specific, orchestrator-supplied or derived from a mutable label? When were they sampled? Which component made the decision?

SPIFFE makes the bootstrap problem unusually visible. Its Workload API need not ask the caller for a pre-existing secret. The implementation identifies the caller from context such as process attributes, kernel metadata or orchestrator labels. This avoids requiring a credential to obtain a credential. It does not make environmental observation infallible. A rule that distinguishes only a host or IP address gives every eligible process on that host a wider route to the same identity than a rule bound to a UID, cgroup or workload-specific selector.

The evidence needed here is a bootstrap receipt: issuer, observed attributes, attestor version, policy version, time and decision. A later token signature cannot reconstruct those inputs if the issuer never retained them.

Proof two: which live instance received the identity

Kubernetes exposes the difference between an account name and an instance. Its service-account administration documentation describes bound tokens and TokenRequest, while the WIMSE draft shows a kubelet requesting tokens from the API server and delivering them to containers in a scheduled Pod. A token may carry namespace, service-account, Pod and node claims.

Those claims matter, but they do not freeze the cluster. The Pod may terminate, a replacement may receive the same service-account identity, labels may change, or a credential may outlive the instance it described. Offline verification with published signing keys proves that the token was signed and that its claims satisfy local checks. It does not ask whether the referenced object still exists. The draft explicitly notes that Kubernetes object invalidation is detected only when TokenReview is used.

Runtime binding therefore needs a fresh, instance-level receipt: the concrete Pod or process, its lifecycle state, the scheduling and policy epoch, and the time at which the relying party evaluated them. A service-account subject alone is too broad when several replicas share it.

Proof three: what was issued and how it arrived

Issuance and delivery are separate. The issuer can mint correct bytes while the wrong process reads them, while a file update is only partially observed, or while a stale consumer keeps an earlier credential.

The draft compares three delivery patterns. Filesystem delivery decouples renewal from the application, but the writer must replace files atomically and flush updates. Local APIs over Unix sockets, loopback or link-local addresses can issue on demand or push renewals, but their security rests on isolation and correct caller identification. Environment variables are static and often leak through monitoring, debugging and process inspection; the draft says they must not be used in production where another mechanism exists.

An atomic rename proves that readers cannot see a partially written file. It does not prove that every process reopened the path, abandoned an old file descriptor or cleared an in-memory copy. A local API response proves that one connection received bytes. It does not prove that redirects, SSRF or a compromised application did not expose them elsewhere. Delivery evidence must name the channel, target instance, credential digest and acknowledgement semantics.

Proof four: who controls the key now

Bearer tokens turn possession into authority for their remaining lifetime. The draft consequently prefers proof-of-possession credentials where platforms and relying parties support them. X.509 authentication demonstrates control of the corresponding private key during the handshake. Key-bound JWT mechanisms can make a stolen token unusable without a second secret. RFC 8705 shows one OAuth mechanism for binding access tokens to mutual-TLS certificates.

Proof of possession answers a narrow question: did this protocol participant demonstrate control of the required key for this exchange? It does not prove that the key has never been copied, that only one process can invoke it, or that the process is still the workload the issuer originally observed. A sidecar, node agent, HSM interface or compromised runtime may all be able to use the key without exporting it.

The possession receipt should bind a concrete exchange to the credential and key identifier, with freshness and anti-replay state. Exclusive custody, where required, needs separate evidence about key generation, storage, access paths and destruction.

Proof five: where the credential may speak

Audience restriction is one of the draft’s strongest practical recommendations. A platform credential used to federate to an external identity provider should name that provider alone. A Kubernetes API token should not be reused outside the platform. A workload that contacts several resources should obtain separate credentials rather than one multi-audience bearer token.

This limits blast radius, but audience is not permission. It answers “which verifier is entitled to accept this token?” It does not answer “may this workload delete this record, sign this release or transfer this money?” RFC 7521 defines an OAuth assertion framework, and RFC 7523 defines JWT bearer assertions. Successful assertion processing can authenticate a client or support a grant. The target still needs an authorization rule for the requested operation and current resource state.

This is also the precise boundary from the earlier BTW article on agentic OAuth. That work examined who authorizes finalized, model-generated tool arguments. This Article stops earlier and ranges wider: it asks whether the identity and credential chain itself is being mistaken for evidence about runtime state, revocation, execution or outcome.

Proof six: whether rotation finished everywhere

Short lifetimes reduce the time available to abuse a stolen credential. They do not produce instantaneous revocation. The draft recommends renewing a filesystem credential before invalidating the old one so applications have time to switch without downtime. That creates a deliberate overlap window. During it, both credentials may be valid. After the new file appears, an application may still hold the old token in memory, a connection pool, a sidecar cache or a retry queue.

The draft also warns that durable storage, backups, snapshots and images can preserve credential copies. A memory-backed mount reduces that exposure; it cannot prove that no downstream component logged or cached the bytes. For each stopped, paused or removed workload instance, the issuer should invalidate credentials and offer validators a status query. The draft leaves the actual invalidation and query mechanism out of scope.

Rotation therefore needs at least four receipts: new issuance, intended consumer uptake, old-credential rejection or expiry, and drain of known caches and instances. “Rotated” without those dimensions is a control-plane declaration, not a completed state transition.

Proof seven: whether the request was executed

The WIMSE architecture draft, workload-credentials draft, HTTP-signature draft and mutual-TLS draft explore adjacent pieces of identity and authentication. None turns authentication into proof that an application operation occurred.

A resource may validate the issuer, lifetime, audience, token type, key possession and custom claims, then deny the request under local authorization. It may accept the request but fail before committing. A proxy may authenticate on behalf of several workloads, making the proxy-to-workload delegation another boundary. A successful transport exchange is not the same as a durable application effect.

Execution evidence must come from the effecting service: canonical request identity, authorization decision, idempotency or transaction identifier, commit status and relevant policy epoch.

Proof eight: whether the intended result happened

Even a committed request is not necessarily the promised result. A credentialed job can enqueue work that later fails. A deployment API can accept a release whose rollout never becomes healthy. A database can commit an intermediate row while a downstream transfer is reversed. Identity telemetry can say who was allowed to try; it cannot certify the business outcome.

This is the practical use of Heng Lu’s distinction between reality and symbolic layers. A token, a policy and a success response may carry powerful institutional meaning, but the reality layer is the state that was actually executed and observed. The related principles of minimum specification and local verification and running-code primacy suggest a disciplined record: keep each claim close to the system capable of validating it.

The result receipt should therefore be produced by the system that can observe the intended state, not inferred from an authentication log. Workload identity is valuable precisely because it can make the first links stronger. Its credibility is damaged when those links are asked to stand in for all the rest.

A reviewable chain

A serious deployment can summarize the evidence model in eight questions: What did the platform observe? Which live instance was bound? What bytes were issued and delivered? Which key was proved for this exchange? Which audience and operation were authorized? Did the old credential stop working across known stores and instances? Did the target execute the request? Did an independent result observer see the intended outcome?

None of these questions negates the others. The safer architecture is not one universal identity token. It is a chain of narrow receipts whose boundaries are explicit enough that a failure can be located without inventing certainty.