did:pkh primary sources — 2026-05-10

What I reviewed

did:pkh is a generative DID method that wraps existing blockchain accounts into DID form instead of asking each chain ecosystem to deploy and maintain a separate DID registry or registry-backed method.
The method depends on CAIP-10 account identifiers. The most important validity check is whether the underlying blockchain account string is well-formed for its namespace, not whether the account is active, funded, or rotated.
The draft repeatedly emphasizes usability: an existing wallet/account can become a DID immediately, which reduces the gap between blockchain-native account UX and DID-compatible software.
The DID documents are local-only and purely generative. No native update, deletion, or tombstoning flows are provided, which makes account lifecycle and revocation an external problem.
The spec is intentionally narrow about signing and authentication. Wallet behavior, chain-specific signature methods, and security/recovery assumptions remain downstream of the underlying chain ecosystem.
The text explicitly frames did:pkh as useful alongside verifiable credentials, capability systems, SIWx flows, and controller patterns, which is why it belongs in the corpus as identifier infrastructure rather than as a full-stack identity product.

README: clearest plain-language statement that did:pkh is a generative “pseudo-DID method” built around blockchain addresses and CAIP-10.
Method draft introduction: best statement of the usability rationale and of the idea that existing blockchain accounts should be able to “spin up” valid DID documents instantly.
Draft syntax / resolution sections: useful for understanding how a CAIP-10 account becomes a DID, how verification methods are derived, and why the method is deterministic rather than registry-driven.
Security considerations: important reminder that rotation, deactivation, and privacy guarantees are limited because the method is purely generative.

It strengthens the identity / attestation / wallet-auth side of the corpus by isolating the subject-identifier layer from the authentication and authorization layers.
It is a useful comparison class for EIP-4361, CAIP-122, delegate registries, and attestation systems because it standardizes who the subject is without standardizing every later action taken by that subject.
The reusable insight is that many crypto identity products quietly combine identifier formatting, wallet authentication, authorization receipts, and trust signals into one UX; did:pkh helps split those layers apart analytically.