This specification defines a Decentralized Identifier (DID)[[DID-CORE]] method for the Nostr protocol. Nostr is an open-source protocol that utilizes the W3C WebSockets standard.

This document is a draft specification produced by the W3C Nostr Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.

This specification is intended to provide a stable foundation for implementing Nostr-based Decentralized Identifiers. Feedback and contributions are encouraged through the GitHub repository.

This document is a work in progress and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

Introduction

Decentralized Identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity. The Nostr DID method connects the emerging W3C DID standard with the Nostr protocol, allowing Nostr keypairs to be used as the foundation for decentralized identifiers.

Nostr is a simple, open protocol that enables a truly censorship-resistant and global social network. By creating a DID method for Nostr, this specification enables Nostr identities to participate in the broader decentralized identity ecosystem, supporting verifiable credentials, authentication, and other identity use cases.

This specification describes how to create, read, and use Nostr DIDs, along with the expected behavior of conforming implementations. The method is designed to be simple, requiring minimal processing overhead while maintaining compatibility with existing Nostr tooling and infrastructure.

Core Concepts

Nostr DID Scheme

The Nostr DID scheme `did:nostr:pubkey` is based on the encoding of a public key. The public key is represented as a 64-character, lowercase string. The prefix did:nostr should be in lowercase, as per the DID specification.

Example Nostr DID: did:nostr:124c0fa99407182ece5a24fad9b7f6674902fc422843d3128d38a0afbee0fdd2.

Relationship with Nostr npubs

In the Nostr ecosystem, public keys are often displayed as "npubs" (e.g., npub1...), which are Bech32 encoded versions of the raw public keys for human-friendly display.

It is important to note that Nostr DIDs use the raw 64-character hexadecimal public key, not the npub format. npubs should be considered display-only identifiers to improve readability in user interfaces.

When implementing the DID Nostr method, applications SHOULD accept raw public keys for DID creation. For display in user interfaces, applications MAY choose to show the corresponding npub alongside the DID.

Example mapping:

Example DID

The following is a template for Nostr DIDs:

{
    "@context": ["https://w3id.org/did", "https://w3id.org/nostr/context"],
    "id": "did:nostr:124c0fa99407182ece5a24fad9b7f6674902fc422843d3128d38a0afbee0fdd2",
    "verificationMethod": [
       {
            "id": "did:nostr:124c0fa99407182ece5a24fad9b7f6674902fc422843d3128d38a0afbee0fdd2#key1",
            "controller": "did:nostr:124c0fa99407182ece5a24fad9b7f6674902fc422843d3128d38a0afbee0fdd2",
            "type": "SchnorrVerification2023"
        }
    ],
    "authentication": ["#key1"],
    "assertionMethod": ["#key1"],
    "service": [
        {
            "id": "did:nostr:124c0fa99407182ece5a24fad9b7f6674902fc422843d3128d38a0afbee0fdd2#relay1",
            "type": "Relay",
            "serviceEndpoint": "wss://some-nostr-relay.org/"
        }
    ]
}

A resolver MUST retrieve events from relays.

Additional Terminology

The term relay refers to a Nostr relay.

Service Field for Relays

The DID Document SHOULD include a service field to explicitly define relevant relays. This provides a standardized approach for applications resolving a DID document to discover the relays associated with the identity.

Each relay is represented as a service entry with type "Relay" and a serviceEndpoint that specifies the WebSocket URL of the relay. Multiple relays can be included in the service array.

Operations

Create (Register)

Creating a did:nostr identifier involves the following steps:

  1. Generate a secp256k1 key pair using a cryptographically secure random number generator
  2. Extract the public key (32 bytes)
  3. Encode the public key as a 64-character lowercase hexadecimal string
  4. Prefix the encoded public key with "did:nostr:" to form the complete DID

For example, if the generated public key in hex is:
124c0fa99407182ece5a24fad9b7f6674902fc422843d3128d38a0afbee0fdd2

The corresponding DID would be:
did:nostr:124c0fa99407182ece5a24fad9b7f6674902fc422843d3128d38a0afbee0fdd2

Note: No on-chain registration is required as the security and uniqueness are derived from the key generation process.

Read (Resolve)

Resolving a did:nostr identifier involves the following steps:

  1. Parse the identifier to extract the 64-character hexadecimal public key
  2. Construct a DID Document with the following properties:
    • Set the id field to the full DID
    • Include a verification method with type "SchnorrVerification2023"
    • Set appropriate authentication and assertionMethod references
    • Include any known relay endpoints in the service section
  3. Optionally, query known Nostr relays for metadata about the public key

The resolved DID Document will follow the template shown in the "Example DID" section above.

For relay discovery, implementations SHOULD:

  1. Check a local cache of known relays for the public key
  2. Query a set of default relays with a filter for kind 0 (metadata) events by the target public key
  3. Include discovered relays in the service section of the DID Document

Update (Replace)

This DID Method does not support updating the DID Document.

Delete (Revoke)

This DID Method does not support deactivating the DID Document.

Security & Privacy

Security Considerations

The security of the did:nostr method relies on the security properties of the underlying Nostr protocol and its public key cryptography. The following security considerations apply:

Key Management

The private keys corresponding to Nostr DIDs MUST be kept secure. Loss of private keys will result in permanent loss of control over the identifier. Implementers SHOULD employ strong key management practices, including secure key generation, storage, and backup procedures.

Relay Security

Nostr DIDs interact with the Nostr network through relays. These relays may have different security properties and trust models. Implementers SHOULD:

  • Use TLS (wss://) connections to relays to prevent eavesdropping and man-in-the-middle attacks
  • Consider using multiple relays for redundancy and to mitigate denial of service risks
  • Be aware that relays may choose to filter or modify events, potentially affecting DID resolution

Cryptographic Considerations

The Nostr DID method uses Schnorr signatures over the secp256k1 curve, which is considered cryptographically secure at the time of writing. However, cryptographic methods may become vulnerable over time. Implementers should stay informed about advancements in cryptanalysis that might affect the security of these signatures.

For additional security requirements, refer to W3C Decentralized Identifiers 7.3.

Privacy Considerations

The did:nostr method has several privacy implications that implementers and users should be aware of:

Identifier Correlation

A Nostr DID directly incorporates a public key that may be used across multiple contexts in the Nostr ecosystem. This creates a potential correlation vector where activities under the same DID can be linked across different services or applications. Users should understand that a single did:nostr identifier does not provide compartmentalization of identity across different contexts.

To mitigate correlation risks, users may consider:

  • Using different DIDs for different contexts or services
  • Creating purpose-specific DIDs rather than using a single DID for all activities

Public Nature of Nostr

Information associated with a Nostr DID is typically stored on public relays where it can be accessed by anyone. Users should be aware that DID Documents and associated Nostr events are public information. Private or sensitive data should not be included in DID Documents or directly associated with did:nostr identifiers.

Service Endpoints

The service endpoints (relays) listed in a DID Document may reveal information about a user's network participation and potentially their geographic region or service preferences. Implementers should be cautious about what information might be inferred from service endpoints included in DID Documents.

For additional privacy requirements, refer to W3C Decentralized Identifiers 7.4.

Implementations

Block, Inc. previously developed a related implementation of the did:nostr method in Rust, but this work has been discontinued and archived. The archived repository can be found at https://github.com/TBD54566975/did-nostr.

Resources