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.
Last updated
Was this helpful?
Architecture Decision Record (ADR) describing how DID resolvers handle DID URL queries, paths and fragments for DIDs and DID-Linked Resources.
Last updated
Was this helpful?
Authors
Alex Tweeddale, Abdulla Ashurov, Andrew Nikitin
ADR Stage
ACCEPTED
Implementation Status
Implemented
Start Date
2023-06-05
Last Updated
2023-06-06
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.
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.
Normal dereferencing can be conceived in two steps:
Endpoint: /1.0/identifiers/<did>
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:
Here, to dereference to this verificationMethod, we need to pass key-1
as a fragment parameter:
Example:
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 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")
Here we have an ability to specify different parameters to filter to particular parts of a DIDDoc.
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.
VersionId
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
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
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:
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.
The diagram below shows how a DID-Linked Resource sits beneath a DID and can be fetched using a DID URL.
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.
Endpoint: /1.0/identifiers/<did>/resources/<resource_id>
Request HTTP headers
Accept
should allow */*
or match the mediaType
of the Resource
Response HTTP headers
Status code 200 OK
Content-Type
should be set to mediaType>
of the Resource
Content-Encoding
should be set to a valid content compression method in Accept-Encoding
and response compressed accordingly
Response HTTP body
Resource, encoded correctly according to the mediaType
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
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
Here we have an ability to specify different parameters to filter to particular DID-Linked Resources.
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.
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
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
resourceMetadata=true
resourceMetadata=false
Unused
Example:
If the output of the DID URL dereferencing function contains the
didDocumentStream
:
If the value of the
Accept
HTTP 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-Type
header. 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 theAccept
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 */*
Response HTTP headers
Status code 200 OK
Content-Type: application/did+ld+json
Response HTTP body
didDocument
/ contentStream
contains @context
section;
didResolutionMetadata
/ dereferencingMetadata
contentType
field is application/did+ld+json
Accept
request HTTP header contains application/ld+json;profile="https://w3id.org/did-resolution"
Response HTTP headers
Status code 200 OK
Content-Type: application/ld+json;profile="https://w3id.org/did-resolution
Response HTTP body
didDocument
/ contentStream
contains @context
section;
didResolutionMetadata
/ dereferencingMetadata
contentType
field is application/ld+json;profile="https://w3id.org/did-resolution
Accept
request HTTP header contains application/did+json
Response HTTP headers
Status code 200 OK
Content-Type: application/did+json
Response HTTP body
didDocument
/ contentStream
DOES NOT contain @context
section;
didResolutionMetadata
/ dereferencingMetadata
ContentType
field is application/did+json
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:
didResolutionMetadata
contains "error" : "<Error message>"
didDocument
: null
didDocumentMetadata
: []
The DID dereferencing output should always conform to the following format: ( dereferencingMetadata, contentStream, contentMetadata )
dereferencingMetadata
contains "error" : "<Error message>"
contentStream
: null
contentMetadata
: []
A is resolved to a ;
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.