DID-Linked Resources

1. Introduction

DID-Linked Resources (DLRs) are digital files that can be retrieved and referenced using a persistent and unique DID URL.

This specification defines common requirements, patterns, algorithms including their request formats and response formats, architectural options, and various considerations for how DID-Linked Resources SHOULD act as persistent identifiers for referencing and retrieving digital Resources (such as data schemas, status lists, trust registries, governance documents, or policy definitions). This specification complements the DID Resolution Specification, including its patterns and algorithms for DID URL resolution and dereferencing.

By using DID URLs which remain conformant with W3C Decentralized Identifiers (DIDs) v1.0 Recommendation [DID-CORE] and the DID Resolution Specification, existing DID Resolvers will be able to dereference these DID URLs to retrieve the identified resources using the DID URL query syntax in this specification.

1.1. Context for Specification

The [DID-CORE] specification defines an interoperable standard for DID documents and associated core properties, however, it does not currently have a standardized way to specify properties of Resources associated with DIDs, nor how to consistently reference nor retrieve them.

Digital Resources are generally stored on traditional centralized-storage endpoints, but this comes with certain drawbacks:

1. Digital Resources could be tampered with by compromising the hosting provider: Digital Resources stored at a centralized web endpoint can be compromised and replaced by malicious actors.

2. Hosting providers could unilaterally cease to host particular clients: Hosting providers could terminate accounts due to factors such as non-payment of fees, violation of Terms of Service, etc.

3. Single point of failure (SPOF): Even with highly-trusted and sophisticated hosting providers who may not present a risk of infrastructure being compromised, a service outage at the hosting provider can make a Resource anchored on their systems inaccessible.

Despite these issues, many decentralized identity and digital credential implementations, even ones that use ledgers or other distributed systems for DIDs, often use centralized storage. From the W3C Verifiable Credential Implementation Guide.

Example schema.org address with full URLs:

{
  "@type": "http://schema.org/Person",
  "http://schema.org/address": {
    "@type": "http://schema.org/PostalAddress",
    "http://schema.org/streetAddress": "123 Main St.",
    "http://schema.org/addressLocality": "Blacksburg",
    "http://schema.org/addressRegion": "VA",
    "http://schema.org/postalCode": "24060",
    "http://schema.org/addressCountry": "US"
  }
}

Using traditional web endpoints to store digital resources that are critical for a Verifiable Credential to function detracts from the proper functioning and utility that persistently-accessible Decentralized Identifiers offer. It can also result in inconsistent and unstandardized approaches to storing, referencing, and retrieving digital resources such as schemas, trust registries, and status lists.

1.2. A Simple Example

To illustrate the concept of **DID-Linked Resources** (DLRs), one of the core concepts is the **parent-child relationship** between a DID and its resources. Consider the following simple example where **Entity A’s** DID (`did:example:entity123`) is the **parent**, and its associated resources are the **children**. Each resource is uniquely identified by an identifier, such as a UUID, and is bound to the DID under paths like `/resources/{resourceId}`. For example, the URI `did:example:entity123/resources/41c0f0fe-cd4e-45aa-aec5-754db4a63865` points to a specific resource controlled by Entity A.

The DID controller, Entity A, has authority over these child resources, and each resource is independently addressable by its unique identifier, but remains logically tied to the parent DID. This structure allows flexible management of resources while maintaining the DID as the authoritative identifier.

1.3. Architecture Overview

The relationship between DIDs and Resources is shown in the diagram below:

1.4. Design Principles

The following design principles should be taken into consideration. DID-Linked Resources SHOULD:

1. Use existing and familiar DID Core Spec patterns where possible.

2. Support existing DID Resolvers and principles of DID URL dereferencing.

3. Protect against linkrot for long-term retrieval.

4. Enable resources to be versioned and organized, with individual versions being able to be fetched.

5. Include semantic linkage between DID documents and associated resources (via metadata or otherwise).

1.5. Conformance

In addition to sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative. The key words MAY, MUST, MUST NOT, OPTIONAL, and SHOULD in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Terminology

DID Controller: As defined in [DID-CORE].

DID Document: As defined in [DID-CORE].

DID URL: As defined in [DID-CORE].

DID URL Dereferencing: As defined in [DID-CORE].

DID-Linked Resource: Digital files that can be retrieved and referenced using persistent and unique DID URLs.

Resource Collection: An organized and structured set of digital resources, collectively and individually identifiable using persistent and unique DID URLs.

Resource ID: A unique identifier for a specified DID-Linked Resource.

3. DID-Linked Resource URI Syntax

The following is the ABNF definition using the syntax in [RFC5234]. All DID-Linked Resources MUST conform to the DID-Linked Resource URI Syntax ABNF Rules.

; DID-Linked Resource URI
dlr-uri = did path-abempty [ "?" query ] [ "#" fragment ]

; DID (per W3C DID Core)
did = "did:" method ":" method-specific-id
method = 1*method-char
method-char = ALPHA / DIGIT / "-"
method-specific-id = 1*( idchar / ":" )
idchar = ALPHA / DIGIT / "." / "-" / "_" / pct-encoded
pct-encoded = "%" HEXDIG HEXDIG

; Resource path
path-abempty = *( "/" segment )
segment = *pchar

; Optional query and fragment (RFC 3986)
query = *( pchar / "/" / "?" )
fragment = *( pchar / "/" / "?" )

; Character classes
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
ALPHA = %x41-5A / %x61-7A
DIGIT = %x30-39

=== Semantics

The components of a DID-Linked Resource URI carry the following semantics:

• The `did` component identifies the base Decentralized Identifier (DID) under which the resource is logically scoped.

• The `path` identifies the logical or versioned name of the resource. This SHOULD be defined at the DID method level and may represent for example:

• A generalized resource (`/resources/1234`)

• A specific resource, such as a schema (`/schema/1234`)

• A different attachment or file (e.g., `/assets/image.png`)

• The `fragment` MAY refer to a sub-component within the resource (e.g., a specific field in a schema, or a section in a document).

4. Core Properties

The following tables contain informative references for the core properties defined by this specification, with expected values, and whether or not they are required. The property names in the tables are linked to the normative definitions and more detailed descriptions of each property.

4.1. Resource URI

DID-Linked Resources (DLRs) are content-addressable or identifier-addressable resources associated with a Decentralized Identifier (DID). They are represented as URIs rooted at a valid DID. The full Resource URI identifying a Resource MUST include a DID and a Resource Identifier `resourceId`.

4.2. Resource Identifiers

A Resource Identifier, or `resourceId`, MUST be a unique identifier for a single resource. Two resources under the same DID method MUST NOT share the same `resourceId`.

4.3. Resource Collection ID

The `resourceCollectionId` property is OPTIONAL. This property is the unique identifier of the DID that the resource is bound to, under which resources are logically collected.

For example, the following DID:

did:example:0a5b94d0-a417-48ed-a6f5-4abc9e95888d

will derive the Collection ID:

0a5b94d0-a417-48ed-a6f5-4abc9e95888d

4.4. Resource Name

The `resourceName` property is OPTIONAL. If present, the value of the type property MUST be expressed as an [ASCII string](https://infra.spec.whatwg.org/#ascii-string).

4.5. Resource Type

The `resourceType` property is OPTIONAL. If present, the value of the type property MUST be expressed as an [ASCII string](https://infra.spec.whatwg.org/#ascii-string). In order to maximize interoperability, the resource type and its associated properties SHOULD be registered in the DID Specification Registries [DID-SPEC-REGISTRIES].

4.6. Resource Version

The `resourceVersion` property is OPTIONAL. If present, the value of the type property be expressed as an [ASCII string](https://infra.spec.whatwg.org/#ascii-string).

4.7. Alternative URI

The `alternativeUri` property is OPTIONAL. If present, the value MUST be a set where each item in the set is a URI conforming to [RFC3986].

4.8. Resource Metadata Properties

4.8.1. Media Type {#mediatype}

The `mediaType` property is OPTIONAL. If present, the value must be expressed as an [ASCII string](https://infra.spec.whatwg.org/#ascii-string) and SHOULD match the underlying IANA media type of the file of the resource identified by the resourceId.

4.8.2. Checksum {#checksum}

The `checksum` property is OPTIONAL. If present, the value SHOULD be an equivalent representation of the resource identified by the resourceId.

4.8.3. Created {#created}

The `created` property is OPTIONAL. If present, the value of the property MUST be a string formatted as an XML Datetime normalized to UTC 00:00:00 and without sub-second decimal precision. For example: 2020-12-20T19:17:47Z.

4.8.4. Updated {#updated}

The `updated` property is OPTIONAL. If present, the value of the property MUST be a string formatted as an XML Datetime normalized to UTC 00:00:00 and without sub-second decimal precision. For example: 2020-12-20T19:17:47Z.

4.8.5. PreviousVersionId {#previousversionid}

The `previousVersionId` property is OPTIONAL. If present, the value should reference the directly previous version of the resource. The value of the property MUST be an ASCII string.

4.8.6. NextVersionId {#nextversionid}

The `nextVersionId` property is OPTIONAL. If present, the value should reference the directly next version of the resource. The value of the property MUST be an ASCII string.

5. Binding to DIDs

In the context of DID-Linked Resources (DLRs), **binding** refers to the relationship between a resource and a Decentralized Identifier (DID). This binding is OPTIONAL, but it is highly recommended.

A DID acts as the **parent** that has authority over the resource, which is the **child**. The DID controller (the entity controlling the DID) has control over the resource and can modify, update or deprecate it.

In this context, the DID itself becomes a **collection**, within which one or multiple resources can be referenced.

In this parent-child relationship:

• The **DID** is the **parent** entity. It serves as the root identifier for an entity, and a collection for the resources, and has the authority to control or manage resources associated with it.

• The **resource** is the **child** entity. A resource is a specific object or piece of data associated with the DID. The resource can include things like schemas, files, metadata, or any other linked data related to the DID.

The binding of a resource to a DID ensures that the DID controller has control over the resource and that the resource is logically scoped within the DID’s authority.

Multiple resources MAY be bound to the same DID, and each MUST include a unique `resourceId`.

This relationship MAY be enforced and validated by the underlying infrastructure (such as a distributed ledger consensus mechanism), or through other cryptographic techniques, defined by the DID Method implementing DID-Linked Resources.

5.1. Representations

Resources linked to a DID should be represented in a way that maintains a verifiable association with that DID. The metadata describing each Resource SHOULD be included as part of the DID Document Metadata, rather than within the DID Document itself. This allows for clear delineation between identity-related data and externally linked Resources.

To ensure the integrity and traceability of Resources associated with a DID, the `didDocumentMetadat`a object MAY include a `linkedResourceMetadata` array. Each entry in this array corresponds to a distinct Resource that is logically bound to the DID. Resources MAY be grouped or indexed by name and type, allowing multiple different resources (not necessarily different versions of the same one) to be managed within a single logical collection.

This approach provides flexibility for DID controllers to organize and track various types of linked Resources while preserving clear versioning relationships and semantic meaning.

5.2. Representation within DID Document Metadata

The `linkedResourceMetadata` array is used to track these resources, where each entry corresponds to a specific resource within the collection. Each resource metadata entry SHOULD includes the properties included in the Core Properties, including links to previous and subsequent versions (if applicable). This allows for a clear versioning and management system while supporting the inclusion of different types of resources in a single collection.

The syntax of the `didDocumentMetadata` including `linkedResourceMetadata` is as follows:

"didDocumentMetadata": {
    "created": "2020-12-20T19:17:47Z",
    "updated": "",
    "deactivated": false,
    "versionId": "bdab59b0-66f5-42d3-b809-1829bdcc0408",
    "previousVersion": "",
    "nextVersion": "",
    "linkedResourceMetadata": [
      { // First version of a Resource called PassportSchema
        "resourceURI": "did:example:13d5ad44-9e99-428f-81e9-274458cefddc/resources/44547089-170b-4f5a-bcbc-06e46e0089e4",
        "resourceCollectionId": "13d5ad44-9e99-428f-81e9-274458cefddc", // Common collection ID
        "resourceId": "44547089-170b-4f5a-bcbc-06e46e0089e4", // Old Resource ID and version number
        "resourceName": "PassportSchema", // Resource name must remain the same
        "resourceType": "CL-Schema", // Resource type must remain the same
        "resourceVersion": "1.0.1", // A user-set version
        "mediaType": "application/json",
        "created": "2022-07-19T08:40:00Z",
        "checksum": "7b2022636f6e74656e74223a202274657374206461746122207d0ae3b0c44298", // Old version checksum
        "previousVersionId": "", // empty string, since no previous version
        "nextVersionId": "bb2118f3-5e55-4510-b420-33ef9e1726d2", // Points to next version below
        },
      { // Second version of a Resource called PassportSchema
        "resourceURI": "did:example:13d5ad44-9e99-428f-81e9-274458cefddc/resources/bb2118f3-5e55-4510-b420-33ef9e1726d2",
        "resourceCollectionId": "13d5ad44-9e99-428f-81e9-274458cefddc", // Common collection ID
        "resourceId": "bb2118f3-5e55-4510-b420-33ef9e1726d2", // New Resource ID and version number
        "resourceName": "PassportSchema", // Resource name must remain the same
        "resourceType": "JSONSchema2020", // Resource type must remain the same
        "resourceVersion" "1.0.1" // user-set semantic version control
        "mediaType": "application/json",
        "created": "2022-08-07T08:40:00Z",
        "checksum": "9123dcbb0b42652b0e105956c68d3ca2ff34584f324fa41a29aedd32b883e131", // New version checksum
        "previousVersionId": "44547089-170b-4f5a-bcbc-06e46e0089e4", // Points to previous version above
        "nextVersionId": "0be87654-4a48-4f8e-8789-15ec3589ccdd" // Points to next version. Empty string if no new version
        },
    { // First version of a different Resource called IDCardSchema
      "resourceURI": "did:example:13d5ad44-9e99-428f-81e9-274458cefddc/resources/12345678-90ab-cdef-1234-567890abcdef",
      "resourceCollectionId": "13d5ad44-9e99-428f-81e9-274458cefddc", // Same collection ID
      "resourceId": "12345678-90ab-cdef-1234-567890abcdef", // New Resource ID and version number
      "resourceName": "IDCardSchema", // Resource name must remain the same
      "resourceType": "JSONSchema2020", // Resource type must remain the same
      "resourceVersion": "1.0.0", // User-set version
      "mediaType": "application/json",
      "created": "2022-09-01T09:30:00Z",
      "checksum": "a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0u1v2w3x4y5z6", // Version checksum
      "previousVersionId": "", // Empty string, no previous version
      "nextVersionId": "" // Empty string, no next version
      }
      ]
    }

All required fields defined under Core Properties MUST be included for each Resource Metadata entry.

5.3. Resource Representation

Resources linked to a DID via a DID-Linked Resource mechanism MUST be retrievable either individually (by their full resourceId) or in aggregate (by querying resources linked to a given DID, using a particular filter).

When queried individually, the result MUST return the full Resource representation associated with the provided resourceId.

When queried in aggregate, the result MUST return an array of Resource Metadata entries, each describing a distinct Resource or version of the same resource. These metadata entries provide an overview of the linked Resources without including the Resources’ full content or returning the DID Document itself.

6. Resource Parameters

The Resource URI syntax supports a simple format for parameters (see section Query in [DID-CORE]). Adding a resource parameter to a Resource URI means that the parameter becomes part of the identifier for a resource.

Resource parameters are completely independent of any specific DID method and function the same way for all DIDs.

7. Resolution and Dereferencing

Requests to fetch Resources are considered as a DID URL Dereferencing scenario it uses [DID URL paths](https://w3c.github.io/did-core/#path) to lead to a Resource object, rather than a DIDDoc.

The DID URL dereferencing function dereferences a Resource URI (a type of DID URL), into a resource with contents depending on the DID URL’s components, including the DID method, method-specific identifier, path, query, and fragment. This process depends on DID resolution of the DID contained in the DID URL. DID URL dereferencing might involve multiple steps (e.g., when the DID URL being dereferenced includes a fragment), and the function is defined to return the final resource after all steps are completed.

Normal DID URL dereferencing can be understood as a two-step process:

1. Resolution: The DID is resolved to its corresponding DID Document using the relevant DID method.

2. Dereferencing: A Resource is located using the path, query, and/or fragment components of the DID URL, which point to the Resource either directly or by reference.

Unlike standard DID dereferencing that fetches a section of the DID Document (such as a service or verification method), dereferencing a Resource URI returns an external Resource object that is linked to, but not contained within, the DID Document.

Dereferencing a Resource URI returns the full Resource representation. In parallel, a metadata representation describing that Resource MUST also be obtainable—either alongside the Resource itself or via a distinct query mechanism (e.g., via content negotiation or an aggregate query over the DID).

This metadata allows clients to understand key attributes of the Resource without retrieving or parsing the entire Resource content. It also supports version tracking, indexing, and discoverability in decentralized systems.

Below is an example of a Resource Metadata structure:

{
  "resourceUri": "did:example:13d5ad44-9e99-428f-81e9-274458cefddc/resources/bb2118f3-5e55-4510-b420-33ef9e1726d2",
  "resourceCollectionId": "13d5ad44-9e99-428f-81e9-274458cefddc",
  "resourceId": "bb2118f3-5e55-4510-b420-33ef9e1726d2",
  "resourceName": "PassportSchema",
  "resourceType": "JSONSchemaValidator2020",
  "resourceVersion": "1.0.1",
  "mediaType": "application/json",
  "created": "2022-04-20T20:19:19Z",
  "checksum": "a7c369ee9da8b25a2d6e93973fa8ca939b75abb6c39799d879a929ebea1adc0a",
  "previousVersionId": "67f2df00-0b6e-404b-8c70-1d63200e6412",
  "nextVersionId": "98922424-c214-4439-b52c-f68ddb450b40",
  "alsoKnownAs": [{
      "uri": "https://example.com/alternative-uri",
      "description": "Alternative URI description"
      },
      {
      "uri": "https://example.com/alternative-uri",
      "description": "Alternative URI description"
      }]
}

8. Rules and Logic for Handling Ambiguous Queries

This section describes how the resolver handles complex or ambiguous dereferencing requests. The resolver applies consistent logic and default behaviors to ensure predictable outcomes for clients.

8.1. Ambiguity Triggers Errors

If a query results in multiple matching resources and does not include sufficient parameters to disambiguate between them, the resolver MUST return an error.

For example, a query that specifies a `resourceType` where multiple resources share that type but differ in `resourceName` will result in an error due to ambiguity.

8.2. Multiple Versions of the Same Resource

If multiple versions of a single resource exist—meaning the resources have the same `resourceType` and `resourceName`, but different `versionId` values—and no specific version is requested, the resolver MUST default to returning the latest version.

This situation is not considered ambiguous, as the resource identity is clear; only the version is unspecified.

8.3. Ambiguous Query with `resourceMetadata=true`

When a query is ambiguous, but includes the `resourceMetadata=true` parameter, the resolver SHOULD return metadata for all matching resources that could be the intended target.

This enables clients to inspect available options and decide which resource to dereference.

For example, the following request would return metadata for all resources matching the specified `resourceType`, regardless of differing `resourceName` values.:

did:example:c1685ca0-1f5b-439c-8eb8-5c0e85ab7cd0?resourceType=String&resourceMetadata=true

{
    "@context": "https://w3id.org/did-resolution/v1",
    "dereferencingMetadata": {
        "contentType": "application/did+ld+json",
        "retrieved": "2023-04-26T15:38:26Z",
        "did": {
            "didString": "did:example:c1685ca0-1f5b-439c-8eb8-5c0e85ab7cd0",
            "methodSpecificId": "c1685ca0-1f5b-439c-8eb8-5c0e85ab7cd0",
            "method": "example"
        }
    },
    "contentStream": {
        "created": "2023-01-25T11:58:10.390039347Z",
        "versionId": "e5615fc2-6f13-42b1-989c-49576a574cef",
        "linkedResourceMetadata": [
            {
                "resourceURI": "did:example:c1685ca0-1f5b-439c-8eb8-5c0e85ab7cd0/resources/9ba3922e-d5f5-4f53-b265-fc0d4e988c77",
                "resourceCollectionId": "c1685ca0-1f5b-439c-8eb8-5c0e85ab7cd0",
                "resourceId": "9ba3922e-d5f5-4f53-b265-fc0d4e988c77",
                "resourceName": "exampleResourceName1",
                "resourceType": "exampleResourceType",
                "mediaType": "application/json",
                "resourceVersion": "",
                "created": "2023-01-25T12:08:39.63Z",
                "checksum": "e1dbc03b50bdb995961dc8843df6539b79d03bf49787ed6462189ee97d27eaf3",
                "previousVersionId": null,
                "nextVersionId": null
            },
            {
                "resourceURI": "did:example:c1685ca0-1f5b-439c-8eb8-5c0e85ab7cd0/resources/e733ebb7-c8dd-41ed-9d42-33bceea70952",
                "resourceCollectionId": "c1685ca0-1f5b-439c-8eb8-5c0e85ab7cd0",
                "resourceId": "e733ebb7-c8dd-41ed-9d42-33bceea70952",
                "resourceName": "exampleResourceName2",
                "resourceType": "exampleResourceType",
                "mediaType": "application/json",
                "resourceVersion": "",
                "created": "2023-01-25T12:04:52.26Z",
                "checksum": "cffd829b06797f85407be9353056db722ca3eca0c05ab0462a42d30f19cdef09",
                "previousVersionId": null,
                "nextVersionId": null
            }
        ]
    },
    "contentMetadata": {}
}

8.4. HTTP Accept Headers

Clients MAY use the `Accept` HTTP header to express a preference for the media type of the dereferenced resource.

The resolver MUST respect the `Accept` header if possible and return a resource representation that matches the requested media type. If no exact match is found, the resolver SHOULD return an error status, following the statuses in the DID Resolution Spec, or fall back to a default media type if appropriate.

9. Resolution and Dereferecing examples

9.1. ResourceMetadata and Filter

This parameter is a filter that specifically returns metadata of one or more resources and can be combined with other filters, for specific filtering. The optional variants are:

• `resourceMetadata=true`

• `resourceMetadata=false`

• Unused

For example:

did:example:d8ac0372-0d4b-413e-8ef5-8e8f07822b2c?resourceType=exampleSchema&resourceName=exampleResourceName&resourceMetadata=true

{
    "@context": "https://w3id.org/did-resolution/v1",
    "dereferencingMetadata": {
        "contentType": "application/did+ld+json",
        "retrieved": "2023-04-27T11:10:17Z",
        "did": {
            "didString": "did:example:d8ac0372-0d4b-413e-8ef5-8e8f07822b2c",
            "methodSpecificId": "d8ac0372-0d4b-413e-8ef5-8e8f07822b2c",
            "method": "example"
        }
    },
    "contentStream": {
        "created": "2023-02-21T14:28:47.40Z",
        "versionId": "44f49254-8106-40ee-99ad-e50ac9517346",
        "linkedResourceMetadata": [
            {
                "resourceURI": "did:example:d8ac0372-0d4b-413e-8ef5-8e8f07822b2c/resources/bae5cb6c-564a-4ed4-8c0e-d5c3b0f8ae0a",
                "resourceCollectionId": "d8ac0372-0d4b-413e-8ef5-8e8f07822b2c",
                "resourceId": "bae5cb6c-564a-4ed4-8c0e-d5c3b0f8ae0a",
                "resourceName": "exampleResourceName",
                "resourceType": "exampleResourceType",
                "mediaType": "application/json",
                "resourceVersion": "1.14.41",
                "created": "2023-02-22T08:57:23.34Z",
                "checksum": "93ba6f3c55ee073e6278f98e820776e73cfd9d3e32dc5882507ee8effbdbfadd",
                "previousVersionId": "40829caf-b415-4b1d-91a3-b56dfb6374f4",
                "nextVersionId": null
            },
            {
                "resourceURI": "did:example:d8ac0372-0d4b-413e-8ef5-8e8f07822b2c/resources/40829caf-b415-4b1d-91a3-b56dfb6374f4",
                "resourceCollectionId": "d8ac0372-0d4b-413e-8ef5-8e8f07822b2c",
                "resourceId": "40829caf-b415-4b1d-91a3-b56dfb6374f4",
                "resourceName": "exampleResourceName",
                "resourceType": "exampleResourceType",
                "mediaType": "application/json",
                "resourceVersion": "1.45.24",
                "created": "2023-02-22T08:55:07.54Z",
                "checksum": "2a6af570635ed49a39eae9a9c60ccb40d61466839d4ab2f17432a8ac705da489",
                "previousVersionId": "547abdb3-99f8-4040-b030-3296c4668846",
                "nextVersionId": "bae5cb6c-564a-4ed4-8c0e-d5c3b0f8ae0a"
            },
            {
                "resourceURI": "did:example:d8ac0372-0d4b-413e-8ef5-8e8f07822b2c/resources/547abdb3-99f8-4040-b030-3296c4668846",
                "resourceCollectionId": "d8ac0372-0d4b-413e-8ef5-8e8f07822b2c",
                "resourceId": "547abdb3-99f8-4040-b030-3296c4668846",
                "resourceName": "exampleResourceName",
                "resourceType": "exampleResourceType",
                "mediaType": "application/json",
                "resourceVersion": "1.42.26",
                "created": "2023-02-22T08:54:14.48Z",
                "checksum": "4524f2193da6e5cc28d8a71f268d097891d053d4f206b045347ae117ce70d8ac",
                "previousVersionId": null,
                "nextVersionId": "40829caf-b415-4b1d-91a3-b56dfb6374f4"
            }
        ]
    },
    "contentMetadata": {}
}

9.2. ResourceId Parameter

`resourceId` parameter can be used for filtering a particular resource version by specifically identifying its unique ID.

For example:

did:example:b5d70adf-31ca-4662-aa10-d3a54cd8f06c?resourceId=5e16a3f9-7c6e-4b6b-8e28-20f56780ee25

{
  "title": "Example Verifiable Credential Schema",
  "description": "Example schema for DID-Linked Resources spec",
  "type": "object",
  "properties": {
    "@context": {
      "description": "Defines semantic context of the Example Credential",
      "type": "array",
        "items": {
          "type": "string",
          "format": "uri"
        }
    }
  }  
}

9.3. ResourceCollectionId Parameter

`resourceCollectionId` parameter filters all resources linked to a particular DID by the `collectionId` property. It is recommended that this query is only used when there is one resource linked to a DID. If it is used with multiple resources, it is recommended to be combined with another query parameter to act as a filter such as `resourceMetadata=true`. Otherwise, it is likely to result in an ambigous query.

For example:

did:example:d8ac0372-0d4b-413e-8ef5-8e8f07822b2c?resourceCollectionId=d8ac0372-0d4b-413e-8ef5-8e8f07822b2c

{
  "title": "Example Verifiable Credential Schema",
  "description": "Example schema for DID-Linked Resources spec",
  "type": "object",
  "properties": {
    "@context": {
      "description": "Defines semantic context of the Example Credential",
      "type": "array",
        "items": {
          "type": "string",
          "format": "uri"
        }
    }
  }  
}

9.4. ResourceType Parameter

This parameter is another filter for the `resourceType` property. Again, this should only be used if there is one resource associated with the DID. Otherwise additional filters should be added to avoid ambiguous queries.

For example:

did:example:d8ac0372-0d4b-413e-8ef5-8e8f07822b2c?resourceType=exampleResourceType

{
  "title": "Example Verifiable Credential Schema",
  "description": "Example schema for DID-Linked Resources spec",
  "type": "object",
  "properties": {
    "@context": {
      "description": "Defines semantic context of the Example Credential",
      "type": "array",
        "items": {
          "type": "string",
          "format": "uri"
        }
    }
  }  
}

9.5. ResourceName Parameter

This parameter is a filter for the `resourceName` property. Again, this should only be used if there is one resource associated with the DID. Otherwise additional filters should be added to avoid ambiguous queries.

For example:

did:example:d8ac0372-0d4b-413e-8ef5-8e8f07822b2c?resourceName=exampleResourceName

{
  "title": "Example Verifiable Credential Schema",
  "description": "Example schema for DID-Linked Resources spec",
  "type": "object",
  "properties": {
    "@context": {
      "description": "Defines semantic context of the Example Credential",
      "type": "array",
        "items": {
          "type": "string",
          "format": "uri"
        }
    }
  }  
}

9.6. ResourceName and ResourceType Parameters

This is a combined filter that SHOULD fetch the latest version of the resource, of the same name and type.

For example:

did:example:d8ac0372-0d4b-413e-8ef5-8e8f07822b2c?resourceName=exampleResourceName

{
  "title": "Example Verifiable Credential Schema",
  "description": "Example schema for DID-Linked Resources spec",
  "type": "object",
  "properties": {
    "@context": {
      "description": "Defines semantic context of the Example Credential",
      "type": "array",
        "items": {
          "type": "string",
          "format": "uri"
        }
    }
  }  
}

did:example:d8ac0372-0d4b-413e-8ef5-8e8f07822b2c?resourceVersion=b9029cf7-c40b-4850-b9a1-9bfad46a68d7

{
  "title": "Example Verifiable Credential Schema",
  "description": "Example schema for DID-Linked Resources spec",
  "type": "object",
  "properties": {
    "@context": {
      "description": "Defines semantic context of the Example Credential",
      "type": "array",
        "items": {
          "type": "string",
          "format": "uri"
        }
    }
  }  
}

did:example:d8ac0372-0d4b-413e-8ef5-8e8f07822b2c?resourceVersionTime=2023-02-22T06:58:18.61Z&resourceVersion=1.14.41

{
  "title": "Example Verifiable Credential Schema",
  "description": "Example schema for DID-Linked Resources spec",
  "version": "1.14.41",
  "type": "object",
  "properties": {
    "@context": {
      "description": "Defines semantic context of the Example Credential",
      "type": "array",
        "items": {
          "type": "string",
          "format": "uri"
        }
    }
  }  
}

did:example:d8ac0372-0d4b-413e-8ef5-8e8f07822b2c?checksum=27ad51a49f079a6634b18bbc3ac08dd2d91f13fabf72ea8e5d83692fe4820058

{
  "title": "Example Verifiable Credential Schema",
  "description": "Example schema for DID-Linked Resources spec",
  "version": "1.14.41",
  "type": "object",
  "properties": {
    "@context": {
      "description": "Defines semantic context of the Example Credential",
      "type": "array",
        "items": {
          "type": "string",
          "format": "uri"
        }
    }
  }  
}