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
• Security properties like pre-rotation and witness validation remain intact

Key Features & Capabilities

Authentication Architecture

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
• Simplified delegation models: May support basic delegation without the full complexity of nested cooperative delegation

Private Cloud Optimization

The private cloud deployment model enables several architectural simplifications:

Controlled Infrastructure: Unlike public cloud deployments that must handle arbitrary network topologies and trust boundaries, SKWA can assume:

• Known network infrastructure
• Controlled service endpoints
• Simplified OOBI (Out-Of-Band Introduction) discovery
• Reduced need for complex watcher networks

Trust Model Simplification: Private cloud environments allow for:

• Pre-configured witness pools
• Known backer infrastructure
• Simplified key state verification
• Reduced ambient verifiability requirements

Security Guarantees

Despite its simplified nature, SKWA maintains critical KERI security properties:

Self-Certifying Identifiers: SKWA-generated AIDs remain cryptographically bound to their controlling key pairs, ensuring that:

• Identifiers are verifiable to their cryptographic root-of-trust
• No external authority can forge or hijack identifiers
• Control authority is provable through digital signatures

Duplicity Detection: The implementation preserves KERI's ability to detect conflicting key events:

• First-seen policy enforcement
• Witness agreement mechanisms
• KEL consistency validation

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:

• Ed25519 signature schemes
• Blake3 hashing algorithms
• CESR (Composable Event Streaming Representation) encoding

KERI Infrastructure: Connection to KERI ecosystem components:

• Witness services for event validation
• Watcher services for KEL monitoring (potentially simplified in private cloud)
• OOBI resolution for identifier discovery

Usage & API

While detailed API documentation is not provided in the available sources, the integration with KRAM suggests the following usage patterns:

Authentication Request Flow

Client Request Structure: Web clients making authenticated requests to SKWA-protected services must:

1. Generate an ISO-8601 formatted timestamp
2. Include the timestamp in the request body
3. Sign the request using their KERI AID
4. Submit the request with attached signatures

Server Validation Process: SKWA servers validate requests by:

1. Extracting the timestamp from the request body
2. Comparing against server time to ensure it falls within acceptable window
3. Verifying the cryptographic signature against the claimed AID
4. Checking the KEL for the AID to confirm current key state
5. Accepting or rejecting the request based on validation results

Identifier Management

AID Creation: SKWA likely provides simplified interfaces for:

• Generating new autonomic identifiers
• Creating inception events
• Configuring initial witness pools
• Establishing threshold requirements

Key Rotation: Support for basic rotation events:

• Rotating controlling key pairs
• Updating pre-rotated keys
• Modifying witness configurations
• Maintaining KEL integrity

Related Implementations

KERI Ecosystem Implementations

SKWA exists within a broader ecosystem of KERI implementations, each optimized for different use cases:

KERIpy: The Python reference implementation

• Full-featured KERI protocol implementation
• Supports all KERI features and extensions
• Used for production deployments like GLEIF vLEI
• More complex but more capable than SKWA

KERIox: Rust implementation

• Performance-optimized implementation
• Focus on efficiency and safety
• Suitable for resource-constrained environments
• Different trade-offs than SKWA's usability focus

Signify: Public cloud client

• Designed for public cloud deployments
• Minimizes client-side KERI complexity
• Contrasts with SKWA's private cloud model
• Different trust assumptions and architecture

Keep: UI/UX wallet

• Shares private cloud deployment model with SKWA
• Provides user interface for KERI operations
• May integrate with SKWA for authentication
• Complementary rather than competing implementation

Integration Patterns

SKWA can integrate with other KERI ecosystem components:

KERIA: KERI Agent in the cloud

• Provides agent services for KERI operations
• May serve as backend for SKWA deployments
• Handles complex KERI protocol operations
• Enables SKWA to remain simple while leveraging full KERI capabilities

CESR Libraries: Encoding support

• SKWA relies on CESR for data serialization
• Maintains compatibility with CESR-encoded data
• Enables interoperability across implementations

Witness Networks: Validation infrastructure

• SKWA connects to witness pools for event validation
• May use simplified witness configurations in private cloud
• Maintains compatibility with standard KERI witness protocols

Implementation Trade-offs

What SKWA Optimizes For

Ease of Integration: SKWA prioritizes:

• Simple API surface
• Reduced configuration complexity
• Straightforward deployment procedures
• Clear documentation and examples

Web Authentication Focus: Specialized for:

• HTTP/HTTPS request authentication
• Web application identity
• API access control
• Session management

Private Cloud Deployment: Optimized for:

• Controlled infrastructure
• Known network topology
• Simplified trust models
• Internal organizational use

What SKWA Sacrifices

Performance: SKWA may not optimize for:

• High-throughput scenarios
• Minimal latency requirements
• Resource-constrained environments
• Massive scale deployments

Feature Completeness: SKWA may not support:

• Advanced delegation hierarchies
• Complex multi-signature configurations
• All KERI protocol extensions
• Exotic cryptographic schemes

Public Cloud Capabilities: SKWA does not target:

• Arbitrary network topologies
• Untrusted infrastructure
• Public witness networks
• Maximum decentralization

Security Non-Negotiables

Regardless of simplifications, SKWA maintains:

Cryptographic Integrity: All supported features preserve:

• Self-certifying properties
• Non-repudiable signatures
• Verifiable event logs
• Duplicity detection capabilities

KERI Core Properties: Essential KERI characteristics remain:

• Autonomic identifier control
• Key event ordering
• Witness validation
• End-verifiability

Use Cases and Applications

Enterprise Authentication

SKWA is well-suited for:

Internal Web Applications: Organizations can use SKWA to:

• Authenticate employees to internal services
• Provide cryptographically verifiable identity
• Eliminate password-based authentication
• Enable self-sovereign identity within enterprise

API Access Control: SKWA enables:

• Verifiable API authentication
• Request replay protection via KRAM
• Cryptographic proof of authorization
• Audit trails of API access

Organizational Identity

Departmental Identifiers: SKWA can manage:

• AIDs for organizational units
• Delegated identifiers for sub-organizations
• Role-based identity within enterprises
• Hierarchical identity structures

Service Identities: Applications can use SKWA for:

• Machine-to-machine authentication
• Service-to-service communication
• Microservice identity
• Container and pod authentication

Development and Testing

KERI Prototyping: SKWA provides:

• Simplified environment for learning KERI
• Reduced complexity for proof-of-concept work
• Faster iteration on KERI-based applications
• Lower barrier to entry for developers

Integration Testing: Organizations can use SKWA to:

• Test KERI integration without full infrastructure
• Validate authentication flows
• Develop against KERI APIs
• Prototype identity-based applications

Architectural Considerations

Private Cloud Assumptions

SKWA's private cloud focus enables architectural simplifications:

Network Trust: Private clouds provide:

• Controlled network perimeters
• Known routing infrastructure
• Simplified OOBI discovery
• Reduced need for complex percolated discovery

Infrastructure Control: Organizations can:

• Pre-configure witness pools
• Establish known service endpoints
• Simplify watcher deployment
• Reduce ambient verifiability requirements

Security Model

SKWA maintains KERI's security properties while simplifying deployment:

Cryptographic Root-of-Trust: Even in simplified form, SKWA preserves:

• Self-certifying identifiers
• Cryptographic binding of identifiers to keys
• Verifiable control authority
• Non-repudiable event logs

Duplicity Detection: SKWA retains ability to detect:

• Conflicting key events
• Forked KELs
• Witness disagreement
• Invalid rotations

Scalability Characteristics

SKWA's trade-offs affect scalability:

Vertical Scaling: Simplified implementation may:

• Reduce per-request overhead
• Simplify caching strategies
• Enable straightforward optimization
• Support moderate load levels

Horizontal Scaling: Private cloud deployment enables:

• Load balancing across instances
• Shared witness infrastructure
• Coordinated key state caching
• Simplified consensus mechanisms

Future Directions

While specific roadmap details are not provided in available documentation, SKWA's position in the KERI ecosystem suggests potential evolution:

Feature Expansion

As SKWA matures, it may add:

• Support for additional KERI protocol features
• Enhanced delegation capabilities
• More sophisticated witness configurations
• Integration with emerging KERI standards

Ecosystem Integration

SKWA may increasingly integrate with:

• ACDC (Authentic Chained Data Container) for credentials
• IPEX for credential exchange
• TEL for credential registries
• Broader KERI ecosystem tools and services

Deployment Models

Future versions might support:

• Hybrid cloud deployments
• Edge computing scenarios
• Container-native architectures
• Serverless implementations

Conclusion

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.

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

Testing and Validation

Verification Requirements: SKWA implementations should:

• Test interoperability with other KERI implementations
• Validate KEL generation against KERI specification
• Verify KRAM timestamp validation under various clock skew scenarios
• Test duplicity detection capabilities
• Validate witness agreement mechanisms