Software Identity Binding Landscape
The problem is older than any one mechanism.
Software systems need ways to answer different questions: Which actor is this? What state is it in? What evidence supports that state? Which statements have been made about it? Which authority does it carry? Which changes preserve continuity? Which identifier refers to the binding being evaluated?
No single mechanism needs to answer all of these questions. Modern identity, attestation, transparency, provenance, and authorization systems divide the problem into different objects and roles.
SIBUID is best understood against that landscape. It is not a replacement for it.
A problem-centered map
| Concern | Typical object | Persistent question |
|---|---|---|
| Actor identity | workload/service/agent identifier | Which actor? |
| Verifiable identity | certificate/token/identity document | Can the actor present a verifiable identity? |
| Operational state | evidence/claims | What state is the actor in? |
| Appraisal | attestation result/policy decision | Is that state acceptable? |
| Artifact identity | digest/resource descriptor | Which exact artifact? |
| Transparency | signed statement/log entry/receipt | What was asserted and recorded? |
| Provenance | supply-chain statement | Where did the software come from? |
| Binding identity | policy-delimited binding identifier | Which identity-to-state relationship? |
| Continuity | transition policy/history | Is this still the same binding? |
Workload identity
Workload-identity systems establish stable identities for software running in dynamic infrastructure. A current example is SPIFFE, whose SPIFFE ID uniquely and specifically identifies a workload within a trust domain and whose identity documents make that identity verifiable.
This addresses Which workload is this? A SIBUID can refer to a binding associated with such a workload identity rather than replacing it.
Current example: SPIFFE / SPIRE. Source: SPIFFE Concepts.
Attestation
Attestation systems address another question: what evidence supports claims about the current or intended state of a system?
The RATS architecture separates the Attester, Evidence, Verifier, Attestation Result, and Relying Party. It is deliberately neutral toward processor architectures, claim content, and protocols.
A SIBUID does not replace Evidence or an Attestation Result. Those objects can contribute to the state represented by a binding.
Current example: IETF RATS. Source: RFC 9334.
Artifact attestations
Artifact-attestation systems bind statements to exact software artifacts. The in-toto Statement model requires subject artifacts to carry digests and treats the identified subjects as immutable for matching purposes.
This is strong for Which exact artifact does this attestation concern? It is distinct from Do several changing states still belong to the same policy-delimited software-identity binding?
Current example: in-toto Attestation Framework. Source: Statement v1 specification.
Transparency
Transparency systems make signed statements inspectable and auditable over time.
SCITT defines a content-agnostic architecture for signed statements, receipts, and verifiable data structures. Its Subject concept can group a logical collection of statements, including coherent sequences about the same artifact.
Existing transparency mechanisms can already provide stable subject references across changing statements. SIBUID therefore does not claim that a new persistence mechanism is missing. Its role is descriptive: when an identifier is used specifically to identify a software-identity binding bounded by continuity policy, this reference calls that semantic role a SIBUID.
Current example: SCITT. Source: RFC 9943.
Transparency logs
Transparency logs provide append-only records of signed or verified events. Sigstore's Rekor is designed as an immutable, tamper-resistant ledger for signed metadata in software supply chains.
A log entry can be evidence in the history of a binding without being the semantic identity of the binding itself.
Current example: Sigstore Rekor. Source: Rekor overview.
Agent identity
As software becomes more autonomous, existing identity and authorization mechanisms are being applied directly to agents that can act with delegated authority.
This is relevant because autonomy makes the distinction between actor identity and current binding state more operationally important. It does not make SIBUID an AI-agent standard.
Current example as of 2026: AI Agent Authentication and Authorization, revision 03 published 6 July 2026. Source: IETF Datatracker.
What SIBUID claims — and does not claim
Does not claim
- existing systems lack identifiers;
- existing systems cannot group changing statements;
- software identity is an unsolved field;
- a new cryptographic mechanism is required;
- one universal continuity policy should exist.
Does claim
An actor identifier, a binding identifier, and a snapshot identifier answer different questions even when one technical field can sometimes perform more than one role.
The distinction is semantic. Implementations may reuse existing mechanisms.
Current comparison
| System | Primary role here | Relationship to SIBUID |
|---|---|---|
| SPIFFE / SPIRE | Workload identity and issuance | Complementary |
| RATS | Evidence appraisal architecture | Complementary |
| in-toto | Artifact-bound attestations | Complementary |
| Sigstore / Rekor | Transparency evidence | Complementary |
| SCITT | Statement sequencing and subject grouping | Can implement part of the role |
| Agent identity work | Identity/authentication/authorization for autonomous software | Application context |
| SIBUID | Semantic name for a policy-delimited software-identity binding identifier | Descriptive layer |
Time-bounded context
This page is intentionally temporal. Standards, drafts, and implementations will change. The canonical definition of SIBUID does not depend on this table.
When a mechanism changes, this page should be updated by adding or revising an entry rather than rewriting the underlying problem.