Decentralized Identifiers (DIDs) v1.0 + Verifiable Credentials Data Model 1.1

Reference: Sporny, M., Longley, D., Sabadello, M., Reed, D., Steele, O. & Allen, C. (2022). Decentralized Identifiers (DIDs) v1.0: Core architecture, data model, and representations. W3C Recommendation, 19 July 2022. Companion: Sporny, M., Noble, G., Longley, D., Burnett, D. C., Zundel, B. & den Hartog, K. (2022). Verifiable Credentials Data Model v1.1. W3C Recommendation, 3 March 2022. (Citation-only — W3C specifications.) Open access — DID Core v1.0 · Verifiable Credentials Data Model 1.1 · DID Method Registry · DIDComm v2 (DIF)

Summary

The W3C Decentralized Identifiers (DID) and Verifiable Credentials (VC) specifications standardise an identity infrastructure designed to be independent of any centralised registry, identity provider, or certificate authority. A DID is a globally unique URI of the form did:method:identifier — for example did:key:z6Mk... (a key-based DID), did:web:example.com:alice (a DNS-anchored DID), did:ion:... (a Bitcoin-anchored DID via Sidetree). The portion before the colon (method) names a DID method — an algorithm for resolving the DID to a DID document containing public keys, service endpoints, and authentication mechanisms. DID methods can be registry-free (the DID itself encodes the public key), DNS-anchored, blockchain-anchored, or web-anchored; over 100 methods exist. Verifiable Credentials are signed assertions — JSON-LD or JWT documents — issued by one DID-identified party (the issuer) about another DID-identified party (the subject), and presented to a third party (the verifier) via a verifiable presentation. The data model supports selective disclosure (revealing only some claims via BBS+ signatures or zk-SNARK predicates), zero-knowledge proofs of possession, and revocation via status lists. Together DIDs and VCs supply a complete decentralised identity stack: principals control their own identifiers (DIDs), accumulate signed credentials from trusted issuers (VCs), and present subsets to verifiers as needed. The architecture is the modern realisation of substantial machinery from SPKI/SDSI (local namespaces, authority-not-identity, attenuable delegation) and the PGP web-of-trust (peer-issued credentials), repackaged as W3C standards with first-class support for selective disclosure and zero-knowledge predicates. For agent communication, DIDs are the emerging standard for agent identity across ecosystems (DIDComm, Hyperledger Aries, A2A agent cards) and VCs supply the corresponding mechanism for cross-platform agent-trust assertions.

Key Ideas

DID as a self-sovereign URI: did:method:identifier where method names a resolution algorithm; the identifier need not be assigned by any central authority. Over 100 DID methods are registered, ranging from registry-free (did:key, the DID is the public key) to blockchain-anchored (did:ion, did:ethr, did:cheqd) to DNS-anchored (did:web).
DID document: the resolution result — a JSON-LD or JSON-encoded structure containing verificationMethod (public keys for various purposes), authentication (which keys can authenticate as the DID subject), assertionMethod, keyAgreement, capabilityDelegation, capabilityInvocation, and service endpoints (where to find services controlled by the DID subject).
Verifiable Credentials data model: a signed JSON-LD or JWT document with issuer, credentialSubject, issuanceDate, expirationDate, claims, and proof. Supports selective disclosure (BBS+) and zk-SNARK predicates for privacy-preserving credentials.
Verifiable Presentations: a holder packages a subset of held VCs into a presentation, possibly with selective disclosure, and presents it to a verifier with a proof of possession (anchored to a key in the holder’s DID document).
Capability-style delegation: the capabilityDelegation and capabilityInvocation verification relations in DID documents support SPKI-SDSI-style authority-not-identity authorisation; the related W3C Authorization Capabilities (zCaps) specification gives a full SPKI-flavoured capability layer.
Decoupling identity from any single registry: DIDs are deliberately designed to support migration between methods (a did:web can be re-rooted as did:ion), revocation via status-list credentials, and rotation of keys without changing the DID itself.
DIDComm: the messaging protocol for DID-identified agents — JSON-LD over HTTP/WebSocket/Bluetooth, with end-to-end encryption between DID-controlled keys, supports both routing through mediators and direct connections. The standard transport for A2A-style agent interoperability.

Connections

Conceptual Contribution

Claim: A modern identity infrastructure should let principals control their own identifiers (DIDs), accumulate signed credentials from trusted issuers (VCs), and present subsets selectively to verifiers — independent of any centralised identity provider, registry, or certificate authority. Identity, authority, and credential issuance should be decomposable, attenuable, and privacy-respecting.
Mechanism: DID URI scheme did:method:identifier with method-specific resolution to a DID document; DID document with multiple keys per verification relation (authentication / assertion / capability delegation / etc.); Verifiable Credential / Verifiable Presentation data model with selective disclosure and zero-knowledge proof support; DIDComm messaging for inter-DID communication.
Concepts introduced/used: Decentralized Identifier, Verifiable Credential, DID Method, DID Document, Verifiable Presentation, DIDComm, Self-Sovereign Identity.
Stance: W3C Recommendation; standardisation outcome of two decades of decentralised-identity research.
Relates to: Modern repackaging of substantial machinery from SPKI-SDSI (local namespaces → DID methods, authority-not-identity → VC capability claims, attenuable delegation → zCap chains) plus the PGP web-of-trust (peer-issued credentials) — with first-class support for selective disclosure and zero-knowledge predicates. The W3C Authorization Capabilities (zCaps) work is the explicit SPKI-style capability layer on top of DIDs/VCs; together they form a complete capability-based decentralised security infrastructure. In the agent-communication setting, DIDs are emerging as the standard for agent identity across heterogeneous LLM-agent ecosystems: A2A agent cards reference DIDs, ANP uses DIDs for discovery, Hyperledger Aries / DIDComm is the established interop substrate, and several MAS research platforms have switched from custom identifier schemes to DIDs. Where Agent Cards supply what an agent claims about itself, DIDs and VCs supply who issued the claim, when, with what authority, and how to verify it — closing the gap between LLM-agent advertising and verifiable trust assertions. The conceptual link to IPFS-style content-addressing is direct: DID documents and VCs can be content-addressed, anchored to immutable records, and resolved through P2P infrastructure independent of any centralised resolver.

Backlinks

Linked Pages

IPFS Content-Addressed Versioned P2P File System

IPFS - Content Addressed, Versioned, P2P File System

Reference: Juan Benet (2014). arXiv:1407.3561 (DRAFT 3). Source file: downloads/ipfs_benet.pdf. URL

Summary

Original whitepaper introducing the InterPlanetary File System (IPFS), a peer-to-peer hypermedia protocol that synthesises ideas from Git (Merkle-DAG object model), BitTorrent (incentivised block exchange via BitSwap), DHTs (Kademlia-based routing), and self-certifying file systems (SFS) into a single content-addressed distributed file system. Objects are referenced by the cryptographic hash of their contents, giving intrinsic integrity, deduplication, and location independence.

The design stack layers an identity/peer-routing layer (S/Kademlia DHT), a block exchange layer (BitSwap with tit-for-tat credit), an object graph layer (Merkle-DAG with links), a naming layer (IPNS for mutable pointers signed by keys), and application-level filesystem semantics. The paper positions IPFS as the substrate for a “permanent web” where content survives independent of any particular host.

Key Ideas

Content addressing: name = hash(content) -> intrinsic integrity, dedup, cacheability
Merkle-DAG as universal object model spanning files, directories, commits
BitSwap: BitTorrent-like block trading generalised beyond single swarms
Kademlia DHT for peer and content routing
IPNS: mutable pointer namespace via signed records keyed to public keys
Self-certifying paths and location-independent fetching

Connections

Conceptual Contribution

Claim: A single peer-to-peer protocol layered over Merkle-DAG content addressing can unify the roles played today by HTTP, Git, BitTorrent, and CDNs, yielding a permanent, decentralised, versioned web.
Mechanism: Five-layer stack — S/Kademlia DHT for identity/routing, BitSwap for incentive-compatible block exchange, Merkle-DAG for the object graph, IPNS for mutable naming via signed records, and filesystem-level conventions above that. All objects are referenced by their SHA-2 multihash, so any peer can serve any object and clients can verify it independently.
Concepts introduced/used: Content-addressed Storage, Merkle-DAG, Gossip Protocols, BitSwap, IPNS, Self-certifying paths, Peer Sampling Service, Hypermedia
Stance: engineering / systems
Relates to: Directly underpins the distribution story for Protocol Documents in A Scalable Communication Protocol for Networks of LLMs — Agora PDs are hash-identified and can be served over any content-addressed store, of which IPFS is the canonical example. Shares the decentralised-naming motivation with Decentralized Identifiers and the self-organising-overlay motivation with Myconet Fungi Inspired Superpeer Overlay.

In this vault

Agent Network Protocol

ANP — protocol stack for multi-agent networks.

Discussed in:

Agent-to-Agent Protocol

A2A — protocol for inter-agent communication among autonomous LLM agents.

Discussed in:

SPKI-SDSI

SPKI / SDSI: A Simple Distributed Security Infrastructure with Linked Local Names

Reference: Rivest, R. L. & Lampson, B. (1996). SDSI — A Simple Distributed Security Infrastructure. (Working document, MIT.) Followed by: Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B. & Ylonen, T. (1999). SPKI Certificate Theory. RFC 2693, IETF. (Also: Clarke, D. E., Elien, J.-E., Ellison, C., Fredette, M., Morcos, A. & Rivest, R. L. (2001). Certificate Chain Discovery in SPKI/SDSI. Journal of Computer Security 9(4).) Open access (RFC 2693) · SDSI 1.0 (Rivest-Lampson, MIT) · Chain discovery (Elien MIT MS thesis 1998)

Summary

Rivest, Lampson, Ellison and the SPKI working group develop SPKI/SDSI, a public-key infrastructure that takes a sharply different stance from the X.509 / hierarchical-CA tradition: instead of a global namespace of certified identities rooted in a chain of certificate authorities, SPKI/SDSI gives each principal its own local namespace and certificates that bind keys to authorisations rather than identities. SDSI’s central innovation is linked local names: K_alice's friends is a name in K_alice’s namespace; K_alice's friends's secretary is a chain of links — no global registry needed. Authority delegation is similarly local: a certificate K_a → K_b : auth issued by K_a grants authority auth to K_b, optionally with delegation rights. Authority is what matters, not who — a distinction Lampson summarised as “we’re moving from authentication to authorization.” The SPKI Certificate Theory (RFC 2693) formalises this: certificates are 5-tuples <Issuer, Subject, Delegation, Authority, Validity>; chain discovery (Clarke et al. 2001) gives a sound and complete algorithm for deriving “does this principal have this authority?” from a collection of certificates. The design directly anticipates modern decentralised identity / object-capability composition: SPKI/SDSI is the conceptual bridge between the object-capability tradition (E, Spritely) and the cryptographic-identity tradition (X.509, PGP). DIDs and Verifiable Credentials inherit substantial conceptual machinery from SPKI/SDSI; Macaroons (Birgisson et al. 2014) are SPKI-style attenuable capability tokens for HTTP APIs.

Key Ideas

Authorization, not authentication: certificates bind keys to authorities — what the principal is permitted to do — rather than to identities. The question “who is this key?” is replaced by “what is this key allowed to do?”
Local namespaces (SDSI): each principal has its own namespace; names are local identifiers like K_alice's bob, with no global resolution. Linked local names chain across namespaces: K_alice's bob's friends resolves through K_alice’s and then K_bob’s namespaces.
Delegation as a first-class certificate field: a certificate may grant authority with or without the right to re-delegate; chains of delegated certificates are the principal authority-derivation mechanism.
5-tuple certificates: <Issuer, Subject, Delegation-flag, Authorization-S-expression, Validity> (RFC 2693 §2.4 calls the field “Authorization”, not “Authority”); the Authorization is an S-expression in a structured language (action, object, qualifier) that supports rich access-control specifications.
Chain discovery (Clarke et al. 2001): given a goal K_principal has authority A, the chain-discovery algorithm searches the certificate collection for a derivation; sound and complete; polynomial in the size of the certificate collection for many practical fragments.
No mandatory identity binding: certificates may bind keys to local names (SDSI-style) or directly to authorisations (SPKI-style) — identity is just one kind of authority. The system can be used without ever assigning a global “real name” to a key.
Capability composition: SPKI authorities compose under intersection and chain; the resulting authority is the most-restrictive intersection along the chain. This is exactly the capability-security composition rule lifted to a certificate-based distributed setting.

Connections

Conceptual Contribution

Claim: A distributed security infrastructure should bind cryptographic keys to authorisations (what they may do) rather than to identities (who they “really” are); each principal should have its own local namespace; authority delegation should be first-class with an explicit chain-discovery algorithm. The X.509 hierarchical-CA model is the wrong fit for most distributed-system access-control needs.
Mechanism: 5-tuple certificate format (issuer / subject / delegation / authority / validity); local namespaces with linked-local-names resolution; sound and complete chain-discovery algorithm; authority composition under intersection.
Concepts introduced/used: SPKI, SDSI, Linked Local Names, Capability Certificate, Authority-not-Identity, Chain Discovery.
Stance: foundational systems-design paper / IETF specification.
Relates to: Direct conceptual bridge between the object-capability tradition (Dennis & Van Horn 1966, EROS, the E-language line in Miller 2006) and the cryptographic-identity tradition (X.509, PGP). SPKI/SDSI explicitly takes the capability stance — unforgeable name = capability — and lifts it into a distributed cryptographic setting where the unforgeability comes from the public-key cryptography rather than from memory protection. The Macaroons paper (Birgisson, Politz, Erlingsson, Taly, Vrable & Lentczner 2014) is SPKI/SDSI’s most-deployed modern descendant: HMAC-chained authority tokens with attenuation, used in production at Google and elsewhere. Modern decentralised-identity standards — W3C DIDs, Verifiable Credentials, the Authorization Capabilities (zCaps) work — inherit substantial conceptual machinery from SPKI/SDSI even when they do not cite it directly. Within this vault, SPKI/SDSI is the missing distributed-cryptographic counterpart of the in-process capability work in Capability Myths Demolished and Robust Composition - Towards a Unified Approach to Access Control and Concurrency Control — it is what those frameworks become when keys cross machine boundaries. The Lowe/PKI Layer Cake - Kaminsky Patterson Sassaman-style critiques of X.509 PKI are simultaneously arguments for SPKI-style local-name systems: parser differentials and the trust-collapse-by-CA-misissuance problem largely vanish when certificates bind authority rather than identity.

In this vault

Verifiable Presentation

A signed package wrapping one or more Verifiable Credentials (or selectively-disclosed subsets thereof), presented by a holder to a verifier with a proof of possession anchored to a key in the holder’s DID Document. Supports zero-knowledge proofs of credential possession without revealing the credentials themselves; the privacy-preserving counterpart of “show me your driver’s licence.”

In this vault

DID Document

The resolution result of a Decentralized Identifier — a JSON-LD or JSON document containing verificationMethod (public keys), verification relations (authentication, assertionMethod, keyAgreement, capabilityDelegation, capabilityInvocation), and service endpoints. The capabilityInvocation and capabilityDelegation relations support SPKI-SDSI-style authority-not-identity authorisation flows.

In this vault

DID Method

The portion of a Decentralized Identifier URI before the second colon (did:METHOD:identifier) — names a registered algorithm for resolving the DID to its DID Document. Methods can be registry-free (did:key, the DID is the public key), DNS-anchored (did:web), blockchain-anchored (did:ion Bitcoin/Sidetree, did:ethr, did:cheqd), or anchored to other registries (did:peer, did:pkh). Over 100 methods are registered in the W3C DID Method Registry.

In this vault

Verifiable Credential

A W3C-standardised signed assertion (JSON-LD or JWT) issued by one DID-identified party (the issuer) about another DID-identified party (the subject). Carries issuer, credentialSubject, dates, claims, and a cryptographic proof. Supports selective disclosure (BBS+ signatures), zero-knowledge predicates (zk-SNARK proofs over claims without revealing them), and revocation via status-list credentials. Presented to a verifier via a Verifiable Presentation.

In this vault

Decentralized Identifier

A W3C-standardised globally-unique URI of the form did:method:identifier whose resolution is governed by a DID method algorithm rather than by any centralised registry. The portion before the colon names the resolution method (did:key, did:web, did:ion, …); the resolution result is a DID Document containing public keys, service endpoints, and verification relations. The substrate of self-sovereign identity; the modern descendant of SPKI/SDSI capability-style PKI.

In this vault

Linked Local Names

SDSI’s mechanism for distributed naming without a global registry: a name like K_alice's bob's friends is resolved by chaining lookups across local namespaces — first K_alice looks up “bob” in her namespace and finds K_bob, then K_bob looks up “friends” in his namespace, and so on. No central authority needed. The conceptual ancestor of DID-style namespacing in modern decentralised-identity standards.

In this vault

Certificate Authorities

Entities in a Public Key Infrastructure that issue X.509 certificates binding public keys to identities. CAs are a single point of trust whose aggregation of implementation-dependent parsing, naming, and OID choices has produced a long tail of signature-transfer, name-confusion, and EKU-bypass attacks.

In this vault

Macaroons

Birgisson, Politz, Erlingsson, Taly, Vrable & Lentczner’s (2014) lightweight authorisation tokens — HMAC-chained capability tokens supporting attenuation (the holder can derive strictly less-permissive sub-tokens) and third-party caveats (delegating verification of a condition to a separate service). The most-deployed modern descendant of SPKI/SDSI capability certificates, used in production at Google and elsewhere. A practical realisation of Capability Security in HTTP-API authorisation.

In this vault

Capability Security

Access-control style where authority is conveyed by unforgeable object references; lexical scope in languages like Scheme suffices as a capability kernel.

In this vault

Capability Certificate

A signed certificate binding a public key (the subject) to an authority (a description of what actions the subject is permitted) — the SPKI-style realisation of Capability Security in a distributed cryptographic setting. Composes by chain (concatenated delegations, with authority intersected at each step) and by attenuation (a delegate can issue a sub-certificate granting strictly fewer rights). Modern descendants: Macaroons (Birgisson et al. 2014), zCaps (W3C Authorization Capabilities), object-capability tokens in cap-secure RPC.

In this vault

SDSI

Simple Distributed Security Infrastructure (Rivest & Lampson 1996), unified with SPKI in RFC 2693. SDSI’s central innovation is local namespaces with Linked Local Names: each principal has its own namespace, and names like K_alice's bob's friends resolve through chains across local namespaces — no global registry. Combined with SPKI authority certificates, it gives a complete distributed access-control infrastructure free of mandatory global identity.

In this vault

SPKI

Simple Public Key Infrastructure (Ellison et al. RFC 2693, 1999) — the IETF formalisation of the SPKI/SDSI design. Certificates bind keys to authorisations (5-tuples <Issuer, Subject, Delegation, Authority, Validity>) rather than to global identities. Authority delegation is first-class; chain discovery (Clarke et al. 2001) gives a sound and complete algorithm for deriving access decisions from collections of certificates. The cryptographic-identity counterpart of object-capability security in distributed systems.

In this vault

Survey Of Agent Interoperability Protocols

A Survey of Agent Interoperability Protocols: MCP, ACP, A2A, and ANP

Reference: Ehtesham, Singh, Gupta, Kumar (2025). arXiv:2505.02279. Source file: 2505.02279v1.pdf. URL

Summary

This survey examines four emerging agent communication protocols targeting different interoperability tiers: the Model Context Protocol (MCP) for JSON-RPC tool invocation and context delivery; the Agent Communication Protocol (ACP) for REST-native multi-part performative messaging; the Agent-to-Agent Protocol (A2A) for peer-to-peer Agent-Card-based task outsourcing; and the Agent Network Protocol (ANP) for decentralized discovery using DIDs and JSON-LD.

The authors contrast architectures, discovery mechanisms, security models, and communication patterns, then recommend a phased adoption roadmap (MCP for tool access, then ACP for messaging, A2A for collaborative execution, ANP for open marketplaces). A timeline traces ancestry from KQML (1993) and FIPA-ACL (2000) through RAG, ReAct, function-calling up to modern agent protocols.

Key Ideas

Phased adoption roadmap: MCP -> ACP -> A2A -> ANP.
MCP core primitives: Tools, Resources, Prompts, Sampling under JSON-RPC 2.0.
A2A introduces Agent Cards, Tasks, Artifacts for enterprise-scale delegation.
ANP uses DIDs and JSON-LD for decentralized, internet-scale agent discovery.
Security threats tabulated across creation/operation/update lifecycle phases.

Connections

Conceptual Contribution

Claim: Modern agent interoperability is best understood as a four-tier stack (MCP for tools, ACP for messaging, A2A for delegation, ANP for open discovery) and should be adopted in that phased order.
Mechanism: Structured comparison of architectures, discovery, security, and message patterns; historical timeline rooting each protocol in KQML/FIPA-ACL ancestry; lifecycle threat table.
Concepts introduced/used: Model Context Protocol, Agent-to-Agent Protocol, Agent Network Protocol, Agent Communication Protocol, KQML, FIPA-ACL, Agent Cards, Decentralized Identifiers, JSON-RPC, Tool Use, LLM Agents
Stance: survey
Relates to: Complements the broader Survey Of AI Agent Protocols with a narrower, adoption-oriented roadmap. Its security-threat lifecycle connects directly to AI Agents Under Threat and MalTool Malicious Tool Attacks.

Decentralized Identifiers (DIDs) v1.0 + Verifiable Credentials Data Model 1.1

Summary

Key Ideas

Connections

Conceptual Contribution

Tags

Backlinks