XID

Identity System / Design

Novel decentralized identifier architecture — "eXtensible IDentifier" — defined as a unique 32-byte identifier for a subject entity (person, organization, device, or any abstract subject), generated from the SHA-256 hash of an inception key. XIDs resolve to XID Documents — Gordian-Envelope-encoded controller documents that bind the identifier to public keys, permissions, endpoints, and delegation rules — and inherit Envelopes selective elision so the controller document can be tailored per-recipient. The defining architectural insight is that holders, not issuers, control which parts of the controller document are revealed to which counterparties. Intentionally not W3C DID-conformant: XIDs are research/architectural exploration positioned alongside (not within) the W3C DID paradigm. Recently extended with "Edges" (BCR-2026-003) to support web-of-trust attestations between XIDs

Community
Links
Visit Community

Details

License BSD-2-Clause Plus Patent License — bc-xid-rust reference library; bc-envelope-cli tooling supports XID operations
Dev Status 📋 Planned
Dev Status Detail Research / pre-spec — partial reference implementation in bc-xid-rust; "open for community feedback"; Q1 2026 Blockchain Commons report describes XIDs as "one of our largest current projects"
Owner Blockchain Commons LLC (not-for-profit benefit corporation founded by Christopher Allen, April 25, 2019; Berkeley, California). Specification author: Wolf McNally, Lead Researcher
Country USA (Berkeley, California)
Start Year 2024
Stack Rust (bc-xid-rust); integrated with bc-envelope, provenance-mark crates
Funding Blockchain Commons donations and patron sponsorships
Last Investigated Jul 1, 2026

Use Case Domains

Identity & Trust

Identity System / Design Attributes

Origins Blockchain Commons; built on the Gordian Envelope architecture; influenced by but explicitly diverging from W3C DID Core
Database N/A — controller documents are Envelope artifacts; persistence is implementation concern (registry, web URL, blockchain, peer-shared via Garner)
Query Language N/A directly — Envelope's selective-disclosure mechanism via inclusion proofs effectively functions as the query model; recipients receive only the parts of the controller document the holder chooses to reveal
Data Formats CBOR (deterministic via dCBOR); 32-byte identifier tagged with CBOR tag #6.40024; XID Documents as Gordian Envelopes
Mobile Support Yes — libraries cross-compile to mobile platforms; Envelope tooling on mobile via BCSwiftEnvelope
Web Support Yes — TypeScript library (xid by Leonardo Custodio); web-compatible Envelope serialization
Native Apps CLI tooling (bc-envelope-cli with XID operations); Garner system for publishing identity content
Terms Open research, BSD-2-Clause Plus Patent License
Funds Unknown — funded under Blockchain Commons general operating budget; specific XID allocation not separately published
Based On Gordian Envelope (controller documents); dCBOR (deterministic encoding); SHA-256 (inception-key-derived identifier); Provenance Marks (versioning); FROST (group signing); SSKR (recovery)
Authentication & Identity Self-certifying identifier — the XID is the SHA-256 hash of an inception public key, providing cryptographic proof of origin while allowing keys to be rotated without changing the identifier
Storage Model XID Documents resolved via dereferenceVia assertions (HTTPS resolvers, BTCR, IPFS, Hubert dead-drops, etc.); decentralized resolution; holders can publish elided versions to different recipients
Interoperability Inspired by but intentionally not conformant to W3C DID Core; standalone architecture leveraging Gordian stack; can encode dereferenceVia URIs to existing W3C DID resolvers as a bridge
Data Portability By design — identifier is portable (hash of inception key, no registry binding); controller document portable via Envelope encoding; selective-disclosure subsets cryptographically verifiable independent of full document
Governance & Decision Making Holder-controlled — architectural commitment that the identifier holder, not the issuer, controls disclosure; this is fundamentally a different governance model from issuer-mediated SSI flows
Identity Standards Self-defined (Blockchain Commons Research papers BCR-2024-010 and BCR-2026-003); not W3C DID Core; not OIDC
DID Methods Supported XIDs are not a DID method; XID Documents can reference other DID-resolvable URIs via dereferenceVia
Key Management Inception key + rotated keys with permission flags; FROST threshold signing for group XIDs; SSKR recovery shares
Credential Types Edges (BCR-2026-003) — signed Envelope-wrapped attestations between XIDs forming a web-of-trust graph; can carry any Envelope-encodable credential format
Verification Method Cryptographic verification via Envelope signatures; controller document elision preserves Merkle digest for proof of original content
Privacy Features Selective elision per recipient (Merkle-tree privacy); holder-controlled disclosure rather than issuer-controlled; non-correlation across contexts via tailored documents
Authentication Methods Public-key signatures rooted in XID-document keys; Permits (Envelope encryption) for confidential exchanges
Revocation Mechanism Key rotation (XID stable across rotations); permission flag updates in controller document; provenance-mark-chained Editions track XID Document versions
Agent Types Supported People, organizations, devices, applications, abstract entities — domain-agnostic
Wallet/Client Types CLI tooling; reference apps in development; Garner publishing system
Recovery Mechanisms SSKR-based shard recovery; FROST threshold-based recovery; multi-key inception possible
Compliance / Regulations Not yet evaluated — XID is a research note (BCR-2024-010) rather than a standardized identity protocol; architectural design supports privacy-by-design and data-minimization principles compatible with GDPR
Credential Exchange Protocols Envelope-native — assertions exchanged as Envelope artifacts; could be carried over DIDComm or other credential exchange protocols if wrapped in those formats
Trust Framework Self-sovereign — no central authority; web-of-trust via Edges (BCR-2026-003); Permits for context-specific trust
Cost Model No cost (self-generated); resolution costs depend on chosen dereferenceVia method
Censorship Resistance High — autonomous identifier generation, decentralized resolution options including Hubert dead-drops on BitTorrent/IPFS