Skip to content

DID URL Dereferencing

DID URL dereferencing retrieves resources using DID URLs. This differs from DID resolution, which retrieves complete DID documents.

These two processes serve different but complementary purposes in the DID ecosystem:

ProcessPurposeInputOutput
DID ResolutionObtains a DID document for a given DIDA DID (did:example:123)A complete DID document
DID URL DereferencingRetrieves a specific resource identified by a DID URLA DID URL (did:example:123/path?query#fragment)A specific resource (document fragment, verification method, service endpoint, or external resource)

The dereferencing process:

  1. Parse the DID URL to extract the DID and additional components
  2. Resolve the DID to obtain the DID document
  3. Identify the target resource based on additional components
  4. Return the resource

A DID URL contains the DID (base identifier), path (specific resource), query parameters (additional instructions), and fragment (specific part of resource) that determine what resource is returned.

Common Use Cases for DID URL Dereferencing

Section titled “Common Use Cases for DID URL Dereferencing”

DID URL dereferencing enables verification method access (retrieving specific cryptographic keys), service endpoint retrieval (accessing associated service endpoints), external resource access (obtaining controller-hosted resources), historical version access (retrieving specific document versions), and linked resource retrieval (obtaining registry-linked resources).

Dereferencing outcomes: success with resource (returns requested resource), success with redirection (resource located elsewhere), or failure (invalid DID URL, resource not found, lack of permissions).

Metadata includes dereferencing options (input metadata affecting how dereferencing occurs), dereferencing metadata (output metadata about the process), and content metadata (resource information).

DID URL parameters influence how dereferencing happens:

  • service: Identifies a service endpoint in the DID document
  • relativeRef: Specifies a resource relative to a service endpoint
  • versionId: Requests a specific version of a DID document
  • versionTime: Requests the DID document as it existed at a specific time
  • hl: Provides integrity protection through resource hashing

Dereferencing failures return specific error codes: invalidDidUrl (invalid syntax), notFound (resource doesn’t exist), and contentTypeNotSupported (content type unavailable).

Relationship to the Vidos Universal Resolver

Section titled “Relationship to the Vidos Universal Resolver”

The Vidos Universal Resolver implements DID URL dereferencing according to W3C DID Core specification, providing standardized resource access across different DID methods.

Consider that dereferencing might reveal accessed resources, some resources may require authentication/authorization, verify integrity of retrieved resources for critical operations, and consider caching implications for frequently accessed resources.