Workload Identity

Workload identity solves a narrower problem than machine identity in general: instead of asking "how does this server or service account prove who it is," it asks "how does this specific running process, which might be one of thousands of interchangeable, constantly-restarting instances of the same service, prove what it is, for exactly as long as it's actually running, without a human ever handing it a long-lived password or API key to leak?" The answer the field converged on is to issue short-lived, automatically-rotated credentials at start-up, scoped to that one workload instance, verified against a chain of trust the workload never has to manage itself.

The reference open standard for this is SPIFFE, Secure Production Identity Framework For Everyone. It defines a SPIFFE ID (a URI naming the workload within a "trust domain") and an SVID, a SPIFFE Verifiable Identity Document, issued as either a short-lived X.509 certificate or a JWT, that a workload presents to prove its identity to another workload, typically as the foundation for a mutual TLS (see mTLS) handshake between two services that have never directly shared a secret. SPIRE is the standard's reference runtime: an agent running alongside each workload that attests to what the workload actually is (checking, for example, that a process really is the container image it claims to be) before handing it a fresh SVID.

Where it comes from

SPIFFE traces back to security engineers at Scytale, the team behind the influential "Zero Trust Networks" thinking about eliminating implicit trust inside a network perimeter. The project was contributed to the Cloud Native Computing Foundation and graduated as a full CNCF project in 2022, putting it in the same governance tier as Kubernetes and Envoy. Solidus contributed nothing to SPIFFE or SPIRE and does not implement either.

Solidus status

Solidus has no SPIFFE trust domain, mints no SVIDs, and runs no SPIRE infrastructure. What exists on Solidus's testnet is an adjacent but materially different mechanism: a compute-network operator node registers a did:solidus identity once, on-chain, at start-up (see Machine Identity and Operator Registry), a durable identifier that persists for the node's operational lifetime, not a short-lived credential reissued automatically every time the process restarts the way a SPIFFE SVID is. This is a real, named tradeoff, not an oversight: a compromised long-lived key has a larger blast radius than a compromised short-lived SVID, and Solidus's design accepts that today because its compute network is small, permissioned, and gated behind KYB and a data-processing agreement rather than an auto-scaling fleet of anonymous microservice instances. The scenario SPIFFE was built to solve. If the network grows toward that shape, adopting SPIFFE-style short-lived, per-instance credentials is the honest next step, not yet taken.

Proof: none, there's nothing to demonstrate, because Solidus hasn't built this. The honest, adjacent thing that is checkable: the ComputeRegister transaction handler that Solidus does run is visible in source in the public solidusnetwork/protocol repository's solidus-txns crate, confirming directly that it's a one-time on-chain registration, not a SPIFFE-style reissued-per-instance credential.