Technical composition of DID-Linked Resources
Last updated
Last updated
"Resources" are identified with a did:cheqd Decentralized Identifier with a Universally Unique Identifier (UUID) that acts as a permanently-accessible link to fetch the resources from the cheqd ledger. We refer to this as the "resource ID".
Using UUIDs, we can have a high level of confidence that no two identical resource IDs will ever be created. This is important for ensuring the integrity and uniqueness of each individual resource.
Figure 1: DID-linked Resource DID URL path
This will be explained further in the section on DID URL dereferencing to fetch a resource.
Resources are organised into groups called "Collections". Each DID may have an associated Collection, and the Collection ID is derived from the unique identifier of the DID.
Collections can store any type of Resource, but for the purpose of this documentation we will focus on the use case where the Collection is used for storing a set of schemas.
The most important concept used in this design is that each on-ledger Collection is identified using a DID and is described using a DID Document.
The DID Document acts as metadata, providing information about the Collection, such as who is able to update it, when it was created and what are the latest and deprecated versions of Resources within the Collection.
For example, the following DID:
did:cheqd:mainnet:1f8e08a2-eeb6-40c3-9e01-33e4a0d1479d
will derive the Collection ID: 1f8e08a2-eeb6-40c3-9e01-33e4a0d1479d
Figure 2: Relationship between a DID and Resource Collection
A Collection is created using a createResource transaction, and specifying the Collection ID as the same identifier as that of the parent DID.
Note that the Collection ID may take the syntactical form of a 'Hyperledger Indy' DID identifier or may be a Universally Unique Identifier (UUID). This is described in the cheqd DID method.
To create a "DID-Linked Resource", you must already have created a 'parent' DID, from which the Collection ID can be derived. When you carry out the createResource transaction, you must:
Generate a new, unique UUID for the Resources
Specify the same Collection ID as the unique identifier of the parent DID
Sign the createResource transaction with the Verification Method keys of the parent DID.
This is shown in the diagram below:
Figure 3: Relationship between a DID and DID-linked Resource
Example of createResource transaction using Veramo SDK:
Multiple, DID-Linked Resources can be stored in a Collection, for example, this could be different versions of the same Resource over a period of time or semantically-linked resources. This enables unique resources to be stored directly on-ledger and be retrievable through DID resolution and dereferencing.
Once you have created a resource, the DID Document will automatically reference the resource and the collection within the didDocumentMetadata in a newly defined section called linkedResourceMetadata.
This relationship is shown in the diagram below:
Figure 4: DID Document metadata with DID-linked Resource metadata
For simplicity, we will focus on the use case where a Resource is a schema. The same logic used in fetching schemas from the ledger can be applied to any of the aforementioned types of Resources.
The syntax of a Resource metadata for a single schema is as follows:
Any valid IANA Media Type (colloquially known as "file type") is allowed as an on-ledger Resource. The only restriction is that the Resource should fit within a block, which de-facto restricts it to ~190KB to fit within the ~200KB block limit. Any files larger than this are recommended to be stored and linked via long-term immutable file discovery mechanisms such as IPFS.
A Golang library is used to derive and set media type based on the file extension of provided resource file. This makes it much simpler to maintain, since there is no list of file types that the cheqd ledger needs to gatekeep.
The following list defines which specific parameters a resource request format may contain:
| Parameter | Description |
|---|---|
| A string or a map that conforms to the rules of RFC3986 URIs which SHOULD directly lead to a location where the resource can be accessed from. For example: |
| A string that conforms to a cheqd-supported unique identifier format. For example a UUID: |
| A string that uniquely identifies the resource, cheqd uses UUIDs. For example a UUID: |
| A string that uniquelt names and identifies a resource. This property, along with the resourceType below, can be used to track version changes within a resource. |
| A string that identifies the type of resource. This property, along with the resourceName above, can be used to track version changes within a resource. Not to be confused with media type. |
| (Optional) A string that identifies the version of resource. This property is provided by the client and can be any value |
| (Optional) An array that describes alternative URIs for the resource. |
The following list defines which specific parameters a resource response format may contain:
| Parameter | Description |
|---|---|
| A string or a map that conforms to the rules of RFC3986 URIs which SHOULD directly lead to a location where the resource can be accessed from. For example: |
| A string that conforms to a cheqd-supported unique identifier format. For example a UUID: |
| A string that uniquely identifies the resource, cheqd uses UUIDs. For example a UUID: |
| A string that uniquelt names and identifies a resource. This property, along with the resourceType below, can be used to track version changes within a resource. |
| A string that identifies the type of resource. This property, along with the resourceName above, can be used to track version changes within a resource. Not to be confused with media type. |
| (Optional) A string that identifies the version of resource. This property is provided by the client and can be any value |
| (Optional) An array that describes alternative URIs for the resource. |
| A string that identifies the IANA-media type of the resource. |
| A string that identifies the time the resource was created in XML date-time. |
| (Optional) A string that identifies the time the resource was updated in XML date-time. |
| A string that may be used to prove that the resource has not been tampered. |
| (Optional) A string that identifies the previous version of the resource. |
| (Optional) A string that identifies the next version of the resource. |
Let’s take a look at a fully resolved output response for a DID with a Collection and single associated Resource:
Let’s take a look at a fully resolved output response for a DID with a Collection and multiple associated Resources:
Collections are identified by a Collection ID which is a unique identifier of the linked, parent DID. Within the DID Document Metadata of the Collection DIDDoc, the Linked Resource metadata describes Resources within this Collection:
Note that the Linked Resource output above does not show the actual data / schema attributes when displaying all Resources in this Collection. It only shows Resource metadata.
This logic prevents GetResourceCollection requests returning large quantities of data, which may be stored across multiple Resources within a Collection.
In order to fetch the actual data, it is necessary to query the specific Resource, rather than the entire Collection.
For more information about the particulars of requests and responses, please refer to our ADR on Resources on ledger.
As shown in the examples above, there may be previous and next versions of the Resource ID.
Whenever a Resource is updated, a new UUID must be generated. The new Resource references the older version, so the UUID is effectively a version number.
Importantly, the collectionId, resourceName and the resourceType of the Resource must remain the same.
For example, a Resource with the name PassportSchema must always have the same name and resource type to be considered for previous/next version linking.
This could be used, for example, to find the version active at a particular point in time:
Fetching resources using DID resolvers and DID URLs is hugely desirable. Up until this point, we have shown resources identified using path-based syntax.
However, query-based syntax should also be enabled to allow more granular and specific searches within a particular Collection.
To enable combined resolution/dereferencing behavior, cheqd are defining multiple query-based DID URL parameters to fetch resource or associated metadata. 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.
IMPORTANT: DID URL queries should be fully qualified so that they uniquely identify a single resource, or single resource version unless expressly specified.
