ADR: DID Method Strategy (did:key + did:web)

[ojongerius]

The spec currently uses placeholder DID methods (did:agent:, did:user:) that aren't registered W3C DID methods. Verifiers have no way to resolve proof.verificationMethod to an actual public key, which means receipts can be signed but not independently verified.

Proposed decision

Use did:key as the zero-infrastructure default for SDKs and did:web as the recommended method for production operators. Define a concrete migration path between them.

What the ADR covers

• Why did:key and did:web over did:jwk, did:peer, did:ion, or SPIFFE/SPIRE
• did:key encoding rules for Ed25519
• did:web DID document structure
• did:key → did:web migration via key.migrate receipts (depends on ADR-0002)
• Key granularity guidance (per-operator vs per-agent vs per-session)
• Verification algorithm changes

Open questions

1. Has anyone run did:web in production at scale? What broke?
2. Is did:key → did:web migration worth the verification complexity, or should we say pick one?
3. Should we support did:jwk alongside did:key?
4. What's the right default key granularity for an audit trail protocol?

Related

• Blocks: Key Rotation ADR, Capability Delegation ADR
• Draft ADR: docs/adr/0001-did-method-strategy.md