Skip to content

Consider making the domain portion of a did:webvh DID optional #255

@swcurran

Description

@swcurran

This topic was raised in a Signal chat and discussed at the did:webvh Work Item Meeting 2025.08.28. Check out the conversation and recording from that meeting.

Suppose we make the domain/discovery portion of a did:webvh DID optional to enable use cases where the locationsof the DID Log and witness files are known based on the context/ecosystem of the DID usage. In such cases, the resolver would have to know where to get the files for processing. All of the other features of the DID remain. When the domain part of the DID is missing, a client could use a DID URL query parameter src to specify a URL of where to find the DID Log file (and hence, the witness.json file).

Use cases:

  • An alternative to did:peer for Peer DIDs, where parties exchange DIDs directly for peer-to-peer use vs. publishing them for all to see. Note that how the DIDs are exchanged is outside of the did:webvh spec.
  • Similar to how did:plc is used where the context of the DID usage (in ATProto exchanges) is sufficient to know the location of the DID Log.
  • In an ecosystem where the DID Logs are stored in known locations such as watchers. With did:webvh watchers, the querying of a Watcher uses only the SCID -- not the entire DID.
  • Where the DID itself has no location component, but the src DID URL query parameter is always used. The result is almost the same as the did:webvh with a location component, but removes the location component from the DID itself.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Next VersionIssues that should be considered in the context of the next version of the specification.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions