did:nostr

A Nostr key is a decentralized identifier.
Draft spec GitHub CID v1.0

What is did:nostr?

did:nostr is a W3C DID method in which a Nostr public key is the identifier. There is no registry, no ledger, and nothing to mint: the keypair you already use on Nostr resolves directly to a DID document. 

did:nostr:124c0fa99407182ece5a24fad9b7f6674902fc422843d3128d38a0afbee0fdd2

The identifier is the 64-character lowercase hex public key; npub (bech32) is display only.

Resolving that DID yields a document describing the key (as a Multikey) and, optionally, an alsoKnownAs link to a WebID, bridging a Nostr identity into the wider WebID, Solid, and Verifiable-Credentials world without giving up self-custody of the key.

How resolution works

A conforming resolver works in three tiers; the first needs no network at all.

  1. Minimal (offline). A resolver MUST produce a valid DID document from the public key alone, with no network. The key plus the deterministic Multikey transform is the document.
  2. HTTP. For a richer document, fetch https://<domain>/.well-known/did/nostr/<pubkey>.json, which is fast and cacheable.
  3. Enhanced (relays). Query Nostr relays for the key's kind 0 profile and kind 3 follows to fill in profile, follows, and relay service endpoints.

The key appears as a Multikey referenced from authentication and assertionMethod. An optional alsoKnownAs links to a WebID (or ActivityPub, Bluesky, other DIDs), bridging the Nostr identity outward; the same key signs requests over HTTP via NIP-98, so resolution and auth share one keypair.

The DID document

The minimal document a resolver returns (derivable from the key alone):

{
  "@context": [
    "https://www.w3.org/ns/cid/v1",
    "https://w3id.org/nostr/context"
  ],
  "id": "did:nostr:124c0fa9…bee0fdd2",
  "type": "DIDNostr",
  "verificationMethod": [{
    "id": "did:nostr:124c0fa9…bee0fdd2#key1",
    "type": "Multikey",
    "controller": "did:nostr:124c0fa9…bee0fdd2",
    "publicKeyMultibase": "fe70102124c0fa9…bee0fdd2"
  }],
  "authentication": ["#key1"],
  "assertionMethod": ["#key1"]
}

The publicKeyMultibase is f (base16) + e701 (secp256k1 multicodec) + parity byte + the 64-char hex key. Multikey and publicKeyMultibase are defined by Controlled Identifiers v1.0; the nostr/context adds the Nostr terms. Enhanced documents may also carry alsoKnownAs, service (relay endpoints), profile, and follows.

The published draft still lists https://w3id.org/did as the first context; the switch to CID v1.0 is in flight (nostrcg/did-nostr#91).

Ecosystem

Projects building on did:nostr. Browse them all on the did-nostr GitHub topic; add the did-nostr topic to your repo to appear here.

Servers & pods

Libraries & keys

Indexers & infrastructure

Clients & apps

Specification & standards

Bridges

Resolver coming soon

A live directory and resolver already runs at nostr.social, where you can browse did:nostr identities and fetch their DID documents. An in-browser widget, where you paste an npub or hex pubkey and watch its document resolve here, is planned; it will run the full resolution chain (pod well-known endpoints plus Nostr relays), not a single host.

Standards

did:nostr builds on W3C DID Core and Controlled Identifiers v1.0. The method draft is developed openly in the Nostr Community Group; this site is an independent hub and does not imply Community-Group consensus.

The same CID v1.0 foundation underpins the W3C Linked Web Storage (LWS) 1.0 authentication suite. Because a did:nostr key can be declared as a Multikey in a WebID profile, a NIP-98 signature can authenticate as that WebID, alongside LWS-CID JWTs and Solid-OIDC. JSS ships this today (jss.live/docs/features/lws).