-
Notifications
You must be signed in to change notification settings - Fork 16
Open
Labels
Next VersionIssues that should be considered in the context of the next version of the specification.Issues that should be considered in the context of the next version of the specification.
Description
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
Labels
Next VersionIssues that should be considered in the context of the next version of the specification.Issues that should be considered in the context of the next version of the specification.