Key points
- W3C DID Core specification (1.0)
- Format: did:method:identifier (e.g. did:web:idsync.com, did:key:z6Mk...)
- Resolves to a DID document containing public keys and service endpoints
- Foundation for verifiable credentials and SSI
- Multiple 'methods' — did:web, did:key, did:ion, did:ethr — with very different trust models
What it is
A DID is an identifier the subject controls, paired with a public-key infrastructure that doesn't depend on a central CA or directory. It's how an issuer or holder of a verifiable credential is named and proves control of their keys.
A DID looks like: did:web:idsync.com or did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSrqNUqj8jXBcrYHrjeu. Resolving it returns a DID document — JSON listing public keys, authentication methods, and service endpoints.
DID methods
- did:web — hosted at a
/.well-known/did.jsonpath; relies on DNS + HTTPS trust - did:key — derives the document from the key itself; no network at all
- did:ion / did:ethr — backed by Bitcoin or Ethereum for censorship resistance
- did:jwk — embeds a JWK directly
Each method has very different operational and trust properties.
When buyers care
- Implementing verifiable credentials (issuer or verifier)
- EUDI Wallet, mDL, and other government wallet integrations
- Pilots of reusable workforce identity
Common misconceptions
- DIDs don't require a blockchain. did:web and did:key don't touch one.
- DIDs are not user-facing identifiers. Users see human-readable names; DIDs sit underneath.
FAQ
DID vs OIDC subject?
An OIDC sub is issued and controlled by the IdP. A DID is controlled by the subject — the IdP/issuer doesn't get to revoke the identifier itself.