...

This flow is shown by figure 1, below:

Figure 1: The normal DID resolution process

DID URL Dereferencing

DID URL Dereferencingis the process of resolving a DID to a DID document in order to determine how to dereference the remainder of the DID URL (path, query, fragment as defined by the ABNF in section 3.2 of the DID 1.0 specification.)

...

1. A DID is resolved to a DID Document;
2. A resource within the DID Document is identified, based on the portion of the DID URL that follows the DID (path, query, fragment as defined by the ABNF in section 3.2 of the DID 1.0 specification.).
   

An example is processing a DID fragment to return a specific public key from the DID Document. Or alternatively, processing a DID query to return a specific service endpoint, specified in the service section of the DID Document.

...

Figure 2: The normal DID URL Dereferencing process

(Note: The specifics of how dereferencing operates depends on the DID URL and the DID method.)

Motivations

The aim of this specification is to create a more resilient, tamper-resistant, highly available and standardized way of storing, referencing and retrieving resources (such as data schemas, interface definitions, governance or policy definitions), using DID URLs to identify resources written directly to a Verifiable Data Registry. 

On-ledger Resources identifiable via DID URLs

Central to this specification is the idea of a DID URL dereferencing directly to a resource, rather than first dereferencing to a DID Document. 

This is an exception to the normal 2-step resolution/dereferencing process, enabling the DID itself to directly identify a digital resource that can be returned directly by the VDR of the associated DID method. This behavior may be desirable:

...

This flow is shown in figure 3, below:

Image Modified

Figure 3: The relationship of DIDs, DID URLs, DID documents, and Resources

...

Resource Parameters for Resolution and Dereferencing

To enable this combined resolution/dereferencing behavior, this specification defines multiple DID URL parameters to fetch resource. If a DID method specification supports these parameters, and if a DID URL using that method includes the parameter with a valid value, then when a resolver calls the associated VDR using that DID URL, the VDR returns the identified digital resource, not the DID document.

Common and standardized resource parameters:

Error messages

There MAY be instances where the resolver has not been provided enough specific information to process the request and fetch a single resource. 

Verifiable Data Registry (VDR) and DID Method Requirements

A Verifiable Data Registry (VDR) and DID Method conforming to this specification to include support for resources identifiable via DID URLs:

1. MUST define:
   1. A method to write a resource to the VDR resource which is mapped to an associated DID Document

   2. A method to map the individual fields of the resource metadata to the resource parameters listed above.

   3. A method to reference resources within the associated DID Document: 

      1. MAY include in the associated DID document an alsoKnownAs property containing at least one value that is a hashlink to the identified digital resource. This provides additional cryptographic verification of the binding between the DID and the identified digital resource. This approach MAY be used when there is ONLY one resource associated with a DID and DID Document.

      2. MAY include references to the associated on-ledger resources within the didDocumentMetadata property, for example:

         Code Block
         language js firstline 1 title Linked Resource Metadata
         "didDocumentMetadata": { "created": "2022-07-19T08:29:07Z", "versionId": "57543FA1D9C56033BABBFA3A438E0A149E01BBB89E6D666ACE1243455AA6F2BC", "linkedResourceMetadata": [ { "resourceURI": "did:cheqd:mainnet:46e2af9a-2ea0-4815-999d-730a6778227c/resources/0f964a80-5d18-4867-83e3-b47f5a756f02", "resourceCollectionId": "46e2af9a-2ea0-4815-999d-730a6778227c", "resourceId": "0f964a80-5d18-4867-83e3-b47f5a756f02", "resourceName": "DegreeLaw", "resourceType": "CL-Schema", "mediaType": "application/json", "created": "2022-07-19T08:40:00Z", "checksum": "7b2022636f6e74656e74223a202274657374206461746122207d0ae3b0c44298", "previousVersionId": null, // null if no previous version, otherwise, resourceId of previous version "nextVersionId": null, // null if no new version, otherwise, resourceId of new version } ] }

         
         

   4. How the VDR shall determine the default media type for the resource written to the VDR.
   5. How the VDR shall return the resource in response to a request from a conforming DID resolver.
   6. Important: If the DID alone is resolved without a resource parameter, it MUST return the authoritative DID document as defined in W3C Decentralized Identifiers (DIDs) 1.0. This specification adds no additional requirements to a conforming DID document. To enable this combined resolution/dereferencing behavior, this specification defines multiple new DID URL parameters for retrieving resources. If a DID method specification supports this specification, and if a DID URL using that method includes a parameter with a valid value, then when a resolver calls the associated VDR using that DID URL, the VDR returns the identified digital resource, or metadata associated with the resource.

Example of resource fields