DID Key Method

Key Method DIDs are natively compatible with standard web cryptography. The public key material within a did:key can be directly expressed as a JSON Web Key (JWK) in the DID document.

• Interoperability: This allows DIDs to be used seamlessly with JSON Web Signatures (JWS) and JSON Web Encryption (JWE).
• Example: Signing a Verifiable Credential or securing an API request using a DID as the issuer or subject, leveraging existing JOSE library support.

A Key Method DID serves as the issuer identifier or subject identifier in a Verifiable Credential (VC). The corresponding private key signs the VC, providing cryptographic proof of origin.

• Flow: Issuer creates a did:key, embeds it in the VC's issuer field, and signs the VC. A verifier resolves the DID to get the public key and verifies the signature.
• Advantage: Eliminates the need for a central certificate authority, enabling trustless verification of claims.

In frameworks like Aries and protocols like DIDComm, did:peer and did:key are used to establish encrypted communication channels. Each party uses their DID to exchange keys and authenticate messages.

• Process: DIDs are exchanged during connection setup (DID Exchange protocol).
• Outcome: Creates an end-to-end encrypted tunnel where every message is signed and encrypted using keys derived from the participants' DIDs, ensuring confidentiality and authenticity.

Multiple libraries exist to generate and resolve Key Method DIDs, making them accessible for developers.

• did:key Libraries: did-key-creator (JavaScript), did-key.rs (Rust), ssi (Rust).
• did:peer Libraries: Implemented within the Aries Framework in various languages (JavaScript, .NET, Python).
• Functionality: These SDKs handle the deterministic generation of the DID document from a key pair, signature creation, and resolution, abstracting the underlying cryptography.

The security of a DID Key Method is fundamentally tied to its supported cryptographic suites. Common choices include:

• Ed25519: For fast, high-security signatures.
• secp256k1: Widely used in blockchain contexts (e.g., Ethereum).
• RSA: For compatibility with traditional PKI systems. The method must specify algorithms to prevent algorithm substitution attacks and ensure long-term quantum resistance considerations.

The private key is the core secret. Security depends on:

• Secure Enclaves: Using hardware (HSM, TPM) or trusted execution environments for generation and storage.
• Key Derivation: Employing strong, standardized functions (e.g., BIP-39, BIP-32) from high-entropy seeds.
• Custody Models: Evaluating trade-offs between user-held keys (self-custody) and delegated custody solutions. Loss of the private key equates to permanent loss of the DID.

The DID Document contains public keys and service endpoints. Its integrity must be verifiable. Methods vary:

• On-Chain: Integrity is enforced by the blockchain's consensus (e.g., did:ethr).
• Off-Chain: May rely on content-addressed storage (e.g., IPFS in did:key) or signed data structures. The resolution process must be resistant to DNS spoofing, man-in-the-middle attacks, and ensure the retrieved document is authentic and current.

A critical security control is the ability to respond to key compromise. A robust DID Key Method must define:

• Rotation Mechanism: A verifiable procedure to update the public key in the DID Document.
• Revocation Signal: A way to explicitly invalidate a key, often through an updated document or a verifiable revocation list.
• Recovery Options: Methods like delegated recovery or social recovery to prevent permanent lockout, which introduce their own trust trade-offs.

Each method implementation has unique risks:

• did:key: Relies on the security of the multicodec encoding and the assumption the document is stored/retrieved securely. No built-in revocation.
• did:ethr / did:ion: Subject to the security and finality of their underlying blockchain (Ethereum, Bitcoin). Smart contract bugs or chain reorganizations are risks.
• did:web: Inherits all web security risks (TLS compromise, domain hijacking, server breaches).

Security in practice depends on how the DID and keys are used within protocols like Verifiable Credentials or DIDComm. Considerations include:

• Proof Purpose: Ensuring keys are used only for their intended purpose (e.g., authentication, assertionMethod).
• Audit Logging: Maintaining a verifiable data registry of key changes for non-repudiation.
• Standard Compliance: Adherence to W3C DID Core specifications and related Cryptographic Suite profiles to avoid implementation flaws.

A tamper-evident digital credential whose issuer can be cryptographically verified, often anchored to a DID. A DID Key Method provides the cryptographic keys used to sign and verify these credentials.

• Structure: Contains claims, metadata, and a proof (e.g., a digital signature).
• Example: A university issues a digital diploma (a VC) signed with a key from its DID, which a graduate can then present to an employer.

A globally unique, persistent identifier that does not require a central registration authority. A DID Key Method is the specific mechanism defining how cryptographic keys are derived and used for a given DID.

• Syntax: did:method:method-specific-identifier (e.g., did:key:z6Mk...).
• Purpose: Enables entities to prove control of the identifier using the associated keys, as defined by its method.

A JSON-LD or JSON document describing the public keys, authentication mechanisms, and service endpoints associated with a DID. The DID Key Method specifies the format and location of the keys within this document.

• Contents: Includes verificationMethod entries for public keys and authentication sections.
• Resolution: A DID resolver fetches this document to enable interactions with the DID subject.

A decentralized system used to record DIDs, DID Documents, and status information like revocation. Different DID Key Methods are designed to work with specific types of registries.

• Examples: Public blockchains (e.g., Ethereum, Bitcoin), distributed ledgers, or peer-to-peer networks.
• Role: Provides the trust layer for resolving DIDs to their current, authoritative DID Document.

A governing philosophy and model for digital identity where individuals or entities control their own identifiers and credentials without relying on central authorities. DID Key Methods are a foundational cryptographic component of SSI architectures.

• Principles: User control, portability, interoperability, and consent.
• Implementation: Uses DIDs and Verifiable Credentials as core building blocks.

A standardized JSON data structure for representing cryptographic keys. Many DID Key Methods, such as did:key and did:jwk, use JWK format to encode public keys directly within a DID Document.

• Standard: Defined in RFC 7517.
• Usage: Specifies key type (e.g., EC), curve, and the public key coordinates, enabling direct interoperability with JWT and JOSE ecosystems.