When I wrote about pico-to-pico identity arriving in version 1.6, I explained why I reached for DIDs rather than KERI. The other obvious question is "Why not SPIFFE, the workload-identity stack that Kubernetes shops already run?" It's a fair question, because a pico is, from one angle, just a workload; it's a running process that needs to prove which process it is before another one will talk to it. So why give it a DID instead of a SPIFFE ID?

The answer comes down to a single property: whether the identity travels with the thing it names. SPIFFE and picos give opposite answers to that, and the opposition isn't an accident. It falls out of what each one is built to identify.

What SPIFFE Gets Right

SPIFFE is a genuinely good design for the problem it takes on. A workload asks the local agent for its identity, and instead of holding a secret it proves who it is by what it is and where it runs; the platform attests to the process, and the workload gets back a short-lived credential called an SVID. There's no long-lived key to leak, because the credential expires in minutes and renews on its own. For a datacenter full of ephemeral, interchangeable containers, that's exactly right; you don't want a Kubernetes pod hoarding a private key that outlives it.

The trust anchor for all of this is a server that runs the trust domain. That server decides which workloads exist, attests to them, and signs their SVIDs, and every workload in the domain trusts it by construction. Inside one administrative boundary that centralization is a feature, not a flaw; someone runs the cluster, and that someone is exactly who should be minting identities in it. SPIFFE fits the shape of the place it lives.

Identity that's Derived versus Identity that Lasts

That fit is also the reason SPIFFE isn't what a pico needs. A SPIFFE identity is derived: it comes from what the workload is and where it runs, and the domain's server mints it fresh in whatever environment the workload happens to land in. Move the workload to a different cluster and it gets a different identity from a different authority, because the identity was never the workload's to carry; it was a fact about the environment. That is a badge the building prints for you at the door. It works beautifully inside the building and means nothing the moment you step outside.

A pico's identity is long-lived by design. Every pico holds its own keys and carries a did:webvh that stays the same identifier no matter which engine it runs on or how long it runs; the identity is a property of the pico, not of the host underneath it. When a pico moves between engines, its identity moves with it, because the pico is the one holding the keys that prove it. That is a passport rather than a printed badge; you carry it across borders, and it still says who you are on the other side. For a system whose whole point is picos and meshes that are portable between engines, an identity that gets re-minted per environment just isn't the right choice.

Durable identity is a property that makes picos useful for tasks that ephemeral workloads can't do easily.

• Persistent relationships. A subscription links two identifiers; if they reset on every restart, the relationship can't outlive the move. Durable identity is what lets a mesh of relationships accumulate and survive.
• Reputation and history. Because a pico keeps the same identifier over time, the parties it deals with can remember their history with it and decide how far to trust it. An identifier that resets each session gives them nothing to base that judgment on.
• Credentials. A verifiable credential is a claim about a subject, and the subject has to persist for the claim to keep meaning anything. Without a durable identity there is nothing to hold or present a credential.
• Delegation. An actor operating on your behalf needs a stable identity so the authority you grant persists and stays revocable. Ephemeral identity means re-authorizing constantly and having nothing durable to take back.
• Continuity across infrastructure. Because the keys belong to the pico, the actor is decoupled from the host; you can move engines, change providers, or recover from a crash without losing who the pico is.
• Longevity beyond any vendor. The identity outlives the company that built the device, so a pico doesn't die when someone's cloud is switched off. This is the Internet of My Things rather than the CompuServe of Things.
• A lifecycle that follows the thing. For something with a long life that changes hands, identity and history span custodians instead of resetting with each one.

A digital twin is a good example of where durable identity matters. A pico that stands in for an IoT device grows more valuable the longer it lives, because it accumulates the device's history, relationships, and state over years rather than minutes. When I built Fuse, each car had its own pico, and selling the car meant handing that pico to the new owner with the maintenance history and important relationships intact; the identity was bound to the vehicle, not to me. That is the case ownership language gets wrong. The pico's identity outlives any particular owner, and it has to, because the car it represents might too.

Trust Domains and Strangers

The same split shows up when two identities from different places need to trust each other. SPIFFE can federate across trust domains, but it does it the administrative way: the operators of two domains exchange trust bundles ahead of time, and only then can workloads on one side verify workloads on the other. That's reasonable when both domains belong to the same company, or to two companies that signed a contract; someone with authority on each side sets the relationship up in advance. It assumes the parties already have a reason, and a person, to arrange the introduction.

Picos owned by two different people, on two different engines, don't have that person in the middle, and I don't want to require one. A pico resolves another pico's DID and the two form a relationship directly, with no administrator on either side pre-arranging a federation. This is the same first-person idea I keep pushing for human identity, now applied to software actors: identity you present yourself, not identity an authority vouches for on your behalf. Trust between strangers shouldn't require a treaty negotiated by their landlords.

An Actor, Not a Process

None of this makes SPIFFE wrong; it's just built for a different kind of thing. SPIFFE names a process: a unit of execution that runs, does its work, and can be killed and restarted at will, where you care that some process is handling the request rather than which one. A pico is an actor: something that persists, holds state and relationships, and acts for someone or something over time. A process has an identity so the system can manage it; an actor has an identity that it uses over time.

Systems engineers have a mantra for this divide: treat your servers as cattle, not pets. Cattle are numbered and interchangeable, and when one gets sick you replace it instead of nursing it back to health; that is exactly the right way to run a fleet of workloads, and it's the world SPIFFE is built for. A pico is a pet. It has a name and a history, and relationships that make it worth keeping this one rather than swapping in another that would do the same job.

That distinction is the thread running through everything above. Persistent relationships, reputation, credentials, delegation, history, continuity, and longevity are not affordances a process needs; they are what it takes to be an actor rather than a process, and every one of them presupposes an identity that lasts. So a durable identity isn't a feature bolted onto a workload. It's foundational.

The choice between SPIFFE and DIDs, then, isn't really a choice between two identity technologies; it's a question about what you're naming. If you are naming a replaceable process inside one administrator's domain then SPIFFE is the right tool, and I'd use it. But a pico is an actor that persists over time, not a process that happens to carry an identity, and the identity model has to reflect that. Give the thing that's meant to persist and travel an identity that persists and travels with it.

Photo Credit: A printed visitor badge and a passport from ChatGPT (public domain)