🟣ADR 005: DID Resolution & DID URL Dereferencing
Architecture Decision Record (ADR) describing how DID resolvers handle DID URL queries, paths and fragments for DIDs and DID-Linked Resources.
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 did:cheqd method ADR defines how DIDs are created and read from ledger. According to the W3C DID Core specification, DID methods are expected to provide standards-compliant methods of DID and DID Document ("DIDDoc") production.
The cheqd DID Resolver is designed to implement the W3C DID Resolution specification for did:cheqd method.
Part of the W3C DID Resolution specification 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:
A DID is resolved to a DID Document;
A resource within / associated with 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.).
DID Document Dereferencing Operations
Simple DID Resolution
Endpoint: /1.0/identifiers/<did>
Current implementation returns here the full DIDDoc as in example. By default, in didDocumentMetadata section will be the metadata for the latest version of DIDDoc and the list of all resources.
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.
Take the example excerpt from a DIDDoc below:
"verificationMethod": [
{
"id": "did:cheqd:testnet:97e351e6-2d9d-4314-82ec-e0d12bc5de43#key-1",
"type": "JsonWebKey2020",
"controller": "did:cheqd:testnet:97e351e6-2d9d-4314-82ec-e0d12bc5de43",
"publicKeyJwk": {
"crv": "Ed25519",
"kty": "OKP",
"x": "q8-CHj4_nIYo8tK5RdjYbXlsTUnwW_i4gIEclps2i2o"
}
}
],Here, to dereference to this verificationMethod, we need to pass key-1 as a fragment parameter:
Example:
DID URL with query
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.
Common parameter validation
parameters
metadataandresourceMetadataare designed to be a bool variables, liketrueorfalse.parameters
versionTimeandresourceVersionTimeare 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.
versionId
A string that conforms to a method specific unique identifier format.
Used to filter to a specific version id of the DIDDoc
versionTime
A JSON String serialized as an XML Datetime normalized to UTC 00:00:00 and without sub-second decimal precision.
Used to filter to a specific version of the DIDDoc at a point in time
service
Using a string from the serviceid property within the DID document, this will dereference to the associated serviceEndpoint
Used to navigate to a serviceEndpoint of a DIDDoc, using the serviceId as a query parameter
transformKeys
A string that identifies the intended key type
Used to transform the verificationMethod key material into a different key type, based on the same cryptographic curve
relativeRef
A string that identifies a particular "secondary" resource appended to the serviceEndpoint
Used to fetch a specific part of a serviceEndpoint, such as a particular heading on a website
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.
1.0/identifiers/did:cheqd:testnet:b5d70adf-31ca-4662-aa10-d3a54cd8f06c?resourceId=e577237b-b887-43e8-9540-9097bb00efbb&service=fooVersionId
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.
Example:
VersionTime
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 resourceVersionTime parameter and combine the query with versionTime.
Example:
TransformKeys
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:
Ed25519VerificationKey2020
Ed25519VerificationKey2018
JsonWebKey2020
Example:
Service
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.
Example:
RelativeRef
relativeRef is an additional part for serviceEndpoint and can be used only with service parameter. It combines serviceEndpoint URL with relativeRef value and does the redirect to the URL.
Example:
Metadata
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.
Example:
Errors
NotFoundErrorraises if there is now resource/metadata with requested set of parameters or the result is ambiguousRepresentationNotSupportedraises if there are:unsupported query parameters
value for parameters are empty
unsupported
transformKeysvaluemetadataorresourceMetadataparameter has value not onlytrueorfalserelativeRefparameter is used withoutserviceone. They must be used only together
InvalidDidUrlraises if there are:versionIdorresourceIdare not valid UUID stringsversionTimeorresourceVersionTimeare not in RFC3339 or RFC3339Nano formats.resourceVersionTimeis used without any other resource parameters.
Dereferencing to a DID-Linked Resource
cheqd's ADR: 002 DID-Linked Resources 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.
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
Requests to fetch on-ledger cheqd Resources are considered as a DID URL Dereferencing scenario it uses DID URL paths to lead to a Resource object, rather than a DIDDoc.
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.
Get a specific Resource
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 HTTP content negotiation phase by client applications. In this case, only the HTTP Response headers are returned without the body.
Endpoint: /1.0/identifiers/<did>/resources/<resource_id>
Request HTTP headers
Acceptshould allow*/*or match themediaTypeof the ResourceAccept-Encodingmay be allowed compression methods (e.g.,gzip,compress, etc.)
Response HTTP headers
Status code
200 OKContent-Typeshould be set tomediaType>of the ResourceContent-Encodingshould be set to a valid content compression method inAccept-Encodingand response compressed accordinglyContent-Lengthshould be set to the Resource size, in decimal bytes
Response HTTP body
Resource, encoded correctly according to the
mediaType
Get metadata for a specific resource
Return metadata for a specified resource. This is effectively a portion of the DIDDoc Metadata block.
Endpoint: /1.0/identifiers/<did>/resources/<resource_id>/metadata
Get metadata for all Resources linked to a DID
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
301Redirect to
/resources/all
/1.0/identifiers/<did>/resourcesThrow an
invalidDidUrlerror
Query parameters
Here we have an ability to specify different parameters to filter to particular DID-Linked Resources.
resourceId
A string that conforms to a method specific unique identifier format.
The unique identifier of a particular DID-Linked Resource
resourceCollectionId
A string that conforms to a method specific unique identifier format.
Can be used to query all resources associated with a DID if combined with resourceMetadata=true
resourceVersionTime
A JSON String serialized as an XML Datetime normalized to UTC 00:00:00 and without sub-second decimal precision.
Used to fetch a version of a resource at a specific point in time
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:
ResourceId
ResourceId parameter can be used for filtering a particular resource version by specifically identifying its unique ID.
Example:
ResourceCollectionId
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.
Example:
ResourceType
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.
Example:
ResourceName
Behavior of this parameter is similar with resourceType one. If there is no ambiguous resource, it will be fetched. Otherwise greater specifity is required.
Example:
ResourceVersion
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.
Example:
ResourceVersionTime
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).
Example:
Checksum
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.
Example:
ResourceMetadata
This parameter a kind of modifier which works in the same manner as metadata 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:
resourceMetadata=trueresourceMetadata=falseUnused
Example:
HTTP headers and associated rules
The cheqd DID Resolver complies with the rules and algorithm defined in Decentralized Identifier Resolution (DID Resolution) v0.3. This section clarifies and expands some descriptions specific to cheqd.
The DID Resolution specification HTTP(S) bindings section states that:
If the output of the DID URL dereferencing function contains the
didDocumentStream:
If the value of the
AcceptHTTP header is absent orapplication/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-Typeheader. The value of this header MUST beapplication/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 theAcceptHTTP 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 */*
Accept header is application/did+ld+json OR blank OR */*Response HTTP headers
Status code
200 OKContent-Type: application/did+ld+json
Response HTTP body
didDocument/contentStreamcontains@contextsection;didResolutionMetadata/dereferencingMetadatacontentTypefield isapplication/did+ld+json
Accept request HTTP header contains application/ld+json;profile="https://w3id.org/did-resolution"
Accept request HTTP header contains application/ld+json;profile="https://w3id.org/did-resolution"Response HTTP headers
Status code
200 OKContent-Type: application/ld+json;profile="https://w3id.org/did-resolution
Response HTTP body
didDocument/contentStreamcontains@contextsection;didResolutionMetadata/dereferencingMetadatacontentTypefield isapplication/ld+json;profile="https://w3id.org/did-resolution
Accept request HTTP header contains application/did+json
Accept request HTTP header contains application/did+jsonResponse HTTP headers
Status code
200 OKContent-Type: application/did+json
Response HTTP body
didDocument/contentStreamDOES NOT contain@contextsection;didResolutionMetadata/dereferencingMetadataContentTypefield isapplication/did+json
Error handling
The DID Resolution specification defines an algorithm for how invalid DID URL Resolution/Dereferencing errors should be handled. The cheqd DID Resolver aims to implement all of these scenarios, with the correct HTTP Response status codes based on the specific error encountered.
DID Resolution errors
The DID resolution output should always conform to the following format: ( didResolutionMetadata, didDocument, didDocumentMetadata )
If the resolution is unsuccessful, the DID resolver should return the following result:
didResolutionMetadatacontains"error" : "<Error message>"didDocument: nulldidDocumentMetadata:[]
DID URL Dereferencing errors
The DID dereferencing output should always conform to the following format: ( dereferencingMetadata, contentStream, contentMetadata )
dereferencingMetadatacontains"error" : "<Error message>"contentStream: nullcontentMetadata:[]
Last updated
Was this helpful?