Rules and architecture of DID resolver to handle DID URL queries, paths and fragments
Last updated
Was this helpful?
Status
Category
Status
Authors
Alex Tweeddale, Abdulla Ashurov, Andrew Nikitin
ADR Stage
ACCEPTED
Implementation Status
Implemented
Start Date
2023-06-05
Last Updated
2023-06-06
Summary
The defines how DIDs are created and read from ledger. According to the , DID methods are expected to provide .
The is designed to implement the for method.
Part of the is the notion of DID URL Dereferencing whereby a DID URL identifies either a primary or secondary resource which is returned directly.
Understanding DID resolution vs DID URL dereferencing
When you resolve a DID you get a DID Document.
When you dereference a DID, you may get the DID Document, a portion of a DID document, or the resource at the end of a service endpoint (if the DID contains a service component).
You can only resolve a DID to return a DID document, and you can only dereference a DID reference to return whatever resource is referenced.
Process for dereferencing a DID URL
Normal dereferencing can be conceived in two steps:
DID Document Dereferencing Operations
Simple DID Resolution
Endpoint: /1.0/identifiers/<did>
DID URL with fragment
Endpoint: /1.0/identifiers/<did>#example
If a DID URL contains a fragment #. the logic is similar to the general web browser logic where # symbols can be used for linking to the particular document section.
For the DIDDoc, you can equate a specific section within a webpage to a specific section inside the DIDDoc, for example verificationMethod. To resolve to a particular section, we need to use a request which specifies the section itself.
All the queries can be divided into 2 main groups:
Queries for fetching a resource referenced within the DIDDoc body.
Queries for fetching an external resource associated with the DIDDoc, referenced within the DIDDoc metadata.
Note: in instances where there is no versionId or versionTime parameters specfied, we have set the default dereferencing rules to fetch the latest version of a resource, if it is uniquely identified by the parameters in the query.
Common parameter validation
parameters metadata and resourceMetadata are designed to be a bool variables, like true or false.
parameters versionTime and resourceVersionTime are designed as string representation of time and can be in 2 formats, RFC3339 and RFC3339Nano. Examples are ("2006-01-02T15:04:05Z07:00" and "2006-01-02T15:04:05.999999999Z07:00")
Query parameters
Here we have an ability to specify different parameters to filter to particular parts of a DIDDoc.
Parameter
Type
Description
versionId
Used to filter to a specific version id of the DIDDoc
versionTime
Used to filter to a specific version of the DIDDoc at a point in time
service
Used to navigate to a serviceEndpoint of a DIDDoc, using the serviceId as a query parameter
transformKeys
Used to transform the verificationMethod key material into a different key type, based on the same cryptographic curve
relativeRef
Used to fetch a specific part of a serviceEndpoint, such as a particular heading on a website
metadata
Used to fetch the metadata associated with a particular DIDDoc
All queries can be chained together to make very specific requests using & within the request format. This makes query parameters particularly powerful because they can be used to fetch specific parts of a DID Document or specific resources associated with a DID Document.
For example, the example below queries a particular service endpoint associated with a particular DIDDoc version.
If the user knows the particular versionId he could ask about it by adding the query versionId=<uuid of DIDDoc version> It can be combined with any other queries for building more complex requests. linkedResourceMetadata will contain only resources which were active for this version. In other words, resource which were created before the next version in terms of timeline.
The transformKeys parameter changes the representation of verificationMethod section in DIDDoc. It allows you to change publicKey representation into the one of next variants. To do so, just pass the parameter transfromKeys with one of the following values:
Service - is a DIDDoc section which includes serviceEndpoint field with URL inside. As a result, pair service=<service-id> will redirect to the serviceEndpoint value.
By default, without metadata=true pair DID-resolver returns only particular DIDDoc. If you want to specifically fetch only the metadata for a DIDDoc, you can pass an additional query. It can be helpful in the instance, for example, where you want to get all the resources which were created for the exact versionId or before versionTime.
NotFoundError raises if there is now resource/metadata with requested set of parameters or the result is ambiguous
RepresentationNotSupported raises if there are:
unsupported query parameters
value for parameters are empty
unsupported transformKeys value
metadata or resourceMetadata parameter has value not only true or false
relativeRef parameter is used without service one. They must be used only together
InvalidDidUrl raises if there are:
versionId or resourceId are not valid UUID strings
versionTime or resourceVersionTime are not in RFC3339 or RFC3339Nano formats.
resourceVersionTime is used without any other resource parameters.
Dereferencing to a DID-Linked Resource
The diagram below shows how a DID-Linked Resource sits beneath a DID and can be fetched using a DID URL.
DID-Linked Resource resolution rules
On the other hand, on-ledger cheqd Resources metadata requests are handled like DID URL Resolution since the result is a subsection of didDocumentMetadata specific to that resource.
API endpoints related to on-ledger cheqd Resources are described below. All of these request types are GET requests, with POST and PUT requests disallowed.
Returns metadata for all Resources directly linked to/controlled by a DID. This is effectively the full linkedResourceMetadata section in DIDDoc Metadata block.
Endpoint: /1.0/identifiers/<did>/resources/all
Alternative endpoints
/1.0/identifiers/<did>/resources/
Status code 301
Redirect to /resources/all
/1.0/identifiers/<did>/resources
Throw an invalidDidUrl error
Query parameters
Here we have an ability to specify different parameters to filter to particular DID-Linked Resources.
Parameter
Type
Description
resourceId
The unique identifier of a particular DID-Linked Resource
resourceCollectionId
Can be used to query all resources associated with a DID if combined with resourceMetadata=true
resourceName
The specific name of a DID-Linked Resource
resourceType
The specific type of a DID-Linked Resource
resourceVersionTime
Used to fetch a version of a resource at a specific point in time
checksum
Used to specify a particular resource checksum to demonstrate it is untampered
resourceMetadata
Used to fetch metadata related to a specific resource or group of resources
Like with DIDDoc query parameters, these can all be chained together to create complex requests for specific DID-Linked Resources at particular points in time or associated with particular DIDDoc versions.
Rules and logic for handling ambiguous queries
It is important to understand how our resolver logically handles more complex dereferencing requests. We have set some baseline defaults and rules to ensure a logical and consistent experience for clients who use our resolver.
Ambiguity generally throws an error
If the request specifies a parameter where there are multiple potential results, such as where the DID has two resources of the same resourceType ('String') but resourceName is not the same, an error will be thrown because there is not enough information to discern which resource is being requested.
Multiple versions of the same resource
If there are multiple resources with the same resourceType and resourceName but with different versionIds, and there is no parameter specified to fetch a particular version, the resolver will fetch the latest resource by default.
This is because the query is not ambiguous in terms of discerning which set of resources to dereference to, but is only ambiguous in terms of which version of that resource to fetch.
Ambiguity + resourceMetadata=true
If there is an ambiguous query, such as where there are two resources with the same name but different types, AND there is a resourceMetadata=true parameter, resource data pertaining to all the resources which could potentially be seen as being ambiguous will be returned.
For example, in the below example, there are multiple resources with the resourceType= string, but with different resourceName parameters:
resourceCollectionId parameter filters all the resource by collectionId field. By default cause we are asking for resources for a particular DID it already includes all the resource with the same collectionId and this parameter can used mostly as sanity check. Without resourceMetadata=true parameter will return the latest created resource if there is only one resource or an unambiguous resource.
This parameter is also just a filter by Type field through resources. But there is a corner case if the user asks about exact resource (exact data). If after applying all the parameters in request several resources are left with the same Name - the latest one will be responded. Otherwise - error NotFoundError will be raised.
This parameter filters by Version field. We introduced it with latest network upgrade and can be optionally set to identify a version of a resource with a particular string.
Important: This parameter must always be accompanied by another resource query qualifier.
The main goal here is to get the nearest resource for resourceVersionTime value. "Nearest" means that if we are asking for time between resource1 and resource2 were created - resource1 will be returned. In case if requested resourceVersionTime is before the first resource created - NotFoundError will be returned. The most useful use-case here is checking that some "Credential" (driver's license) was active at resourceVersionTime (was not revoked from Revocation Registry for example).
It just checks that checksum is the same as resource's metadata and also can used as a sanity check. For example, if the user knows what is exact checksum then it may be checked before actual downloading.
If the output of the DID URL dereferencing function contains the didDocumentStream:
If the value of the Accept HTTP header is absent or application/did+ld+json (or other media type of a conformant representation of a DID document):
The HTTP response status code MUST be 200.
The HTTP response MUST contain a Content-Type header. The value of this header MUST be application/did+ld+json (or other media type of a conformant representation of a DID document).
The HTTP response body MUST contain the didDocumentStream, in the representation corresponding to the Accept HTTP header.
Since the cheqd DID Resolver APIs are REST APIs, the default Content-Type: application/did+ld+json encoding is used if the Accept header is not explicitly set since it matches the Accept: */* header that most client applications send.
Accept header is application/did+ld+json OR blank OR */*
A resource within / associated with the is identified, based on the portion of the that follows the (path, query, fragment as defined by the ABNF in .).
Current implementation returns here the full DIDDoc as in . By default, in didDocumentMetadata section will be the metadata for the latest version of DIDDoc and the list of all resources.
A that conforms to a method specific unique identifier format.
A serialized as an normalized to UTC 00:00:00 and without sub-second decimal precision.
Using a from the serviceid property within the DID document, this will dereference to the associated serviceEndpoint
A that identifies the intended key type
A that identifies a particular "secondary" resource appended to the serviceEndpoint
The user could ask resolver for the nearest DIDDoc which was created/updated before versionTime value. The logic about linkedResourceMetadata is the same. Here, resolver figure out what the versionId is the nearest one for versionTime and shows all the active resources. If you want to file resources also, you can use parameter and combine the query with versionTime.
relativeRef is an additional part for serviceEndpoint and can be used only with parameter. It combines serviceEndpoint URL with relativeRef value and does the redirect to the URL.
cheqd's introduces a new concept to the SSI ecosystem - namely, resources that can be associated with a DID and fetched using existing DID URL dereferencing patterns.
Requests to fetch on-ledger cheqd Resources are considered as a DID URL Dereferencing scenario it uses to lead to a Resource object, rather than a DIDDoc.
Returns the Resource data/payload stored on ledger for specified resource. HEAD request type is also allowed for this endpoint since it can be used for phase by client applications. In this case, only the HTTP Response headers are returned without the body.
may be allowed compression methods (e.g., gzip, compress, etc.)
should be set to the Resource size, in decimal bytes
A that conforms to a method specific unique identifier format.
A that conforms to a method specific unique identifier format.
A
A
A serialized as an normalized to UTC 00:00:00 and without sub-second decimal precision.
A
Behavior of this parameter is similar with one. If there is no ambiguous resource, it will be fetched. Otherwise greater specifity is required.
This parameter a kind of modifier which works in the same manner as but applies to resources. It allows to get only Metadata information about resource(s) without downloading. Also it changes the flow for resourceType and resourceName parameters and general meaning of this parameter - just filter. So, here it allows to create a chain of parameters and apply all of them to the resourceCollection and get only interested resource metadata. Possible variants:
The cheqd DID Resolver complies with the rules and algorithm defined in . This section clarifies and expands some descriptions specific to cheqd.
The section states that:
The DID Resolution specification should be handled. The cheqd DID Resolver aims to implement all of these scenarios, with the encountered.
