An Out-of-Band (OOB) Invitation is a foundational concept in decentralized identity and secure communication protocols, most notably within the W3C Decentralized Identifiers (DIDs) and Verifiable Credentials ecosystem. It is a message, often encoded as a QR code or a deep link, that contains all the cryptographic information necessary for one entity (the inviter) to initiate a trusted connection with another (the invitee). The "out-of-band" designation means this invitation is transmitted through a separate, often more secure or user-verifiable channel—such as scanning a QR code in person, using NFC, or sharing via email—distinct from the eventual encrypted digital channel that will be established.
LABS
Glossary
Out-of-Band Invitation
An out-of-band invitation is a secure message, often a QR code or URL, that initiates a connection protocol between decentralized identity agents.
Chainscore © 2026
definition
DECENTRALIZED IDENTITY
What is an Out-of-Band Invitation?
A secure method for establishing a digital connection between two parties without relying on a shared, pre-existing digital channel.
The core purpose of an OOB invitation is secure peer discovery and connection setup. It typically contains the inviter's public DID, their DID Document endpoint, and a one-time-use cryptographic key or nonce. When the invitee accepts the invitation, their wallet or agent uses this information to locate the inviter's DID Document, retrieve their public keys, and establish an encrypted communication channel, often using the DIDComm protocol. This process ensures that the initial connection is not susceptible to man-in-the-middle attacks that could occur if the parties were trying to find each other solely through an insecure, in-band network.
In practical applications, OOB invitations are the primary user experience for initiating peer-to-peer relationships in decentralized systems. Common examples include: a verifier presenting a QR code for a citizen to scan with their digital wallet to receive a credential; two mobile wallets establishing a connection to exchange verifiable presentations; or a new employee onboarding to a corporate identity system. By leveraging a user-verifiable channel for the initial handshake, OOB invitations provide a critical layer of trust and security that is essential for the self-sovereign identity (SSI) model, where users control their own identifiers and data exchanges.
how-it-works
DECENTRALIZED IDENTITY
How an Out-of-Band Invitation Works
An out-of-band (OOB) invitation is a foundational mechanism in decentralized identity systems for establishing a secure, private connection between two parties without relying on a central directory or intermediary.
An out-of-band invitation is a cryptographically secure message, typically containing a DIDComm or peer DID, that is transmitted via a non-primary communication channel to initiate a trusted connection. In the context of Self-Sovereign Identity (SSI) and the W3C Decentralized Identifiers (DIDs) standard, this process allows an issuer (e.g., a university) to send an invitation to a holder (e.g., a student) through an external channel like email, QR code, or SMS. The invitation itself contains the metadata needed for the recipient's digital wallet to establish a direct, encrypted communication channel back to the sender, enabling the subsequent exchange of verifiable credentials.
The core technical components of an OOB invitation include a unique invitation URL or a scannable QR code that embeds a DID and a service endpoint. When the recipient's wallet processes this invitation, it performs a DID resolution to discover the sender's public keys and service endpoints. This allows the two agents to engage in a DIDComm protocol, establishing a mutually authenticated, encrypted peer-to-peer messaging channel. This channel is out-of-band because its setup is independent of the main credential issuance or presentation flow, enhancing security by preventing man-in-the-middle attacks that could occur if the connection details were exchanged in-band.
A common real-world example is a conference check-in. An organizer generates an OOB invitation encoded in a QR code. An attendee scans the code with their identity wallet, which establishes a secure connection back to the organizer's system. Through this private channel, the organizer can then issue a verifiable credential for event access, which the attendee stores in their wallet. This pattern is fundamental to passwordless authentication, secure onboarding, and any process requiring a trusted introduction without pre-existing digital relationships, forming the bedrock of user-centric identity ecosystems.
key-features
DIDCOMM PROTOCOL
Key Features of Out-of-Band Invitations
Out-of-Band (OOB) Invitations are a foundational mechanism in the DIDComm protocol for establishing secure, private communication channels between decentralized identities. They enable one party to initiate a connection by sharing a cryptographically verifiable invitation through any external channel.
01
Channel-Agnostic Delivery
The defining feature of an OOB invitation is its independence from the communication channel used for its delivery. The invitation itself is a portable data object (e.g., a URL, QR code, or NFC payload) that can be transmitted via email, SMS, a physical printout, or any other medium. This separates the invitation transport from the subsequent encrypted DIDComm messaging channel that is established.
02
Cryptographic Handshake Initiation
An OOB invitation contains the cryptographic material necessary to bootstrap a secure connection. It typically includes:
- The inviter's public DID or a newly generated peer DID.
- A DIDComm service endpoint (the URL for future messages).
- A one-time-use invitation key for the initial encrypted response. This allows the recipient to immediately begin a DID Exchange or Connection protocol flow to establish mutual authentication.
03
Decentralized Identity Foundation
OOB invitations are a core component of Self-Sovereign Identity (SSI) architectures. They enable entities controlled by W3C Decentralized Identifiers (DIDs) to discover and connect without relying on a central directory or pre-existing relationship. This is critical for verifiable credential issuance, peer-to-peer agent communication, and secure interactions in decentralized ecosystems.
04
Protocol Agnosticism
While standardized within Aries RFC 0434, the OOB invitation pattern is protocol-agnostic. It serves as a universal "on-ramp" that can initiate various subsequent interaction protocols. After the connection is established, the parties can seamlessly proceed to protocols like:
- Present Proof for credential verification.
- Issue Credential for credential issuance.
- Basic Message for general communication.
05
Security & Trust Establishment
OOB invitations facilitate a trust-on-first-use model with cryptographic guarantees. The security derives from:
- Verifiable authenticity of the invitation contents via DIDs.
- Confidentiality of the subsequent channel using the invitation key.
- Resistance to replay attacks through one-time-use keys and protocol nonces. The trust in the initial connection is based on the security of the OOB delivery channel (e.g., trusting a QR code scanned in person).
06
Example: QR Code for Physical Verification
A common real-world implementation is a QR code displayed at an airport kiosk for digital health credential verification. The QR code encodes an OOB invitation containing the verifier's DID and endpoint. A traveler's wallet app scans the code, establishes a secure DIDComm channel, and then receives a presentation request for their vaccination credential, all without pre-registration or app-specific integrations.
common-formats
OUT-OF-BAND INVITATION
Common Formats & Encodings
Out-of-Band (OOB) Invitations are a method for establishing secure, peer-to-peer connections between decentralized applications (dApps) and wallets without requiring users to scan a QR code. This glossary covers the core formats and encodings used to transmit these invitations.
02
Deep Linking
OOB invitations use mobile deep links to trigger wallet applications directly from a browser or another app. When a user clicks a wc:// URI, the mobile OS attempts to open the registered wallet app, passing the full invitation payload. This requires the wallet to declare support for the wc URL scheme in its app manifest. It enables a seamless "click to connect" flow, bypassing the need for manual QR code handling.
03
Base64 Encoding
For transmission over channels that may not support raw binary data or special URI characters, the connection payload is often Base64-encoded. This encoding converts binary data into an ASCII string, making it safe for inclusion in URLs, JSON bodies, or text messages. The wallet receiving the invitation must decode the Base64 string to retrieve the original URI or JSON-RPC endpoint and symmetric key needed to establish the connection.
04
JSON-RPC Relay Payload
At its core, an OOB invitation contains a JSON-RPC payload specifying how to connect to a relay server. The encoded data includes:
relay.protocol: The communication protocol (e.g.,wakuorirn).relay.data: The relay server URL.symKey: The symmetric key for end-to-end encryption.peerMeta: Metadata about the dApp (name, URL, description). This structured data is serialized, often URL-encoded, and embedded within the invitation URI.
05
Platform-Specific Handoff (iOS/Android)
Different mobile operating systems have specific mechanisms for OOB handoffs:
- iOS: Uses Universal Links (for HTTPS) or Custom URL Schemes (e.g.,
wc://). AirDrop can transmit the invitation as a text file. - Android: Uses Android App Links or Intent Filters for custom URI schemes. Nearby Share can be used for proximity-based transfer. These mechanisms ensure the invitation is delivered to the correct wallet application on the user's device.
06
Security & Integrity
OOB invitations maintain security through:
- End-to-End Encryption: The
symKeyin the invitation establishes a secure channel via the relay. - Topic Uniqueness: Each session uses a unique, unguessable topic to prevent collision attacks.
- Relay Authentication: The invitation specifies a trusted relay server, though the connection payload itself is encrypted. The primary risk is invitation interception during transmission, mitigated by using secure channels (e.g., HTTPS links, direct device-to-device transfer).
security-role
GLOSSARY SECTION
Security Role & Trust Establishment
This section defines the cryptographic and procedural mechanisms by which participants in a decentralized system establish their identity, authority, and trustworthiness without relying on a central authority.
Trust establishment in blockchain and decentralized systems replaces traditional, centralized credentialing with cryptographic proof and verifiable on-chain or off-chain attestations. This process is fundamental for defining security roles—such as validator, governor, or auditor—and ensuring that only authorized entities can perform sensitive operations like signing blocks, upgrading contracts, or accessing privileged data. The goal is to create a trust-minimized environment where roles are transparent, auditable, and resistant to impersonation.
A core method for establishing these roles is the Out-of-Band Invitation, a secure, non-protocol communication used to bootstrap trust for a new participant. Unlike an on-chain transaction, this invitation is typically delivered via a separate, authenticated channel (e.g., encrypted email, secure messaging app, or physical exchange). It contains cryptographically signed data—such as a public key, node ID, or a unique token—that the recipient uses to prove their legitimacy when they first connect to the network or join a private consortium.
The security of this model hinges on the initial trust anchor. For example, in a permissioned blockchain like Hyperledger Fabric, a network administrator might issue out-of-band invitations containing enrollment certificates to new member organizations. In validator set management for proof-of-stake networks, a genesis group might use secure communications to distribute the initial validator keys. The invitation itself must be tamper-evident and authenticated, often using digital signatures from a pre-established root of trust.
Once the invitation is redeemed, the system transitions to in-band, cryptographic verification for all subsequent interactions. The invited party uses their granted credentials to participate according to their role. This establishes a clear audit trail from the initial invitation to all on-chain actions, allowing anyone to verify the provenance and authority behind a node's operations. This process is critical for maintaining sybil resistance and ensuring the network's security perimeter is well-defined.
Real-world implementations vary: a decentralized autonomous organization (DAO) might use out-of-band invites to onboard multisig signers, while a zero-knowledge proof system could use them to distribute the initial proving keys for a trusted setup ceremony. The common thread is the separation of the high-trust bootstrap phase from the ongoing low-trust protocol operation, effectively minimizing the attack surface after initial configuration.
ecosystem-usage
GLOSSARY TERM
Protocols & Ecosystem Usage
An Out-of-Band Invitation is a method for establishing a secure, private communication channel between two parties by exchanging connection details through an external, non-blockchain medium.
01
Core Definition & Purpose
An Out-of-Band (OOB) Invitation is a foundational mechanism in decentralized identity and communication protocols, such as those defined by the Decentralized Identity Foundation (DIF). Its primary purpose is to bootstrap a peer-to-peer connection for secure message exchange without relying on a public ledger for discovery. This is achieved by sharing invitation details—like a DIDComm endpoint URL and a public DID—via QR codes, email, or messaging apps.
02
Technical Components
A standard OOB invitation contains several key pieces of data necessary for connection establishment:
@type: Specifies the protocol, e.g.,https://didcomm.org/out-of-band/2.0/invitation.id: A unique identifier for the invitation.from: The Decentralized Identifier (DID) of the inviter.body: A human-readable message.goal_code&goal: Define the purpose of the connection (e.g.,issue-vc).services: Contains the recipient's service endpoint for receiving messages, often using the DIDComm transport protocol.
03
Protocol Flow Example
The typical flow using an OOB invitation involves a clear, multi-step handshake:
- Invitation Creation: Alice's wallet generates an invitation payload with her DID and a service endpoint.
- Out-of-Band Transmission: Alice shares the invitation as a QR code for Bob to scan.
- Connection Request: Bob's wallet uses the details to send a DIDComm
connection-requestmessage directly to Alice's endpoint. - Response & Setup: Alice responds with a
connection-response, and both parties establish a cryptographic channel for all future communications, such as credential presentations.
04
Key Advantages
Using an OOB channel offers significant privacy and efficiency benefits over on-chain alternatives:
- Privacy-Preserving: Connection attempts and metadata are not broadcast on a public ledger, protecting the parties' social graph.
- Reduced On-Chain Footprint: Eliminates the need for writing connection states to a blockchain, saving gas fees and increasing scalability.
- User-Centric: The QR code method provides a familiar, intuitive user experience for initiating digital relationships.
- Interoperability: Serves as a standard entry point for various SSI (Self-Sovereign Identity) protocols, enabling wallets from different vendors to connect.
05
Use Cases in Digital Identity
OOB invitations are a critical enabler for real-world Verifiable Credential (VC) ecosystems:
- Credential Issuance: A university invites a student to receive a digital diploma.
- Selective Disclosure: A user scans a QR code from a verifier's website to present proof-of-age without revealing their full identity.
- Agent-to-Agent Setup: Establishing secure messaging channels between Identity Agents or Edge Agents in enterprise SSI architectures.
- IoT Device Pairing: Provisioning a new device by scanning a code to establish a secure management channel.
COMMUNICATION PROTOCOL
In-Band vs. Out-of-Band Invitations
Comparison of methods for establishing a secure, peer-to-peer connection between two entities in a decentralized identity or agent-based system.
| Feature / Characteristic | In-Band Invitation | Out-of-Band Invitation |
|---|---|---|
Primary Communication Channel | Uses the same, pre-existing secure channel (e.g., an existing DIDComm connection). | Uses a separate, external channel (e.g., QR code, deeplink, email, URL). |
Connection Bootstrap | Requires a prior relationship or shared context to exist. | Enables connection establishment from a 'cold start' with no prior relationship. |
Initial Trust Establishment | Relies on the security of the pre-existing channel. | Often uses cryptographic material (public keys, DIDs) embedded in the invitation for verification. |
Typical Use Case | Re-keying, rotating, or upgrading an existing connection. | Onboarding new users, initiating first contact, or public agent discovery. |
Protocol Examples | DIDComm | Aries RFC 0434 Out-of-Band Protocol, Hyperledger Aries OOB invitations. |
Resilience to Replay Attacks | ||
Human-Friendly Presentation | ||
Implementation Complexity | Lower | Higher |
OUT-OF-BAND INVITATION
Frequently Asked Questions
Common questions about out-of-band invitations, a key mechanism for establishing secure, private connections in decentralized identity systems.
An out-of-band invitation is a method for initiating a secure, verifiable connection between two parties in a decentralized identity system, such as one using DIDComm or W3C Decentralized Identifiers (DIDs), by transmitting the invitation data through a separate, trusted channel outside the primary protocol. This process typically involves one party (the inviter) generating an invitation object containing their public DID and a service endpoint, which is then shared with the invitee via email, QR code, or a direct message. The invitee uses this data to establish a private, encrypted communication channel, enabling the exchange of credentials and proofs without relying on a central directory. This method enhances privacy and security by preventing correlation and ensuring the initial handshake is authenticated.
OUT-OF-BAND INVITATION
Common Misconceptions
Clarifying frequent misunderstandings about the purpose, security, and use cases of out-of-band invitations in decentralized identity and verifiable credential systems.
An out-of-band (OOB) invitation is a method for initiating a secure, peer-to-peer connection between two entities (like a holder and issuer) outside the primary communication channel, often used in Decentralized Identity (DID) protocols. It works by one party generating a unique invitation payload—typically containing a DID, a public DIDComm endpoint, and a cryptographic challenge—and transmitting it via a separate, trusted medium (e.g., QR code, email, or a secure link). The recipient uses this payload to establish a direct, encrypted communication channel, enabling the exchange of verifiable credentials or other data without relying on a central directory. This process bootstraps trust for the initial interaction within a zero-trust network architecture.
ENQUIRY
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.
NDA Protected
Confidentiality24h Response
Time to ValueDirectly to Engineering Team
No Sales Fluff10+
Protocols Shipped
$20M+
TVL Overall