did:peer

The Peer DID Method is a decentralized identifier specification designed for private, peer-to-peer relationships between parties without requiring any central source of truth or blockchain. It enables self-sovereign identity management that is fast, scalable, and secure while being completely independent of any centralized infrastructure.

The method is optimized for pairwise (two-party) and n-wise (small group) relationships, making it ideal for most private interactions between people, organizations, and things. Unlike public DID methods, peer DIDs are only resolvable by the parties involved in the relationship, providing enhanced privacy and security.

Key features include:

• Zero transaction costs for creation and maintenance
• Offline-first capability with no internet dependency
• High scalability limited only by participating parties
• Enhanced privacy with no central data store
• Flexible key management supporting multiple verification methods
• Service endpoint definition capabilities
• Multiple implementation versions (0-4) with different features

The method supports four main implementation approaches:

1. did:peer:0 - Single inception key without document
2. did:peer:1 - Genesis document with single key
3. did:peer:2 - Multiple inception keys without document
4. did:peer:3 and did:peer:4 - Short-form/long-form variants for efficiency

Technical Architecture:

1. DID Generation:

• Generated through cryptographic operations using public keys or document hashes
• Uses multicodec encoding for standardized data representation
• Implements base58 encoding for human-readable format

2. Resolution Process:

• Local resolution only by participating parties
• No external lookup or blockchain queries required
• Supports both short-form and long-form resolution

3. Security Features:

• Self-certifying through inception key control
• Entropy-based uniqueness guarantees
• Trust-on-first-use (TOFU) protection mechanisms
• Verifiable credential support for enhanced trust

4. Key Management:

• Supports multiple key types and purposes
• Enables separate authentication and encryption keys
• Follows DKMS (Decentralized Key Management System) best practices

5. Technology Stack:

• Built on W3C DID Core specification
• Uses multicodec and multibase encoding standards
• Compatible with DIDComm v2 messaging protocol
• Implements SHA-256 hashing for document integrity

The method is particularly well-suited for:

• Private organizational relationships
• IoT device identity management
• Secure messaging applications
• Offline-capable identity systems
• Privacy-focused implementations