OOBI (Out-of-Band Introduction) Protocol

Identity Protocol

A formal protocol specification (IETF Internet-Draft) defining a mechanism for introducing KERI Autonomic Identifiers (AIDs) to witness, watcher, and service endpoints via URL-based out-of-band exchanges. An OOBI is a URL pairing an AID with a network endpoint (IP address or URL) that can provide or cache the associated KERI Key Event Log (KEL). OOBIs enable KERI participants to bootstrap identifier discovery without a centralized directory, allowing any party with the OOBI URL to locate and verify another party's key state.

Community
Links
Visit Community Suggest an edit

Details

License Open specification (IETF I-D); reference implementations in KERI Python (keripy) and Rust (keri-core) under Apache-2.0
Dev Status 🟢 Active
Dev Status Detail Released (implemented in production KERI tooling including KERIA, keripy, and the WebOfTrust reference implementations; IETF Internet-Draft active)
Owner Samuel M. Smith (spec author); IETF Internet-Draft (draft-ssmith-oobi); KERI community
Governing Body IETF (Internet-Draft draft-ssmith-oobi) | None (single specification author; KERI community)
Country USA (Samuel M. Smith)
Start Year 2021
Stack Language-agnostic (IETF specification); implemented in Python (keripy / KERIA), TypeScript (signify-ts), Rust; HTTP URLs as the OOBI format
Funding Community / DARPA (KERI ecosystem funded partly by DARPA and DIF grants; OOBI spec funded as part of KERI development)
Last Investigated Jul 1, 2026

Use Case Domains

Identity & Trust

Affordances

Trust graph portability Sovereign identity

Identity Protocol Attributes

Origins KERI ecosystem bootstrap (designed to solve KERI's identifier discovery problem — KERI AIDs are self-certifying but need a mechanism for parties to locate each other's key event logs without a central directory)
Database N/A (OOBIs point to endpoints that serve KELs; no database defined by the OOBI spec itself)
Query Language HTTP URL resolution (OOBI is a URL; resolution fetches KEL from specified endpoint via HTTP GET)
Data Formats OOBI URL (format: scheme://host:port/oobi/{AID}/{role}/{eid}); KERI CESR (Composable Event Streaming Representation) for KEL data returned by endpoints
Mobile Support Library-level (any HTTP client; QR code OOBI sharing common in mobile KERI wallet implementations)
Web Support Yes (OOBI URLs are HTTP/HTTPS; web-based KERI wallets resolve OOBIs via standard HTTP)
Native Apps Library-level (embedded in KERI wallet applications; QR code OOBI sharing in mobile wallet UIs)
Terms Free / Open standard (IETF Internet-Draft; Apache-2.0 reference implementations)
Funds Unknown (part of broader KERI ecosystem funding; not separately itemized)
Based On KERI (Key Event Receipt Infrastructure) — OOBI is the bootstrap/discovery mechanism for KERI identifiers; HTTP URL format; CESR (Composable Event Streaming Representation) for KEL data
Permissions Key-based (OOBI is an open URL; AID key control governs what can be done with the discovered identity)
Authentication & Identity KERI AID-based (OOBI introduces a KERI AID to its endpoint; authentication is via KERI key event log verification, not OOBI itself)
Storage Model N/A (OOBI points to endpoints; storage is at the KERI witness/watcher infrastructure level)
Interoperability KERI ecosystem (OOBI is specific to KERI AID discovery; compatible with any KERI-conformant implementation)
Data Portability Full portability (OOBIs can be exchanged out-of-band via any channel — QR code, email, chat, NFC — enabling key state discovery independently of platform)
Governance & Decision Making Community / IETF process (IETF Internet-Draft; community-governed; Sam Smith as spec author)
Protocol Maturity / Standardization IETF Draft (active IETF Internet-Draft draft-ssmith-oobi; implemented in production KERI tooling; not yet published as RFC)
Identity Standards KERI (Key Event Receipt Infrastructure); W3C DID (KERI AIDs can be expressed as DIDs); CESR (Composable Event Streaming Representation)
DID Methods Supported did:keri (KERI AIDs as DIDs; OOBI is the discovery mechanism for did:keri resolution)
Key Management Delegated to KERI (OOBI locates the key event log; KERI manages key rotation, pre-rotation, and recovery via the KEL)
Credential Types N/A (OOBI is a discovery/bootstrap protocol; credential types defined at KERI/ACDC layer)
Verification Method Key event log verification (OOBI URL leads to KEL; cryptographic verification of key binding performed by KERI resolver, not OOBI itself)
Privacy Features Minimal (OOBI URLs may expose AID and endpoint; out-of-band exchange (QR code, direct link) limits exposure; no ZKP features)
Authentication Methods QR code scanning (common OOBI exchange mechanism in wallets); Deep linking (OOBI URL passed via any channel); HTTP GET resolution
Revocation Mechanism N/A (OOBI is a discovery URL; revocation handled at KERI key event log level)
Agent Types Supported Any KERI-identified entity: Humans (individuals), Organizations, Services/APIs, Devices/IoT
Wallet/Client Types SDK/Library integration (keripy, signify-ts, KERIA server); QR code exchange in mobile wallets
Recovery Mechanisms N/A (recovery handled at KERI level via key event history and pre-rotation)
Compliance / Regulations Unknown (IETF Internet-Draft; no specific regulatory compliance addressed)
Credential Exchange Protocols KERI/ACDC (Authentic Chained Data Containers); compatible with DIDComm via KERI DID method
Trust Framework Cryptographic verification only (OOBI points to KEL; trust established through KERI key event log cryptographic verification; no external trust anchor)
Cost Model Free (open IETF Internet-Draft; open source implementations)
Censorship Resistance Hybrid (OOBI URLs depend on endpoint availability; multiple OOBIs can be provided for same AID via different witnesses/watchers; resilient via multi-witness architecture)