1. Secure Agent Initialization: Establishes a cryptographically verifiable delegation relationship between a Signify client's AID and a KERIA agent worker's AID through a three-step handshake protocol

2. Authenticated Request-Response: Defines message authentication patterns where all Admin Interface requests must be signed by the Client AID and all responses signed by the Agent AID, establishing bidirectional cryptographic verification

3. Key Management Lifecycle: Specifies procedures for passcode rotation, key derivation, and recovery operations that maintain security while enabling cloud-hosted agent services

Formal Specification References

SKRAP is documented in the KERIA protocol specification (commit 3e18975) and the Cardano Foundation KERIA fork. The protocol builds upon foundational KERI specifications:

• KERI Core Protocol: IETF draft-ssmith-keri defining KEL (Key Event Log) structures, establishment events, and witness coordination
• CESR Encoding: IETF draft-ssmith-cesr defining Composable Event Streaming Representation used for message encoding
• ACDC Credentials: IETF draft-ssmith-acdc defining Authentic Chained Data Container structures for verifiable credentials

Version History and Evolution

SKRAP represents the Mark II Agent server architecture for KERIA, succeeding earlier single-tenant agent designs. The protocol emerged from the need to support:

• Multi-tenant cloud infrastructure: Multiple users sharing KERIA server resources while maintaining cryptographic isolation
• Mobile and browser clients: Lightweight clients like mobile apps and KERIMask browser extensions that minimize KERI implementation complexity at the edge
• Hardware wallet integration: Support for HSMs (Hardware Security Modules) and hardware wallets where keys remain secured in hardware while connecting to cloud agents

The protocol continues to evolve as part of the broader KERI suite development, with ongoing refinements to support additional use cases and security requirements.

Protocol Architecture

Three-Interface Design

KERIA exposes three distinct HTTP endpoints on separate network interfaces, each serving a specific security boundary:

1. Boot Interface

The Boot Interface handles Agent Worker initialization and is designed for internal infrastructure access only. This interface:

• Exposes one endpoint for Agent Worker initialization
• Accepts out-of-band delivery of signed inception events to establish new client-agent relationships
• Can be exposed to internal infrastructure only or disabled entirely
• In static worker mode (all agent workers configured at startup), can be completely disabled

This separation allows the Boot Interface to be protected from external access while other interfaces remain publicly accessible, following defense-in-depth security principles.

2. Admin Interface

The Admin Interface provides the REST API for command and control operations from Signify clients. All requests must be signed by the Client AID using Signify Request Authentication. All responses are expected to be signed by the Agent AID, establishing bidirectional cryptographic verification.

The Admin Interface handles:

• AID creation and management operations
• Credential issuance and revocation through IPEX (Issuance and Presentation Exchange Protocol)
• Key state queries and updates
• Passcode rotation procedures
• Witness pool configuration

3. KERI Protocol Interface

The KERI Protocol Interface implements CESR over HTTP for KERI protocol interactions with external KERI ecosystem entities. This interface enables:

• Protocol-level KERI message exchange with witnesses, watchers, and other KERI infrastructure
• Key event propagation and receipt collection
• External credential exchange and verification operations through IPEX
• OOBI (Out-Of-Band Introduction) resolution

This three-interface design enables network-level security controls where administrators can expose interfaces to different network zones based on operational requirements.

Component Organization

The SKRAP architecture organizes components into three layers:

Edge Layer (Signify Clients)

Signify clients operate at the edge, performing:

• Key generation: Deriving cryptographic keys from user passphrases using Argon2 key stretching
• Event signing: Creating signed key events for inception, rotation, and interaction operations
• Credential signing: Signing ACDCs and presentation requests
• Local key storage: Maintaining encrypted keystores on client devices

Signify minimizes KERI implementation complexity at the edge, handling only cryptographic operations while delegating protocol complexity to KERIA agents.

Agent Layer (KERIA Workers)

KERIA agent workers provide:

• Protocol execution: Managing KEL construction, witness coordination, and duplicity detection
• State management: Maintaining current key state and credential status
• Event propagation: Distributing signed events to witnesses and collecting receipts
• OOBI resolution: Discovering and validating service endpoints for other KERI participants

Each agent worker is dedicated to a single Client AID, providing isolation in the multi-tenant architecture.

Infrastructure Layer (Witnesses, Watchers, Registrars)

The KERI infrastructure layer includes:

• Witnesses: Designated entities that verify, sign, and store key events, providing ambient verifiability
• Watchers: Entities maintaining KERL (Key Event Receipt Log) copies in promiscuous mode for duplicity detection
• Registrars: Backers for TEL (Transaction Event Log) credential registries

KERIA agents interact with this infrastructure layer through the KERI Protocol Interface.

Data Flow and Control Flow

SKRAP defines three primary data flows:

1. Initialization Flow

The initialization flow establishes the Client AID to Agent AID delegation:

1. Client generates Client AID: Signify derives keys from passphrase and creates signed inception event
2. Client submits to Boot Interface: Signed inception event delivered out-of-band to KERIA
3. Agent generates Agent AID: KERIA creates agent worker with delegated inception event
4. Client anchors delegation: Client creates interaction event anchoring the agent's delegated inception
5. Agent completes delegation: Agent propagates delegated inception to witnesses

This flow creates a cooperative delegation where both delegator and delegate must participate.

2. Request-Response Flow

The request-response flow handles operational commands:

1. Client signs request: Signify creates request body and attaches indexed signature from Client AID
2. Agent verifies request: KERIA validates signature against Client AID's current key state
3. Agent executes operation: KERIA performs requested operation (create AID, issue credential, etc.)
4. Agent signs response: KERIA attaches indexed signature from Agent AID
5. Client verifies response: Signify validates signature against Agent AID's current key state

This bidirectional authentication ensures both parties cryptographically verify all communications.

3. Event Propagation Flow

The event propagation flow distributes signed events to KERI infrastructure:

1. Client creates signed event: Signify generates and signs key event or credential operation
2. Agent receives event: KERIA accepts signed event through Admin Interface
3. Agent propagates to witnesses: KERIA distributes event to configured witness pool
4. Witnesses return receipts: Witnesses verify and sign event, returning receipts
5. Agent collects receipts: KERIA gathers sufficient receipts to satisfy threshold
6. Agent updates state: KERIA updates internal key state and returns confirmation to client

This flow leverages KERI's witness infrastructure for ambient verifiability.

State Management Approach

SKRAP employs a distributed state management model:

Client State

Signify clients maintain:

• Encrypted keystore: Salted and encrypted private keys derived from passphrase
• Local KEL cache: Recent key events for offline verification
• Agent AID state: Current key state of delegated agent for response verification

Agent State

KERIA agents maintain:

• Complete KEL: Full Key Event Log for the Client AID
• Witness receipts: Collected receipts from witness pool
• Credential registry: TEL state for issued credentials
• OOBI cache: Resolved service endpoints for other participants

Infrastructure State

Witnesses and watchers maintain:

• KERL: Key Event Receipt Log including all witnessed events and receipts
• Duplicity logs: DEL (Duplicitous Event Log) tracking any detected inconsistencies

This distributed state model enables end-verifiability where any party can independently verify the complete event history.

Message Formats & Encoding

CESR Encoding Foundation

All SKRAP messages use CESR (Composable Event Streaming Representation) encoding, which provides:

• Dual text/binary encoding: Messages can be represented in Base64 text or compact binary, with lossless conversion between domains
• Self-framing primitives: Each primitive includes length information, enabling streaming parsers
• Composability: Primitives can be concatenated and parsed without delimiters
• Qualified encoding: Each primitive includes a derivation code specifying its cryptographic algorithm

CESR encoding is specified in IETF draft-ssmith-cesr.

Message Types and Structure

Inception Event Message

The Client AID inception event establishes the initial key state:

Field Definitions:

• v: Version string - KERI protocol version ("KERI10JSON00012b_")
• t: Message type - "icp" for inception
• d: SAID (Self-Addressing Identifier) - digest of the event
• i: Identifier prefix - same as SAID for inception
• s: Sequence number - "0" for inception
• kt: Signing threshold - "1" for single-sig
• k: Current signing keys - array of qualified public keys
• nt: Next threshold - threshold for next rotation
• n: Next key digests - array of pre-rotated key digests
• bt: Witness threshold - "0" for no witnesses initially
• b: Witness identifiers - empty array initially
• c: Configuration traits - empty array
• a: Anchoring seals - empty array initially

Semantic Requirements:

• The d and i fields MUST be identical for inception events
• The s field MUST be "0" for inception
• The k array length MUST satisfy the kt threshold
• The n array length MUST satisfy the nt threshold
• Each key in k MUST be a qualified Base64 public key with derivation code
• Each digest in n MUST be a qualified Base64 digest of a pre-rotated public key

Delegated Inception Event Message

The Agent AID delegated inception event references the delegating Client AID:

Additional Field:

• di: Delegator identifier - Client AID prefix

Semantic Requirements:

• The di field MUST reference a valid Client AID
• The delegated inception MUST be anchored in the delegator's KEL through a seal
• The delegation becomes valid only after the delegator anchors it

This creates the cooperative delegation relationship where both parties must participate.

Interaction Event Message

Interaction events anchor external data without changing key state:

Field Definitions:

• v: Version string
• t: Message type - "ixn" for interaction
• d: SAID of the event
• i: Identifier prefix
• s: Sequence number - incremented from previous event
• p: Prior event digest - SAID of previous event in KEL
• a: Anchoring seals - array of seals to external data

Semantic Requirements:

• The s field MUST be exactly one greater than the previous event
• The p field MUST be the SAID of the immediately prior event
• The a array MAY contain seals anchoring delegated inceptions, credential operations, or other data

Rotation Event Message

Rotation events change the authoritative key set:

Field Definitions:

• v: Version string
• t: Message type - "rot" for rotation
• d: SAID of the event
• i: Identifier prefix
• s: Sequence number - incremented from previous event
• p: Prior event digest
• kt: New signing threshold
• k: New current signing keys
• nt: New next threshold
• n: New next key digests
• br: Witness remove list - witnesses to remove
• ba: Witness add list - witnesses to add
• a: Anchoring seals

Semantic Requirements:

• The new keys in k MUST correspond to the pre-rotated digests in the prior event's n field
• This enforces pre-rotation commitment
• The br and ba lists enable witness pool rotation

Encoding Schemes

SKRAP supports multiple serialization formats:

JSON Encoding

JSON (JavaScript Object Notation) encoding is the primary format for human-readable messages:

• Field maps use JSON object notation
• Arrays use JSON array notation
• Strings use JSON string encoding
• The version string specifies "JSON" in the format identifier

JSON encoding is used for:

• Admin Interface request/response bodies
• Human-readable event logs
• Configuration files

CBOR Encoding

CBOR (Concise Binary Object Representation) provides compact binary encoding:

• More compact than JSON for large messages
• Preserves field ordering for deterministic serialization
• Used for high-bandwidth protocol operations

CBOR encoding is specified in RFC 7049.

MessagePack Encoding

MessagePack provides an alternative binary format:

• Similar compactness to CBOR
• Widely supported across programming languages
• Used in some KERI implementations

Field Semantics

Version String Semantics

The version string encodes:

• Protocol version ("KERI10")
• Serialization format ("JSON", "CBOR", "MGPK")
• Message length in hexadecimal
• Underscore separator

Example: "KERI10JSON00012b_" indicates KERI 1.0, JSON format, 299 bytes (0x12b).

SAID Semantics

The SAID (Self-Addressing Identifier) provides:

• Content integrity through cryptographic digest
• Self-referential addressing where the SAID is included in the digested content
• Deterministic serialization ensuring consistent digest computation

SAID computation:

1. Serialize the message with SAID field set to a dummy value
2. Compute cryptographic digest (Blake3-256 by default)
3. Replace dummy value with qualified Base64 digest
4. The SAID is now cryptographically bound to the content

Threshold Semantics

Thresholds in KERI support:

• Simple thresholds: Integer count of required signatures ("1", "2", etc.)
• Weighted thresholds: Fractional weights for multi-sig schemes
• Threshold structures: Complex requirements for threshold signature schemes

SKRAP primarily uses simple thresholds for Client and Agent AIDs.

Protocol Mechanics

Agent Worker Initialization Handshake

The initialization handshake establishes the Client-Agent delegation through a three-step protocol:

Step One: Client AID Generation

The Signify client generates the Client AID as a transferable identifier with:

• Single signing key derived from passphrase
• Single rotation key (pre-rotated) derived from passphrase
• No initial witnesses (witness threshold = 0)

Key Derivation Algorithm:

1. Salt Generation: Generate 128-bit random salt
2. Passphrase Preparation: Prepend salt derivation code ('0A') and blank qualified Base64 character ('A') to 21-character passphrase
3. Key Stretching: Apply Argon2 to derive Ed25519 private keys:
   • Signing key path: signify:controller00
   • Rotation key path: signify:controller01
4. Public Key Derivation: Derive Ed25519 public keys from private keys
5. Digest Computation: Compute Blake3-256 digest of rotation public key
6. Qualification: Prepend derivation codes to create qualified Base64 representations

The signing public key and rotation key digest are included in the inception event.

Security Properties:

• The 128-bit salt provides information-theoretic security against rainbow table attacks
• Argon2 key stretching provides resistance to brute-force attacks
• Pre-rotation commitment prevents key compromise from enabling unauthorized rotation

Step Two: Agent AID Generation

The KERIA service generates the Agent AID as a delegated identifier:

1. Delegated Inception Creation: KERIA creates a delegated inception event with:

   • di field referencing the Client AID
   • Agent-controlled signing and rotation keys
   • Witness configuration for the agent

2. Delegation Seal: The delegated inception includes a seal to the delegating event in the Client AID's KEL

3. Agent Worker Initialization: KERIA initializes an agent worker dedicated to the Client AID

Security Properties:

• The Agent AID is cryptographically bound to the Client AID through the di field
• The delegation is not valid until the Client AID anchors it
• The agent cannot act independently without client participation

Step Three: Delegation Anchoring

The Signify client completes the delegation:

1. Interaction Event Creation: Client creates an interaction event with:

   • Seal anchoring the Agent AID's delegated inception
   • Sequence number incremented from inception
   • Prior event digest referencing the inception

2. Event Signing: Client signs the interaction event with the signing key

3. Event Submission: Client submits the signed interaction event to the Agent through the Admin Interface

4. Witness Propagation: Agent propagates both the Client's interaction event and the Agent's delegated inception to witnesses

5. Receipt Collection: Agent collects witness receipts for both events

Security Properties:

• The delegation becomes valid only after the client anchors it
• Both events must be witnessed to establish the delegation
• The cooperative delegation model ensures both parties must participate

Request Authentication Pattern

All Admin Interface requests use the Signify Request Authentication pattern:

Request Construction

1. Request Body Creation: Client constructs JSON request body with:

   • Operation identifier
   • Operation parameters
   • Timestamp for replay attack protection

2. Signature Generation: Client signs the request body with the Client AID's current signing key

3. Signature Attachment: Client attaches the indexed signature to the request

4. Request Transmission: Client sends the signed request to the Admin Interface

Signature Format:

• The signature is a qualified Base64 indexed signature
• The index indicates which key from the current key set was used
• For single-sig AIDs, the index is always 0

Request Verification

1. Signature Extraction: Agent extracts the indexed signature from the request

2. Key State Retrieval: Agent retrieves the Client AID's current key state from the KEL

3. Signature Verification: Agent verifies the signature against the current signing key

4. Timestamp Validation: Agent validates the timestamp is within acceptable window

5. Operation Authorization: Agent verifies the Client AID is authorized for the requested operation

Security Properties:

• Only the Client AID controller can create valid requests
• Timestamp validation prevents replay attacks
• Key state verification ensures signatures use current keys

Response Construction

1. Response Body Creation: Agent constructs JSON response body with:

   • Operation result
   • Status information
   • Timestamp

2. Signature Generation: Agent signs the response body with the Agent AID's current signing key

3. Signature Attachment: Agent attaches the indexed signature to the response

4. Response Transmission: Agent sends the signed response to the client

Response Verification

1. Signature Extraction: Client extracts the indexed signature from the response

2. Key State Retrieval: Client retrieves the Agent AID's current key state

3. Signature Verification: Client verifies the signature against the current signing key

4. Response Processing: Client processes the verified response

Security Properties:

• Only the Agent AID can create valid responses
• Bidirectional authentication ensures both parties verify each other
• Man-in-the-middle attacks are prevented by signature verification

Passcode Rotation Procedure

Passcode rotation enables users to change their passphrase while maintaining the same Client AID:

Rotation Initiation

1. New Passphrase Entry: User provides new 21-character passphrase

2. New Key Derivation: Client derives new signing and rotation keys from new passphrase using same salt

3. Rotation Event Creation: Client creates rotation event with:

   • New signing key (derived from new passphrase)
   • New rotation key digest (derived from new passphrase)
   • Prior event digest
   • Incremented sequence number

4. Event Signing: Client signs rotation event with OLD signing key (from old passphrase)

5. Event Submission: Client submits signed rotation event to Agent

Security Properties:

• The rotation event must be signed with the old key, proving control before rotation
• The new signing key must match the pre-rotated digest from the prior event
• This enforces pre-rotation commitment

Rotation Completion

1. Event Verification: Agent verifies the rotation event signature and pre-rotation commitment

2. Witness Propagation: Agent propagates rotation event to witnesses

3. Receipt Collection: Agent collects witness receipts

4. Key State Update: Agent updates internal key state to reflect new keys

5. Confirmation: Agent returns signed confirmation to client

6. Keystore Update: Client updates encrypted keystore with new passphrase-derived keys

Security Properties:

• The old passphrase is required to authorize the rotation
• The new keys are cryptographically committed through pre-rotation
• Witnesses verify and record the rotation, providing ambient verifiability

State Transitions

SKRAP defines state transitions for both Client and Agent AIDs:

Client AID State Transitions

1. Uninitialized → Initialized: Inception event creates the Client AID
2. Initialized → Delegating: Interaction event anchors Agent AID delegation
3. Delegating → Delegated: Agent completes delegation and collects witness receipts
4. Delegated → Rotated: Rotation event changes key state
5. Rotated → Delegated: New delegation established with rotated keys

Agent AID State Transitions

1. Uninitialized → Delegated: Delegated inception creates the Agent AID
2. Delegated → Anchored: Client anchors the delegation
3. Anchored → Witnessed: Witnesses verify and receipt the delegation
4. Witnessed → Operational: Agent begins accepting requests
5. Operational → Rotated: Agent rotates keys (requires client participation)

Timing and Ordering Requirements

SKRAP enforces strict ordering requirements:

Event Ordering

• Events in a KEL MUST be strictly ordered by sequence number
• Each event MUST reference the prior event through the p field
• Sequence numbers MUST increment by exactly 1
• No gaps or duplicates are permitted

Delegation Ordering

• The delegated inception MUST be created before the anchoring interaction
• The anchoring interaction MUST reference the delegated inception through a seal
• Both events MUST be witnessed before the delegation is considered valid

Request-Response Ordering

• Requests MUST be processed in the order received
• Responses MUST correspond to requests
• Timestamps MUST be monotonically increasing

Security Properties:

• Strict ordering prevents race conditions and replay attacks
• Event chaining through prior digests ensures tamper-evidence
• Witness receipts provide ambient verifiability of ordering

Security Properties

Threat Model

SKRAP's security design addresses multiple threat categories:

Network Adversaries

Threat: Adversaries controlling network infrastructure attempting to:

• Intercept and modify messages
• Replay captured messages
• Impersonate clients or agents
• Perform man-in-the-middle attacks

Mitigation:

• All messages are signed with indexed signatures
• Signatures are verified against current key state
• Timestamps prevent replay attacks
• Bidirectional authentication prevents impersonation

Compromised Agents

Threat: Malicious or compromised KERIA agents attempting to:

• Create unauthorized events
• Modify client key state
• Issue fraudulent credentials
• Steal client keys

Mitigation:

• Agents cannot create events without client signatures
• Cooperative delegation requires both parties to participate
• Client keys never leave the edge device
• Witnesses provide independent verification

Key Compromise

Threat: Adversaries obtaining client private keys through:

• Device theft
• Malware
• Weak passphrases
• Side-channel attacks

Mitigation:

• Pre-rotation enables recovery from key compromise
• Rotation events must be signed with old keys before compromise
• Witnesses detect duplicity if compromised keys are misused
• Hardware wallet integration protects keys in secure enclaves

Witness Collusion

Threat: Malicious witnesses colluding to:

• Confirm fraudulent events
• Hide legitimate events
• Create duplicitous event logs

Mitigation:

• Threshold of Accountable Duplicity (TOAD) requires sufficient honest witnesses
• Watchers in promiscuous mode detect duplicity
• Ambient verifiability enables anyone to verify event logs
• Witness rotation enables replacing compromised witnesses

Security Guarantees

SKRAP provides the following cryptographic guarantees:

Authenticity

Guarantee: All messages are cryptographically attributable to their claimed source.

Mechanism:

• Digital signatures using Ed25519 or other supported algorithms
• Signatures verified against current key state from KEL
• Indexed signatures identify which key was used

Strength: Authenticity relies on the cryptographic strength of the signature algorithm (128-bit security for Ed25519).

Integrity

Guarantee: Message content cannot be modified without detection.

Mechanism:

• SAIDs (Self-Addressing Identifiers) cryptographically bind content to digests
• Signatures cover entire message content
• Hash chaining through prior event digests ensures tamper-evidence

Strength: Integrity relies on collision resistance of hash functions (Blake3-256 provides 256-bit security).

Non-Repudiation

Guarantee: Message senders cannot deny having sent a message.

Mechanism:

• Digital signatures provide non-repudiable proof of authorship
• Signatures are verified against public keys in KEL
• Witnesses provide independent verification and receipts

Strength: Non-repudiation relies on the security of private key storage and the signature algorithm.

Confidentiality

Guarantee: Message content is protected from unauthorized disclosure.

Mechanism:

• SKRAP itself does not provide confidentiality (messages are signed but not encrypted)
• Confidentiality can be added through:
  • TLS/HTTPS for transport encryption
  • End-to-end encryption for message content
  • SPAC (Secure Private Authentic Confidentiality) for KERI-native encryption

Note: SKRAP focuses on authentication and integrity, not confidentiality. Confidentiality is provided by complementary protocols.

Availability

Guarantee: Services remain available despite failures or attacks.

Mechanism:

• Witness pools provide redundancy
• Threshold of Accountable Duplicity tolerates witness failures
• Clients can switch to different KERIA agents
• Watchers provide backup verification

Strength: Availability depends on witness pool configuration and network infrastructure.

Attack Resistance

SKRAP resists multiple attack vectors:

Replay Attack Resistance

Attack: Adversary captures and replays valid messages.

Defense:

• Timestamps in request bodies
• Sequence numbers in key events
• Prior event digests in event chains
• Nonces in challenge-response protocols

Effectiveness: Replay attacks are detected through timestamp validation and sequence number verification.

Man-in-the-Middle Attack Resistance

Attack: Adversary intercepts and modifies messages between client and agent.

Defense:

• Bidirectional signature verification
• End-to-end cryptographic binding
• TLS/HTTPS transport encryption
• OOBI verification of endpoints

Effectiveness: MITM attacks are prevented by signature verification and transport encryption.

Sybil Attack Resistance

Attack: Adversary creates multiple fake identities to subvert witness pools.

Defense:

• Witness designation by controller
• Threshold of Accountable Duplicity requires sufficient honest witnesses
• Watchers provide independent verification
• Witness rotation enables replacing compromised witnesses

Effectiveness: Sybil attacks are mitigated by controller-designated witness pools and threshold requirements.

Eclipse Attack Resistance

Attack: Adversary isolates a client from honest witnesses.

Defense:

• Multiple witness endpoints
• OOBI discovery of alternative endpoints
• Watchers in promiscuous mode
• Ambient verifiability enables verification through any path

Effectiveness: Eclipse attacks are mitigated by redundant witness endpoints and alternative verification paths.

Key Compromise Attack Resistance

Attack: Adversary obtains client private keys.

Defense:

• Pre-rotation enables recovery
• Rotation events must be signed with old keys
• Witnesses detect duplicity
• Hardware wallet integration protects keys

Effectiveness: Key compromise is recoverable if detected before the compromised keys are used for rotation.

Post-Quantum Security

SKRAP is designed for post-quantum security:

Algorithm Agility

• Derivation codes enable algorithm specification
• New quantum-resistant algorithms can be added without protocol changes
• Existing AIDs can rotate to quantum-resistant keys

Quantum-Resistant Algorithms

Supported quantum-resistant algorithms include:

• Dilithium: NIST-selected lattice-based signature scheme
• Falcon: NIST-selected lattice-based signature scheme
• SPHINCS+: NIST-selected hash-based signature scheme

Migration Path

Clients can migrate to quantum-resistant algorithms through:

1. Rotation event with quantum-resistant next keys
2. Subsequent rotation to quantum-resistant current keys
3. Gradual migration of entire witness pools

Timeline: Migration should occur before large-scale quantum computers become available (estimated 10-20 years).

Interoperability

Dependencies on KERI/ACDC Protocols

SKRAP builds upon foundational KERI protocols:

KERI Core Protocol

Dependency: KERI (Key Event Receipt Infrastructure) provides:

• KEL (Key Event Log) data structures
• Establishment events (inception, rotation)
• Non-establishment events (interaction)
• Witness coordination
• Duplicity detection

Integration: SKRAP uses KERI event structures for all Client and Agent AID operations.

CESR Encoding

Dependency: CESR (Composable Event Streaming Representation) provides:

• Dual text/binary encoding
• Self-framing primitives
• Composability
• Derivation codes

Integration: All SKRAP messages use CESR encoding for cryptographic primitives.

ACDC Credentials

Dependency: ACDC (Authentic Chained Data Container) provides:

• Verifiable credential structures
• Selective disclosure
• Graduated disclosure
• Chain-link confidentiality

Integration: SKRAP enables ACDC issuance and presentation through agent operations.

IPEX Protocol

Dependency: IPEX (Issuance and Presentation Exchange) provides:

• Credential issuance flows
• Presentation request/response patterns
• Contractually protected disclosure

Integration: SKRAP Admin Interface supports IPEX operations for credential exchange.

OOBI Discovery

Dependency: OOBI (Out-Of-Band Introduction) provides:

• Endpoint discovery
• Service endpoint resolution
• Percolated discovery

Integration: SKRAP uses OOBI for discovering witness and watcher endpoints.

Integration Points

SKRAP provides integration points for:

Client Applications

Integration: Client applications integrate SKRAP through:

• Signify client libraries (JavaScript, TypeScript, Python, Rust)
• REST API to Admin Interface
• WebSocket connections for real-time updates

Examples:

• KERIMask browser extension
• Mobile wallet applications
• Desktop identity management tools

Hardware Wallets

Integration: Hardware wallets integrate SKRAP through:

• USB or Bluetooth communication
• Signing requests forwarded to hardware device
• Keys never leave hardware security boundary

Examples:

• HSM (Hardware Security Module) integration
• Ledger/Trezor-style hardware wallets
• TPM (Trusted Platform Module) integration

Witness Infrastructure

Integration: Witnesses integrate through:

• KERI Protocol Interface
• CESR over HTTP
• Receipt generation and storage

Examples:

• Standalone witness services
• Ledger-backed witnesses
• Witness pools with threshold requirements

Credential Registries

Integration: Credential registries integrate through:

• TEL (Transaction Event Log) operations
• Registrar coordination
• Issuance and revocation events

Examples:

• Public TEL registries
• Blinded revocation registries
• Management TEL for registry governance

Implementation Considerations

Common Challenges

Implementers face several common challenges:

Key Derivation Performance

Challenge: Argon2 key stretching is computationally expensive, causing delays during initialization and rotation.

Mitigation:

• Tune Argon2 parameters for acceptable performance
• Cache derived keys in encrypted keystore
• Use hardware acceleration where available
• Consider HSM integration for high-security deployments

Witness Coordination Latency

Challenge: Collecting witness receipts introduces latency, especially with geographically distributed witnesses.

Mitigation:

• Use witness pools with acceptable latency characteristics
• Implement timeout and retry logic
• Consider witness rotation to replace slow witnesses
• Use watchers for asynchronous verification

State Synchronization

Challenge: Keeping client and agent state synchronized, especially with intermittent connectivity.

Mitigation:

• Implement robust state reconciliation protocols
• Use sequence numbers and prior digests for consistency checking
• Cache recent events for offline verification
• Implement conflict resolution for concurrent updates

Error Handling

Challenge: Handling errors gracefully without compromising security.

Mitigation:

• Validate all inputs before processing
• Use cryptographic verification for all messages
• Implement comprehensive error logging
• Provide clear error messages for debugging

Scalability

Challenge: Supporting large numbers of clients and high transaction volumes.

Mitigation:

• Use multi-tenant architecture with dedicated agent workers
• Implement efficient state storage and retrieval
• Use caching for frequently accessed data
• Consider horizontal scaling of KERIA infrastructure

Performance Considerations

Performance optimization strategies:

Cryptographic Operations

Optimization:

• Use hardware acceleration for signature verification
• Batch signature verifications where possible
• Cache public keys to avoid repeated derivation
• Use efficient cryptographic libraries (libsodium, etc.)

Network Operations

Optimization:

• Use connection pooling for witness communication
• Implement parallel witness queries
• Use HTTP/2 or HTTP/3 for multiplexing
• Compress large messages

Storage Operations

Optimization:

• Use efficient database indexing for KEL queries
• Implement write-ahead logging for durability
• Use memory-mapped files for large KELs
• Consider distributed storage for scalability

Message Processing

Optimization:

• Use streaming parsers for large messages
• Implement pipelining for event processing
• Use asynchronous I/O for non-blocking operations
• Batch database writes where possible

Security Considerations

Security best practices:

Key Management

Best Practices:

• Use strong passphrases (21+ characters)
• Store encrypted keystores with appropriate permissions
• Use hardware wallets for high-value identities
• Implement secure key deletion
• Rotate keys periodically

Network Security

Best Practices:

• Use TLS/HTTPS for all network communication
• Validate TLS certificates
• Implement certificate pinning for known endpoints
• Use OOBI verification for endpoint discovery
• Monitor for suspicious network activity

Access Control

Best Practices:

• Implement least-privilege access control
• Use separate interfaces for different security zones
• Disable Boot Interface in production
• Implement rate limiting for API endpoints
• Log all access attempts

Monitoring and Auditing

Best Practices:

• Log all key events and operations
• Monitor for duplicity detection
• Implement alerting for security events
• Regularly audit KELs for consistency
• Use watchers for independent verification

Deployment Considerations

Deployment strategies:

Development Environment

Configuration:

• Use well-known witnesses for testing
• Enable Boot Interface for agent initialization
• Use short timeouts for rapid iteration
• Enable verbose logging

Staging Environment

Configuration:

• Use production-like witness configuration
• Test witness rotation procedures
• Validate performance under load
• Test failure scenarios

Production Environment

Configuration:

• Use geographically distributed witnesses
• Disable Boot Interface or restrict to internal network
• Implement monitoring and alerting
• Use hardware security modules for high-value identities
• Implement backup and disaster recovery

Testing Strategies

Comprehensive testing approaches:

Unit Testing

Focus:

• Cryptographic primitive operations
• Key derivation algorithms
• Signature generation and verification
• Message serialization and deserialization

Integration Testing

Focus:

• Client-agent communication
• Witness coordination
• Event propagation and receipt collection
• State synchronization

Security Testing

Focus:

• Replay attack prevention
• Man-in-the-middle attack resistance
• Key compromise scenarios
• Duplicity detection

Performance Testing

Focus:

• Throughput under load
• Latency characteristics
• Scalability limits
• Resource utilization

Interoperability Testing

Focus:

• Cross-implementation compatibility
• Protocol version compatibility
• Witness pool interoperability
• Credential exchange compatibility

Security Hardening

1. Network Security: Use TLS/HTTPS for all network communication; validate certificates; implement certificate pinning

2. Access Control: Implement least-privilege access; disable Boot Interface in production or restrict to internal network

3. Monitoring: Log all key events and operations; implement alerting for security events; use watchers for independent verification

4. Key Management: Use hardware wallets or HSMs for high-value identities; implement secure key deletion; rotate keys periodically

Testing Requirements

1. Unit Tests: Test cryptographic operations, key derivation, signature verification, and message serialization

2. Integration Tests: Test client-agent communication, witness coordination, event propagation, and state synchronization

3. Security Tests: Test replay attack prevention, MITM resistance, key compromise scenarios, and duplicity detection

4. Performance Tests: Test throughput, latency, scalability, and resource utilization under load

5. Interoperability Tests: Test cross-implementation compatibility and protocol version compatibility