From Software Identity to Binding Continuity
A history of the problem, not a history invented for the term.
SIBUID is a recent descriptive term. The underlying problem is not recent.
Software has long required identifiers, credentials, provenance, evidence, and policy. What changes over time is the degree to which software can move, update, act autonomously, inherit authority, and accumulate evidence while retaining a stable identity.
1 — Software as a named object
The earliest form of the problem is simple: How do we refer to a piece of software? Names, process identifiers, package names, service names, hostnames, database keys, and other identifiers provide reference. The main concern is naming.
2 — Software as an authenticated actor
Distributed systems turn software into an actor that must authenticate to other software. The question expands: Which software actor is making this request, and can it prove that identity? Certificates, tokens, service identities, and workload-identity systems make software identity verifiable in dynamic environments.
3 — Identity separates from location
Cloud computing, orchestration, containers, autoscaling, and heterogeneous infrastructure weaken the assumption that network location is a reliable identity boundary. A workload may move while its identity remains meaningful.
Historical example: SPIFFE formalizes a workload identity namespace and verifiable identity documents for dynamic environments. Source.
4 — Identity separates from exact software state
Once an identity can persist while software updates, another separation becomes visible. The same identity can be associated over time with different keys, builds, configurations, runtimes, and evidence.
What, at this moment, stands behind the stable identity?
5 — Evidence becomes a first-class object
Remote attestation makes operational state explicit. The architecture separates the actor producing evidence, the evidence itself, the verifier, the appraisal result, and the relying party.
Historical example: RFC 9334 (January 2023) provides the RATS architectural model and common terminology. Source.
6 — Artifact state becomes content-addressable
Software supply-chain systems bind attestations and provenance to exact artifacts. Digest-addressed subjects make Which exact artifact? precise. They also clarify a separate problem: a digest names an exact state; it does not by itself explain whether a later state remains part of the same operational relationship.
Historical example: in-toto's Statement model requires subject software artifacts to carry digests. Source.
7 — Assertions become transparent over time
Transparency architectures add persistent, auditable histories of statements. A stable subject reference can organize changing statements without forcing every state to become an unrelated object.
Historical example: SCITT, standardized as RFC 9943 in June 2026, defines signed statements, receipts, sequences, and issuer-defined Subjects for grouping statements. Source.
8 — Software becomes increasingly autonomous
Software actors increasingly invoke tools, act across systems, hold delegated authority, rotate credentials automatically, update without continuous human intervention, and produce or consume evidence.
The practical distance between the actor's stable identity and the state, evidence, and authority currently represented by that identity becomes larger.
Current example as of 2026: IETF work applies existing workload-identity and authorization mechanisms to AI-agent interactions. Source.
9 — Binding continuity becomes explicit
Once identity and its current representation are treated as distinct, systems encounter a recurring policy question: When the representation changes, is this still the same binding?
The answer depends on the meaning of the binding and the policy around it. This is where binding continuity becomes useful explicit vocabulary.
SIBUID enters the vocabulary
SIBUID is introduced in this reference as Software Identity Binding Unique Identifier.
It names the semantic role of an identifier used to distinguish a software-identity binding within a continuity boundary chosen by policy.
It does not claim that the mechanisms underneath it are new. It does not claim that earlier identity, attestation, transparency, or provenance systems lacked identifiers.
An open-ended timeline
Software naming
↓
Authenticated software identity
↓
Identity independent of location
↓
Identity independent of exact state
↓
Attestation and evidence
↓
Content-addressed artifacts
↓
Transparent statement histories
↓
Autonomous software and delegated authority
↓
Binding continuity
↓
[ future mechanisms and vocabulary ]
Future systems can be added as new stages or examples. The structure is designed to grow without rewriting the earlier problem.
The durability test
A historical reference should remain meaningful even when individual standards change.
The problem belongs in the body. Standards belong in examples and evidence.
If every named standard on this page disappeared, the sequence above should still describe the underlying systems pressure.