Cowrie Research

did-pkh

3 min read

did:pkh

  • Name: did:pkh
  • URL: https://github.com/w3c-ccg/did-pkh
  • Category: chain-agnostic DID method / blockchain-account wrapper / identity-subject standard
  • Summary: did:pkh is best understood as a DID-wrapping standard for existing blockchain accounts rather than as a new identity registry. Its core mechanism is to take a CAIP-10-formatted account identifier, validate that it is well-formed for its chain namespace, and deterministically turn it into a local-only W3C DID document with the blockchain account itself as the verification anchor. That makes it a useful comparison class for did:key, EIP-4361, CAIP-122, delegate registries, and attestation systems: those systems decide how a wallet signs, delegates, or proves things, while did:pkh standardizes who the subject is in DID-compatible form without requiring new onchain infrastructure.
  • What it does:
    • Defines a generative DID method that converts a valid CAIP-10 blockchain account into a did:pkh identifier
    • Produces deterministic DID documents locally instead of requiring onchain registration, updates, or a separate DID registry
    • Maps multiple blockchain namespaces and key types into DID verification methods, including EVM chains, Solana, Bitcoin-family chains, Tezos, and Arweave examples in the draft
    • Uses the underlying blockchain account as the verification anchor through blockchainAccountId rather than inventing a separate account system
    • Leaves authentication, signing UX, key recovery, and account lifecycle to the wallet and chain ecosystem that already controls the address
    • Creates an interoperable subject format that can later be used with verifiable credentials, authorization capabilities, or other DID-controller patterns
  • Key claims:
    • The draft explicitly frames did:pkh as a pragmatic bridge: instead of forcing each blockchain ecosystem to run a bespoke DID method stack, it wraps existing blockchain accounts in a common DID representation.
    • The most important design choice is that validation stops at CAIP-10 well-formedness. did:pkh checks that an account identifier is syntactically valid for its namespace, but it does not itself guarantee balance, liveness, rotation, or richer account-state semantics.
    • The spec repeatedly emphasizes usability and recognizability: a blockchain address can become a DID immediately, which reduces the distance between what users think their account is and what DID-aware software expects.
    • Unlike registry-based DID methods, did:pkh is purely generative and local-only. That means there are no native update, deletion, or tombstoning operations, which is analytically important because account rotation and revocation have to be handled somewhere else.
    • The method is intentionally narrow and unopinionated about signing because different chains expose very different wallet and signature capabilities. In practice, that shifts much of the real security model back to wallet behavior and chain-specific verification methods.
    • The draft’s discussion of upgrade paths is useful: a did:pkh identifier can serve as a bridge into richer controller patterns, other DID methods, SIWx flows, and capability objects rather than pretending to solve the whole identity stack by itself.
    • did:pkh belongs in the corpus because it isolates a recurring crypto-identity move that many products blur together: standardizing the identifier layer separately from the authentication layer, the authorization layer, and the social/reputation layer.
  • Whitepaper: No canonical standalone did:pkh whitepaper or litepaper surfaced in this pass. The strongest primary materials were the official W3C-CCG repository README and the method draft itself; see ../../whitepapers/did-pkh-primary-sources-2026-05-10.md.
  • Sources:

Internal linkages

Graph View

Backlinks