Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 11 GitHub source documents. All source documents are searchable here.
Last updated: October 7, 2025
This content is meant to be consumed by AI agents via MCP. Click here to get the MCP configuration.
Note: In rare cases it may contain LLM hallucinations.
For authoritative documentation, please consult the official GLEIF vLEI trainings and the ToIP Glossary.
A category of authentication mechanisms requiring bidirectional communication through multiple request-response cycles, typically using challenge-response patterns where one party issues a challenge that the other must correctly respond to, providing enhanced security through dynamic verification.
Interactive authentication design represents a fundamental approach to verifying identity and authorization in distributed systems through multi-step communication protocols. Unlike non-interactive authentication design, which relies on self-authenticating requests, interactive designs mandate a series of exchanges between parties—typically a challenger and a responder—before authentication succeeds.
The core principle involves challenge-response mechanisms: one party (the challenger) issues a challenge that the other party (the responder) must answer correctly to prove their identity or authorization. This pattern creates a dynamic verification process where each authentication attempt is unique, making replay attacks significantly more difficult.
Key properties of interactive authentication include:
Interactive authentication has deep roots in cryptographic protocol design, predating modern digital identity systems. Traditional examples include:
Password-based challenge-response: Early systems where servers would issue random challenges that clients must combine with passwords to generate correct responses. This prevented password transmission in cleartext while still verifying knowledge of the password.
Nonce-based protocols: Cryptographic protocols using "numbers used once" (nonces) to ensure each authentication attempt is unique. The challenger generates a random nonce, the responder signs it with their private key, and the challenger verifies the signature using the responder's public key.
Challenges must be cryptographically unique to prevent collision attacks. Use CSPRNG sources with sufficient entropy (minimum 128 bits). Include timestamps to enable timeout enforcement and prevent replay of entire challenge-response exchanges.
Maintain pending challenge state with appropriate timeouts (typically 30-300 seconds depending on network conditions). Implement state cleanup to prevent memory exhaustion from abandoned challenges. Consider using time-based eviction rather than explicit cleanup to simplify implementation.
Always verify the responder's current key state from their KEL before accepting responses. Account for potential rotations that may have occurred between challenge issuance and response receipt. Cache KEL state with appropriate TTLs to balance performance and freshness.
For high-security scenarios, require witness receipts as part of the response. Verify that the responder's key events have been properly witnessed according to their threshold of accountable duplicity (TOAD).
Implement graceful degradation when interactive protocols fail due to network issues or timeouts. Consider fallback to non-interactive authentication for non-critical operations. Provide clear error messages distinguishing between authentication failures and protocol failures.
For high-volume scenarios, consider connection pooling and challenge pre-generation to reduce latency. Implement challenge batching for scenarios requiring multiple authentications. Use asynchronous I/O to prevent blocking on network operations.
Zero-knowledge proofs: Advanced interactive protocols where one party proves knowledge of a secret without revealing the secret itself, requiring multiple rounds of challenge-response interaction.
Historically, interactive authentication was considered the "gold standard" for security because:
However, interactive approaches also introduced significant limitations:
The KERI ecosystem supports both interactive and non-interactive authentication designs, recognizing that different use cases demand different trade-offs. The KERI Request Authentication Mechanism (KRAM) specification by Samuel Smith details how both paradigms function within KERI-based systems.
When KERI systems employ interactive authentication, they leverage KERI's unique properties:
Key Event Log (KEL) as Trust Basis: Interactive authentication in KERI doesn't just verify a single key—it verifies the entire key state derived from the KEL. The challenger can verify that the responder controls the current authoritative keys for an AID, accounting for any rotations that have occurred.
Witness-backed verification: Interactive protocols can incorporate witness receipts into the challenge-response flow. A challenger might require not just a signature from the controller, but also witness receipts proving the key event has been witnessed and is part of the authoritative KERL.
Delegation-aware authentication: For delegated identifiers, interactive authentication can verify the entire delegation chain. The challenger issues challenges that require proof of both the delegate's authority and the delegator's authorization.
KERI systems typically employ interactive authentication for:
Initial establishment: When two parties first establish a relationship, interactive protocols provide stronger assurance. The challenger can verify the responder's current key state, witness configuration, and delegation status through multiple exchanges.
High-stakes operations: Operations like key rotation, delegation, or witness pool changes may require interactive authentication to ensure the controller is actively present and authorizing the operation.
Mutual authentication scenarios: When both parties need to verify each other's identities, interactive protocols enable symmetric challenge-response where each party challenges the other.
Real-time verification requirements: Applications requiring immediate confirmation of identity (e.g., live video calls, real-time transactions) benefit from interactive authentication's synchronous nature.
KERI's support for non-interactive authentication design provides an alternative optimized for different scenarios:
Scalability: Non-interactive authentication enables massive scale by eliminating the need for real-time bidirectional communication. A single server can verify thousands of self-authenticating requests without maintaining challenge state.
Path-independent verifiability: Non-interactive requests can be verified by any party with access to the KEL, not just the original challenger. This enables end-verifiable audit trails and third-party verification.
Asynchronous operation: Non-interactive authentication works in store-and-forward scenarios where parties aren't simultaneously online, critical for decentralized applications.
The KRAM specification details how KERI achieves replay attack protection in non-interactive designs through timestamp-based mechanisms, reducing (but not eliminating) the security advantages of interactive approaches.
Secure session establishment: When establishing a secure communication channel between two agents, interactive authentication provides strong mutual verification. Each agent challenges the other to prove control over their respective AIDs, verifying current key state and witness backing.
Credential issuance: When a Qualified vLEI Issuer (QVI) issues a vLEI credential, interactive authentication can verify the applicant's identity through multiple challenge-response rounds, potentially incorporating out-of-band verification steps.
Witness pool updates: When a controller modifies their witness pool, interactive authentication with existing witnesses can confirm the controller's intent and prevent unauthorized changes.
Delegation authorization: When a delegator authorizes a new delegate, interactive authentication ensures the delegator is actively present and approving the delegation, not merely replaying a previous authorization.
Enhanced security: Interactive protocols provide stronger protection against replay attacks through unique per-session challenges. Even if an attacker captures a valid response, it cannot be reused for subsequent authentication attempts.
Freshness guarantees: Challenges can include timestamps or nonces that prove the response was generated recently, preventing attacks using stale credentials.
Mutual authentication: Both parties can verify each other through symmetric challenge-response, establishing bidirectional trust.
Flexible verification: Challengers can request specific proofs (e.g., witness receipts, delegation chains) tailored to the security requirements of each interaction.
Scalability limitations: Interactive authentication requires maintaining state for pending challenges, limiting the number of concurrent authentication attempts a system can handle. This becomes problematic in high-volume scenarios like public APIs or large-scale credential verification.
Latency multiplication: Each round-trip adds network latency. A three-round protocol over a 100ms network connection requires 300ms minimum, impacting user experience.
Synchronous requirements: Both parties must be online simultaneously, preventing asynchronous workflows common in decentralized systems.
Complexity: Implementing interactive protocols correctly requires careful state management, timeout handling, and protection against various attack vectors (e.g., challenge flooding, state exhaustion).
Limited verifiability: Only the original challenger can verify the authentication. Third parties cannot independently verify that authentication occurred without trusting the challenger's attestation.
When implementing interactive authentication in KERI systems:
Challenge uniqueness: Ensure challenges are cryptographically unique (using CSPRNGs) to prevent collision attacks.
Timeout management: Implement reasonable timeouts for pending challenges to prevent state exhaustion attacks while accommodating network latency.
KEL verification: Always verify the responder's current key state from their KEL before accepting responses, accounting for potential rotations.
Witness integration: Consider requiring witness receipts as part of the response to ensure the responder's key events are properly witnessed.
Replay protection: Even in interactive protocols, include timestamps or sequence numbers to prevent replay of entire challenge-response exchanges.
Graceful degradation: Design systems to fall back to non-interactive authentication when interactive protocols fail due to network issues or timeout.
The choice between interactive and non-interactive authentication in KERI systems ultimately depends on the specific security requirements, scalability needs, and operational constraints of each application. KERI's architecture supports both paradigms, enabling developers to select the appropriate approach for each use case.