Feature: Support Multiple Key Types for DID Document Interoperability

[Flaxscrip]

Summary

did:cid provisions secp256k1 keys as is common with Bitcoin, EVM, and nostr protocols. However, to enable interoperability with DIDComm v2, and other DID methods users need the ability to add keys of different types for specific verification purposes.

Problem

When attempting to use did:cid with DIDComm v2 encrypted messaging, the recipient's DID document lacks a keyAgreement entry with an X25519 key. Standard DIDComm libraries (using JOSE ECDH-ES) cannot perform key agreement with secp256k1 keys.

This limits did:cid interoperability with:

• DIDComm v2 messaging
• Systems expecting Ed25519 signatures
• Enterprise systems requiring NIST curves

Background

The W3C DID Core specification defines verification relationships that map keys to specific purposes:

Relationship	Purpose
authentication	Prove control of the DID
assertionMethod	Sign credentials/claims
keyAgreement	Establish shared secrets for encryption
capabilityInvocation	Invoke capabilities
capabilityDelegation	Delegate capabilities

Different key types are optimized for different purposes, and different ecosystems have standardized on different curves.

Key Type Landscape

By Purpose

Purpose	Industry Standard	Also Used
Signing	Ed25519	secp256k1, P-256
Key Agreement (encryption)	X25519	P-256, P-384
Authentication	Ed25519	secp256k1, P-256

By Ecosystem

Ecosystem	Key Type	Notes
Bitcoin/Lightning	secp256k1	Wallet compatibility
Ethereum	secp256k1	EVM chains
Nostr	secp256k1	Social protocol
DIDComm v2	X25519 + Ed25519	Encrypted messaging spec
KERI / did:webs	Ed25519	Key Event Receipt Infrastructure
WebAuthn/FIDO2	P-256	Browser/passkey support
Enterprise/Government	P-256, P-384	NIST compliance

DID Methods Comparison

Method	Key Type(s)
did:cid	secp256k1 only
did:key	Ed25519, X25519, P-256, secp256k1
did:webs	Ed25519
did:webplus	Ed25519
did:ethr	secp256k1
did:sov	Ed25519

Use Cases

1. DIDComm Encrypted Messaging

A did:cid holder wants to receive encrypted DIDComm messages. Senders need an X25519 keyAgreement key to encrypt to.

2. Cross-Method Credential Exchange

A did:cid holder wants to present credentials to a verifier expecting Ed25519 signatures (common in did:key, did:webs ecosystems).

3. Enterprise Integration

A did:cid holder needs to authenticate to a system requiring P-256 keys (WebAuthn, corporate SSO).

4. Future-Proofing

Post-quantum key types will emerge. Users should be able to add new key types without recreating their DID.

Requirements

1. Users should be able to add keys of different types to their existing DID documents
2. Keys should be assignable to specific verification relationships
3. The secp256k1 key should remain the did:cid default for backward compatibility
4. Key derivation should remain deterministic from the HD wallet where possible

Key Types to Consider

Type	Curve	JWK crv	Use Case
EcdsaSecp256k1VerificationKey2019	secp256k1	secp256k1	Bitcoin/Nostr signing
Ed25519VerificationKey2020	Ed25519	Ed25519	Modern signing standard
X25519KeyAgreementKey2020	Curve25519	X25519	DIDComm encryption
JsonWebKey2020	P-256	P-256	Enterprise/WebAuthn

References

• W3C DID Core - Verification Relationships
• DIDComm v2 - Key Agreement
• DID Spec Registries - Verification Method Types