SKWA (Simple KERI for Web Auth) is a usability-focused implementation of the KERI protocol designed for private cloud deployments that deliberately sacrifices performance and feature completeness for ease of integration while maintaining full security guarantees for all supported features.
Related Concepts
No related concepts available
Comprehensive Explanation
simple-keri-for-web-auth
Implementation Overview
SKWA (Simple KERI for Web Auth) represents a specialized implementation philosophy within the KERI ecosystem that prioritizes usability and simplicity over performance optimization and feature completeness. Unlike comprehensive KERI implementations like KERIpy or KERIox, SKWA is designed for narrow application scenarios where the full feature set of the KERI protocol is not required.
Core Implementation Philosophy
The fundamental principle underlying SKWA is that not all KERI applications require all KERI features, but any features that are implemented must maintain the full security properties that make KERI viable for decentralized identity systems. This creates a deliberate trade-off space:
What is sacrificed: Performance optimization, advanced features, protocol completeness
What is gained: Simplified integration, reduced complexity, easier adoption for web authentication use cases
SKWA is explicitly designed for private cloud environments, sharing this deployment model with Keep. This contrasts sharply with Signify, which targets public cloud deployments. The private cloud focus suggests SKWA is optimized for controlled enterprise or organizational environments where infrastructure is managed internally and trust boundaries are more clearly defined.
Implementation Notes
Critical Implementation Considerations
Security Guarantees
Non-Negotiable Properties: Despite SKWA's simplified nature, implementers MUST preserve:
Generate KELs that are valid according to KERI specification
Use standard CESR encoding for all cryptographic primitives
Support verification by other KERI implementations
Maintain compatibility with KERI witness protocols
Performance Considerations
Trade-off Awareness: Implementers should understand:
SKWA prioritizes usability over performance - this is intentional
Simplified implementation may have higher per-request overhead than optimized implementations
Relationship to KERI Protocol
SKWA is not a separate protocol but rather a focused implementation of the core KERI specification. It implements a subset of KERI's capabilities while maintaining compatibility with the broader KERI ecosystem. This means:
SKWA-generated AIDs (Autonomic Identifiers) are valid KERI identifiers
KELs (Key Event Logs) produced by SKWA can be verified by any KERI-compliant validator
SKWA can interoperate with other KERI implementations through standard protocols
SKWA's primary use case is web authentication, providing cryptographically verifiable identity for web applications without requiring the full complexity of enterprise-grade KERI deployments. The implementation focuses on:
Request Authentication: SKWA integrates with KRAM (KERI Request Authentication Method) to provide replay attack protection for web clients. KRAM requires:
All requests from web clients must include a datetime string field in the request body
The datetime must be formatted according to ISO-8601 standard
The server validates that the timestamp falls within an acceptable time window relative to its current system time
Requests with timestamps outside this window are rejected, preventing attackers from replaying captured requests
This timestamp-based validation creates a form of non-interactive authentication that is simple to implement but effective against replay attacks, which are a primary concern in web authentication scenarios.
Simplified Key Management
While SKWA maintains KERI's core security properties, it likely simplifies key management operations:
Reduced witness pool complexity: Private cloud deployments may use fewer witnesses with simpler threshold configurations
Streamlined rotation procedures: Focus on common rotation scenarios rather than supporting all possible establishment event configurations
End-Verifiability: SKWA maintains the property that any party can independently verify the authenticity of identifiers and events without relying on trusted intermediaries.
Installation & Setup
While specific installation procedures are not detailed in the available documentation, SKWA is maintained in the WebOfTrust SKWA GitHub repository. Based on the implementation context:
Expected Deployment Model
Private Cloud Infrastructure: SKWA is designed for deployment in controlled environments:
Internal enterprise networks
Organizational identity systems
Private authentication services
Controlled API access systems
Integration Points: As a web authentication system, SKWA likely provides:
REST API endpoints for authentication requests
Integration with existing web application frameworks
Support for standard web authentication flows
Compatibility with KERI ecosystem tools
Dependencies
As a KERI implementation, SKWA requires:
Cryptographic Libraries: Support for KERI's cryptographic primitives:
SKWA represents an important implementation philosophy within the KERI ecosystem: not every application needs every feature, but every feature must be secure. By focusing on web authentication in private cloud environments, SKWA provides a simplified entry point to KERI's powerful decentralized identity capabilities while maintaining the cryptographic guarantees that make KERI trustworthy.
The implementation demonstrates that KERI's modular architecture supports a spectrum of implementations, from full-featured reference implementations like KERIpy to focused, use-case-specific implementations like SKWA. This flexibility enables KERI to serve diverse deployment scenarios while maintaining interoperability and security across the ecosystem.
For organizations seeking to adopt KERI for internal web authentication without the complexity of public cloud deployments, SKWA offers a pragmatic path forward that balances usability with the security properties that make decentralized identity viable.
Private cloud deployment enables caching and optimization strategies not available in public cloud
Witness validation may be simplified but must not compromise security
Feature Subset Selection
Supported Features: When implementing SKWA, carefully select which KERI features to support:
Core features: Inception, rotation, interaction events are essential
Advanced features: Complex delegation, multi-signature configurations may be simplified or omitted
Security features: Pre-rotation, witness validation, duplicity detection must be fully supported
Documentation: Clearly document which KERI features are and are not supported