did:keri

The did:keri method is built on the Key Event Receipt Infrastructure (KERI), a system designed for secure and decentralized key management without relying on blockchain technology. This method focuses on self-certifying identifiers and uses an event-sourcing approach where the state of an identifier is derived from an append-only log of key events.

Unlike traditional DID methods, did:keri maintains state through a Key Event Log (KEL) - a hash-chained data structure that records all changes to an identifier's key state. The method is particularly notable for its pre-rotation mechanism, which allows secure key rotation by committing to future keys in advance, enhancing security against key compromise.

The method supports both one-to-one (direct mode) and many-to-many (indirect mode) relationships, making it suitable for both private pairwise interactions and public multi-party scenarios. A key innovation is its witness network architecture, where designated witnesses provide signed receipts of key events, creating a robust system for duplicity detection and ensuring consistent views of an identifier's state.

Security is achieved through cryptographic binding of identifiers to their inception keys, with state transitions verified through an append-only event log. The method doesn't require any blockchain or central authority, instead relying on distributed state verification through its witness network.

Technical Details:

1. DID Generation and Structure:

   • Format: did:keri:<prefix>
   • Prefix is derived from inception keys using self-addressing identifiers
   • Cryptographically bound to inception keys
   • Follows specifications in KID0001

2. Resolution Process:

   • Locate the Key Event Log for the prefix
   • Process KEL into Key State following KID0008 rules
   • Generate DID Document containing:
     • Verification Methods from current key state
     • Key State in document metadata
     • Optional service endpoints

3. Key Management Features:

   • Pre-rotation mechanism for secure key updates
   • Support for multi-signature configurations
   • Witness rotation capabilities
   • Delegation support for hierarchical authority
   • Zero-knowledge capable through entropy-based identifiers

4. Security Architecture:

   • Hash-chained event logs prevent tampering
   • Duplicity detection through witness network
   • Non-repudiable key state transitions
   • No single point of failure
   • Threshold signing support

5. Technology Stack:

   • KERI protocol core
   • Key Event Receipt Logs (KERL)
   • Witness network infrastructure
   • State validation rules engine
   • Cryptographic primitives for signing and verification