did:scid

Identity Protocol

A DID method specification developed by the Trust over IP (ToIP) DID SCID Task Force that enables any Self-Certifying Identifier (SCID) format to be expressed as a W3C-conformant DID; the proposed formats are did:scid:vh (did:webvh), did:scid:ke (did:webs / KERI AIDs) and did:scid:jl (did:jlinc). It is technically a metamethod: it defines a namespace plus an optional 'src' query parameter carrying the location of the verification metadata, and delegates format, resolution and verification to the underlying source DID method. The method is designed to address portability and third-party independence: a SCID binds cryptographically to its controlling keys, requires no registry for verification, and can be stored locally or multi-anchored across locations. Supports both "pure" peer-to-peer SCIDs and web-hosted SCIDs with optional location parameters.

Community
Links
Visit Community

Details

License Open specification (ToIP Confluence wiki; no reference implementation repository separately identified)
Dev Status 🔨 WIP
Dev Status Detail WIP (specification under active development by ToIP DID SCID Task Force; not yet at Final status)
Owner Trust over IP (ToIP) Foundation — DID SCID Task Force; hosted under Linux Foundation; specification available on ToIP Confluence wiki
Governing Body ToIP / LF Decentralized Trust (DID SCID Task Force, within the Technology Stack Working Group) | DIF (DID Methods Working Group — standardization proposal submitted)
Country International (ToIP Foundation is Linux Foundation project; global contributor base)
Start Year 2024
Stack Language-agnostic specification (ABNF syntax definition only); resolution and verification reuse the source DID method's existing resolver code rather than introducing a new one (proposed formats: did:webvh, did:webs / KERI, did:jlinc); verification requires only access to the verification metadata — DID document and key event history
Funding Foundation (Linux Foundation / Trust over IP Foundation; member-funded)
Last Investigated Jul 1, 2026

Use Case Domains

Identity & Trust

Identity Protocol Attributes

Origins Self-sovereign identity / DID ecosystem (motivated by the proliferation of SCID-based DID methods — did:peer, did:webs (KERI AIDs), did:webvh, did:jlinc, did:plc — each of which binds its identifier to a particular storage location; did:scid unifies them under a single W3C DID method that preserves their shared property, cryptographic binding to keys without registry dependency, while decoupling the identifier from where its verification metadata lives)
Database N/A (verification requires no database; DID document and key event history carry all necessary information; multi-anchoring to multiple locations optional)
Query Language DID URL resolution (standard W3C DID resolution; location-parameterized variants resolve via HTTPS; pure peer-to-peer variants resolved from local storage)
Data Formats W3C DID Document (JSON-LD); SCID verification metadata (format depends on SCID type: KERI OOBI data, did:peer microledger, etc.)
Mobile Support Library-level (any DID resolver implementation; no dedicated mobile app)
Web Support Yes (web-hosted SCIDs use HTTPS for DID document hosting; pure SCIDs are location-independent)
Native Apps Library-level (embedded in DID resolver implementations; no standalone native app)
Terms Free / Open standard (ToIP specification; no licensing fees)
Funds Unknown (ToIP Foundation member contributions; specific task force budget not disclosed)
Based On W3C DID Core specification; RFC 3986 (URI syntax); source DID methods supplying its proposed formats — did:webvh (did:scid:vh), did:webs / KERI AIDs (did:scid:ke), did:jlinc (did:scid:jl); ToIP High Assurance VIDs Specification; W3C DID-Linked Resources (used for the optional cheqd blockchain hosting path)
Permissions Cryptographic Capabilities (key control determines all permissions; no ACL; delegation via key event history entries)
Authentication & Identity Self-Certifying Identifier (SCID) — identity derived from cryptographic key operations; no third party required for verification; portable across locations via multi-anchoring
Storage Model Local or distributed (pure SCIDs store verification metadata locally per peer; web-hosted SCIDs use HTTPS; multi-anchoring across multiple locations for resilience)
Interoperability W3C DID ecosystem (compatible with any W3C DID consumer); designed as an interoperability layer over existing SCID-based methods rather than a competitor to them — it reuses their formats and resolver code instead of defining new ones. Proposed formats: did:webvh, did:webs / KERI AIDs, did:jlinc. ToIP ecosystem. Appendix B addresses Bluesky's requirement for permanent immutable account identifiers; Appendix D specifies using the cheqd blockchain as a DID host via DID-Linked Resources
Data Portability Full portability (SCID is not bound to any location or provider; verification metadata portable; key rotation and revocation tracked in key event history)
Governance & Decision Making Foundation-governed (ToIP DID SCID Task Force under Linux Foundation governance; specification evolution via ToIP working group process)
Protocol Maturity / Standardization WIP (ToIP DID SCID Task Force specification; under active development; not yet submitted to W3C DID Methods Registry or other formal body)
Identity Standards W3C DID Core (Decentralized Identifiers 1.0); KERI (Key Event Receipt Infrastructure) for KERI-based variants; ToIP High Assurance VIDs
DID Methods Supported did:scid (defines this method). Proposed format registry (Appendix A, still a TODO): did:scid:vh → did:webvh verification metadata format; did:scid:ke → did:webs / KERI AID format; did:scid:jl → did:jlinc format. did:peer is explicitly NOT proposed as a format — the spec states did:scid:pr is not proposed because both vh and ke can also be used peer-to-peer while offering key rotation and other security features did:peer lacks
Key Management User-controlled (SCID cryptographically bound to controlling keys; key rotation tracked in key event history; pre-rotation supported via KERI-style commitments)
Credential Types N/A (DID method specification; does not define credential types; compatible with W3C VCs issued against did:scid identifiers)
Verification Method Cryptographic signature verification (SCID binding verified against key event history; no external registry or blockchain required; pure function on DID document + key history)
Privacy Features Unlinkability (pairwise DIDs possible; pure peer-to-peer SCID not published to any registry); minimal disclosure (verification metadata portable without revealing usage context)
Authentication Methods Cryptographic signatures (DID-based key control; challenge-response via standard DID authentication flows)
Revocation Mechanism Key event history (key rotation and revocation tracked in cryptographically chained key event log; KERI-style pre-rotation for forward secrecy)
Agent Types Supported Humans (individuals), Organizations, Devices/IoT, Services/APIs, Autonomous agents — any entity that can control cryptographic keys
Wallet/Client Types SDK/Library integration (any DID resolver library); compatible with KERI wallets and standard W3C DID wallets
Recovery Mechanisms Pre-rotation / Key event history (recovery keys committed in advance via KERI-style pre-rotation; M-of-N multisignature revocation possible with KERI variants)
Compliance / Regulations Unknown (specification does not address specific regulatory compliance; compatible with eIDAS and GDPR-aligned DID implementations)
Credential Exchange Protocols Compatible with DIDComm, OIDC4VC, and any protocol supporting W3C DID resolution
Trust Framework Cryptographic verification only (no external trust anchor required; trust established through cryptographic proof of key control; optional multi-anchoring for additional resilience)
Cost Model Free (no blockchain fees; no registry fees; pure cryptographic verification)
Censorship Resistance High but host-dependent (no central authority controls identifier validity, and multi-anchoring across diverse locations raises the cost of suppression; however publicly resolvable use still requires reaching at least one DID host, so availability depends on the hosts chosen. Pure peer-to-peer SCIDs with locally held verification metadata require no external service at all)