Our Approach to DID-Linked Resources
Using the capabilities of the DID Core specification for standards-compliant resource lookup
This blog post has been co-written by Alex Tweeddale, Ankur Banerjee and Ross Power. This blog post was since edited on 07/12/2022 to update the approach to the current resource implementation
Introduction
Since the beginning of Q2 2022, cheqd has been assembling the building blocks for anchoring “resources” to the cheqd network.
The concept of resources in self-sovereign identity (SSI) ecosystems is not new, however, as we will discuss throughout this blog post, existing approaches to resources in SSI oblige adopters to make compromises between security, availability and interoperability. We first noticed this when we were looking at how we could securely reference credential schemas, something we will expand on throughout this post.
Our objective in building resources on cheqd is to improve the way resources are stored, referenced and retrieved for our partners and the broader SSI community, in line with the existing W3C DID Core standard.
Within this blog, we will answer three simple questions:
- What are resources?
- What are the problems with the way resources are stored?
- How have we implemented resources on cheqd?
By answering these questions, we aim to provide a conceptual understanding of why we have chosen this approach, how it improves on existing approaches, and the timelines for this being implemented on cheqd in practice.
In self-sovereign identity (SSI) ecosystems, “resources” are often required in tandem with W3C Verifiable Credentials, to provide supporting information or additional context to verifiers receiving Verifiable Presentations.
For example, common types of resources that might be required to issue and validate Verifiable Credentials are:
Schemas
Describe the fields and content types in a credential in a machine-readable format. Prominent examples of this include schema.org, Hyperledger Indy schema objects, etc. You can think of them as a template for what is included in a Verifiable Credential.
Below is an example of a schema.org residential 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"
}
}This might also take the form of evidence schemes, which describe additional information about the processes used to validate the information presented in a Verifiable Credential in common, machine-readable format.
Revocation status lists
Allow recipients of a Verifiable Credential exchange to check the revocation status of a credential for validity. Prominent examples of this include the W3C Status List 2021 specification and Hyperledger Indy revocation registries, etc.
Visual representations for Verifiable Credentials
Although Verifiable Credentials can be exchanged digitally, in practice most identity wallets want to present “human-friendly” representations. A resource, using something like Overlay Capture Architecture (OCA) may enable a credential representation to be shown according to the brand guidelines of the issuer, internationalisation (“i18n”) translations, etc. Such visual representations can also be used to quickly communicate information visually during identity exchanges, such as airline mobile boarding passes.
In the example above from British Airways, the pass at the front is for a “Gold” loyalty status member, whereas the pass at the back is for a “standard” loyalty status member. This information can be represented in a Verifiable Credential, of course, but the example here uses the Apple Wallet / Google Wallet formats to overlay a richer display.
While it’s useful to have digital credentials that can be verified cryptographically, the reality is that there are often occasions when a quick “visual check” is done instead. For example, when at an airport, an airline staff member might visually check a mobile boarding pass to direct people to the correct queue they need to join. The mobile boarding pass does get scanned at points like check-in, security, boarding etc., to digitally read the information, other scenarios where this is not done are equally valid. However, most Verifiable Credential formats do not explicitly provide such “human-friendly” forms of showing the data held in a credential.
Documents
More broadly, there are other types of resources that might be relevant for companies beyond SSI vendors, that want a way to represent information about themselves in an immutable and trustworthy way.
Many companies require documentation such as Privacy Policies, Data Protection Policies or Terms of Use to be made publicly available. Moreover, Trust over IP (ToIP) recommends making Governance Frameworks available through DID URLs, which would typically be a text file, a Markdown file, PDF etc.
Logos
Companies may want to provide authorised image logos to display across different websites, exchanges or block explorers. Examples of this include key-publishing sites like Keybase.io (which is used by Cosmos SDK block explorers such as our own to show logos for validators) and “favicons” (commonly used to set the logo for websites in browser tabs).
The current uses for resources are therefore very broad across the SSI ecosystem, and in addition, for other companies that may want to use DIDs to reference relevant information on ledger. For this reason, it is essential that the SSI community strengthens the way that resources are stored, referenced and retrieved in SSI ecosystems.
What are the problems with the way resources are stored?
There are multiple approaches to decentralised identity which rely on centralised infrastructure across different technical layers. Decentralised Identifiers (DIDs): are often stored on ledgers (e.g., cheqd, Hyperledger Indy, distributed storage (e.g., IPFS in Sidetree), or non-ledger distributed systems (e.g., KERI). Yet, DIDs can be stored on traditional centralised-storage endpoints (e.g., did:web, did:git).
Predominantly, however, the issue of centralisation affects resources providing extra context and information to support Verifiable Credentials. These resources, such as schemas and revocation lists, are often stored and referenced using centralised hosting providers.
Using centralised hosting providers to store resources may have a significant difference in the longevity and authenticity of Verifiable Credentials. For example, a passport (which typically has a 5–10 year validity) issued as a Verifiable Credential anchored to a DID (regardless of whether the DID was on-ledger or not) might stop working if the credential schema, visual presentation format, or other necessary resources were stored off-ledger on traditional centralised storage.
This section will therefore explain the pain points that should be addressed to improve the way resources are stored, managed and retrieved in SSI ecosystems.
Single points of failure
Even for 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.
The high centralisation of cloud providers and history of noteworthy outages clearly demonstrates why we should not host resources on centralised cloud storage in production environments. In Q1 of 2022, the three largest players in the cloud (AWS, Google Cloud, Microsoft Azure) dominated with 65 per cent in nearly all regions (outside of China).
Furthermore, beyond cloud providers, there are other events that exemplify the issuers relying on larger players. The Facebook outage of 2021 (shown in the graph below) took down apps that used “Login with Facebook” functionality. This highlights the risks of “contagion impact” (e.g., a different Facebook outage took down Spotify, TikTok, Pinterest) of centralised digital systems — even ones run by extremely-capable tech providers.
Ed Skoudis, president of the SANS Technology Institute amusingly commented on this issue:
“In the IT field, we sometimes joke about how we spend 15 years centralizing computing, followed by 15 years decentralizing, followed by another 15 years centralizing again,” he said. “Well, we have spent the past 10 years centralizing again, this time on [the] cloud.”
Likewise, with decentralised identity, there has been excellent work to decentralise, with standards that remove the need for centralised intermediaries — notably around Verifiable Credentials and the decentralised trust provided by DID Authentication. Yet, all of this excellent work may be eroded in practice, unless every component of an SSI ecosystem is able to maintain an equivalent level of decentralised trust. Resources are currently an area that has been centralised for the sake of convenience.
Link Rot
“Link rot” happens when URLs become inaccessible over time, either because the endpoint where the content was stored is no longer active, or the URL format itself changes. The graph below from an analysis by The New York Times shows the degradation over time of URLs.
For this reason, keeping an up-to-date version of the links themselves is crucial. Furthermore, a study of link rot found at least 66.5% of links to sites in the last 9 years are dead. This can have an adverse impact on the digital longevity of Verifiable Credentials if there’s “link rot” in the resources necessary to process the credential. For this reason, projects such as The Internet Archive’s Wayback Machine exist to snapshot digital ephemera before they are lost forever.
This illustrates that link rot can affect a significant proportion of links in a relatively small amount of time, and once again, looking at how resources are currently stored in SSI ecosystems, if the resource locations are moved and the links are broken, the Verifiable Credentials relying on these resources become unusable. Therefore, resources, once defined, should be architected to be used and referenced indefinitely, without being changed.
Tamper-evident changes and censorship resistance
Finally, the centralised way that resources are currently stored and managed is not immutable, and as a result, it is liable to tampering. For example, if a hosting provider is compromised, or if malicious actors are working for the company, resources may be changed and previous resource versions may be purged from the central database.
As we move towards a new web infrastructure with Web 3 (and beyond…), and as more projects leverage blockchain and distributed ledgers, it’s important not to port the previous issues of the web, and instead find novel ways to better manage information, with longevity in mind. This is why at cheqd, we have decided to redesign the way resources are captured on the ledger.
Requirements for DID-Linked Resources on cheqd
cheqd’s DID-Linked Resources can be defined as data files, stored in an organised collection and common format on a distributed ledger. As such, these resources will be highly available, resilient to attack and with immutable archives showing expired, revoked or deprecated resources.
Resources, using the same method of referencing may also be stored off-ledger.
When working towards this objective, we laid out a set of requirements we benchmarked our implementation against:
- Resources must be referenceable via immutable and uniquely identifiable using Decentralised Identifiers (DIDs).
- Resources can be stored on-ledger if they are sufficiently small enough. (If a resource is too large to be stored on-ledger, e.g., an image or video file, they should still be referenceable via their DIDs.)
- Resources must be versioned, with each version easily accessible in the future.
- Resources can be indexed, to promote reuse of resources.
- Existing DID resolvers should be able to either resolve resource URLs or get references to them without significant modification to how they currently function and behave.
- There should be an ability to mark resources as deprecated or superseded by new versions.;
- DID-Linked resources must fit within the existing W3C standards for decentralised identity;
- Resources should be assigned a media type, to allow client applications to apply logic to what resources they expect and want to consume.
Is this similar to Hyperledger Indy’s approach to Schemas and CredDefs on-ledger?
We heavily considered the schema implementation used by AnonCreds on Hyperledger Indy in our design phase, since it tackles many of the problems highlighted above. However, the issue we have with schemas and Credential Definitions for AnonCreds is that they are very tightly coupled with Indy-based ledgers. Both schemas and Credential Definitions, require Indy-specific transactions, limiting the interoperability of these Credentials outside of Indy ecosystems.
Our implementation will enable resources on the ledger to be far more interoperable, beyond cheqd, since the architecture does not tie resources to a specific ledger, and builds within the parameters of the W3C DID Core Spec. This means that partners using AnonCreds and proponents of JSON or JSON-LD Verifiable Credentials can benefit from this approach. We have tried to design our architecture as flexible as possible to allow new resource types to be created, without any vendor lock-in.
We will be writing a specific blog post on how cheqd supports AnonCreds and Credential Definitions using its resource architecture.
Understanding the architecture of DID-Linked resources on cheqd
Formatting a Resource
“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 identifiabilty of each individual resource.
This will be explained further in the section on DID URL dereferencing to fetch a resource.
Understanding the DID and Collection relationship
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 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
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.
Creating a Resource inside a Collection, associated with a DID
To create a “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
createResourcetransaction with the Verification Method keys of the parent DID
This is show in the diagram below:
Example of createResource transaction using Veramo SDK:
{
"kms": "local",
"payload": {
"collectionId": "1f8e08a2-eeb6-40c3-9e01-33e4a0d1479d",
"id": "f3d39687-69f5-4046-a960-3aae86a0d3ca",
"name": "PassportSchema",
"resourceType": "CL-Schema",
"data": "SGVsbG8sIHdvcmxk" // base 64 encoded file
},
"signInputs": [{
"verificationMethodId": "did:cheqd:testnet:z4ZUuPbs1xyK7y8d#key-1",
"keyType": "Ed25519",
"privateKeyHex": "0f5c124886178037952e87e0cdc55d185732577fca19ae877e64ac9ab24a0cc534e5326e70f1a42d785d93048aee806c359ec75a7b06f39253befd1746708438"
}]
}Linking DIDs to Resources and Collections
Multiple, 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:
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:
"linkedResourceMetadata": [
{
"resourceURI": "did:cheqd:mainnet:1f8e08a2-eeb6-40c3-9e01-33e4a0d1479d/resources/f3d39687-69f5-4046-a960-3aae86a0d3ca",
"resourceCollectionId": "1f8e08a2-eeb6-40c3-9e01-33e4a0d1479d",
"resourceId": "f3d39687-69f5-4046-a960-3aae86a0d3ca",
"resourceName": "PassportSchema", // First version of a Resource called PassportSchema
"resourceType": "CL-Schema",
"mediaType": "application/json",
"created": "2022-07-19T08:40:00Z",
"checksum": "7b2022636f6e74656e74223a202274657374206461746122207d0ae3b0c44298",
"previousVersionId": null, // null if no previous version, otherwise, resourceId of previous version
"nextVersionId": null, // null if no new version, otherwise, resourceId of new version
}
]Media Types allowed in Resources
Any valid IANA Media Type (colloquially known as “file type”) is allowed as a DID-Linked 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.
Example of a resolved DID with an associated Resource
Let’s take a look at a fully resolved output response for a DID with a Collection and single associated Resource:
{
"@context": "https://w3id.org/did-resolution/v1",
"didResolutionMetadata": {
"contentType": "application/did+ld+json",
"retrieved": "2022-11-28T05:01:50Z",
"did": {
"didString": "did:cheqd:mainnet:1f8e08a2-eeb6-40c3-9e01-33e4a0d1479d",
"methodSpecificId": "1f8e08a2-eeb6-40c3-9e01-33e4a0d1479d",
"method": "cheqd"
}
},
"didDocument": {
"@context": [
"https://www.w3.org/ns/did/v1"
],
"id": "did:cheqd:mainnet:1f8e08a2-eeb6-40c3-9e01-33e4a0d1479d",
"controller": [
"did:cheqd:mainnet:1f8e08a2-eeb6-40c3-9e01-33e4a0d1479d"
],
"verificationMethod": [
{
"id": "did:cheqd:mainnet:1f8e08a2-eeb6-40c3-9e01-33e4a0d1479d#verKey1",
"type": "Ed25519VerificationKey2020",
"controller": "did:cheqd:mainnet:1f8e08a2-eeb6-40c3-9e01-33e4a0d1479d",
"publicKeyMultibase": "zB5wPyMGYL4LbT424Z7yXHm6nZrrLqZZg9eWtVmedodys"
},
],
"authentication": [
"did:cheqd:mainnet:1f8e08a2-eeb6-40c3-9e01-33e4a0d1479d#verKey1"
]
},
"didDocumentMetadata": {
"created": "2015-04-10T11:51:40Z",
"versionId": "9D760202FF2BD4A12344283627FF251BE6C48812C7626C3564C1C2843CAB9085",
"linkedResourceMetadata": [
{ // First version of a Resource called PassportSchema
"resourceURI": "did:cheqd:mainnet:1f8e08a2-eeb6-40c3-9e01-33e4a0d1479d/resources/f3d39687-69f5-4046-a960-3aae86a0d3ca",
"resourceCollectionId": "1f8e08a2-eeb6-40c3-9e01-33e4a0d1479d", // Derived Collection ID
"resourceId": "f3d39687-69f5-4046-a960-3aae86a0d3ca",
"resourceName": "PassportSchema",
"resourceType": "CL-Schema",
"mediaType": "application/json",
"created": "2015-04-16T14:01:42Z",
"checksum": "72f9d4f96c6f4fedcfd5d1691b10d60d14a008cace269ddb35342aa8d43a30fc",
"previousVersionId": null, // No previous or next versions
"nextVersionId": null // No previous or next versions
}
]
}
}Example of DID Document with multiple versions of the same resource
Let’s take a look at a fully resolved output response for a DID with a Collection and multiple associated Resources:
{
"@context": "https://w3id.org/did-resolution/v1",
"didResolutionMetadata": {
"contentType": "application/did+ld+json",
"retrieved": "2022-11-28T05:01:50Z",
"did": {
"didString": "did:cheqd:mainnet:1f8e08a2-eeb6-40c3-9e01-33e4a0d1479d",
"methodSpecificId": "1f8e08a2-eeb6-40c3-9e01-33e4a0d1479d",
"method": "cheqd"
}
},
"didDocument": {
"@context": [
"https://www.w3.org/ns/did/v1"
],
"id": "did:cheqd:mainnet:1f8e08a2-eeb6-40c3-9e01-33e4a0d1479d",
"controller": [
"did:cheqd:mainnet:1f8e08a2-eeb6-40c3-9e01-33e4a0d1479d"
],
"verificationMethod": [
{
"id": "did:cheqd:mainnet:1f8e08a2-eeb6-40c3-9e01-33e4a0d1479d#verKey1",
"type": "Ed25519VerificationKey2020",
"controller": "did:cheqd:mainnet:1f8e08a2-eeb6-40c3-9e01-33e4a0d1479d",
"publicKeyMultibase": "zB5wPyMGYL4LbT424Z7yXHm6nZrrLqZZg9eWtVmedodys"
},
],
"authentication": [
"did:cheqd:mainnet:1f8e08a2-eeb6-40c3-9e01-33e4a0d1479d#verKey1"
]
},
"didDocumentMetadata": {
"created": "2015-04-10T11:51:40Z",
"versionId": "9D760202FF2BD4A12344283627FF251BE6C48812C7626C3564C1C2843CAB9085",
"linkedResourceMetadata": [
{ // First version of a Resource called PassportSchema
"resourceURI": "did:cheqd:mainnet:1f8e08a2-eeb6-40c3-9e01-33e4a0d1479d/resources/f3d39687-69f5-4046-a960-3aae86a0d3ca",
"resourceCollectionId": "1f8e08a2-eeb6-40c3-9e01-33e4a0d1479d", // Derived Collection ID
"resourceId": "f3d39687-69f5-4046-a960-3aae86a0d3ca",
"resourceName": "PassportSchema", // Resource name remains the same
"resourceType": "CL-Schema", // Resource type remains the same
"mediaType": "application/json",
"created": "2015-04-16T14:01:42Z",
"checksum": "72f9d4f96c6f4fedcfd5d1691b10d60d14a008cace269ddb35342aa8d43a30fc",
"previousVersionId": null,
"nextVersionId": "8f86d7aa-dc6a-4cee-ac37-97956542d587"
},
{ // Second version of a Resource called PassportSchema
"resourceURI": "did:cheqd:mainnet:1f8e08a2-eeb6-40c3-9e01-33e4a0d1479d/resources/8f86d7aa-dc6a-4cee-ac37-97956542d587",
"resourceCollectionId": "1f8e08a2-eeb6-40c3-9e01-33e4a0d1479d", // Derived Collection ID
"resourceId": "8f86d7aa-dc6a-4cee-ac37-97956542d587",
"resourceName": "PassportSchema", // Resource name remains the same
"resourceType": "CL-Schema", // Resource type remains the same
"mediaType": "application/json",
"created": "2020-06-16T14:02:39Z",
"checksum": "ec54f8019b869d5511b42678ea859b9dc185f487bf1776cb079fda0930331689",
"previousVersionId": "f3d39687-69f5-4046-a960-3aae86a0d3ca",
"nextVersionId": "bd128013-636d-4240-b48b-fc88bf9ee8de"
},
{ // Third version of a Resource called PassportSchema
"resourceURI": "did:cheqd:mainnet:1f8e08a2-eeb6-40c3-9e01-33e4a0d1479d/resources/bd128013-636d-4240-b48b-fc88bf9ee8de",
"resourceCollectionId": "1f8e08a2-eeb6-40c3-9e01-33e4a0d1479d", // Derived Collection ID
"resourceId": "bd128013-636d-4240-b48b-fc88bf9ee8de",
"resourceName": "PassportSchema", // Resource name remains the same
"resourceType": "CL-Schema", // Resource type remains the same
"mediaType": "application/json",
"created": "2022-09-16T14:10:46Z",
"checksum": "cc187364f3bf071e5411cb6074d9c44a1b416a32b8eea581d113e486d1d586cf",
"previousVersionId": "8f86d7aa-dc6a-4cee-ac37-97956542d587",
"nextVersionId": null
}
]
}
}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.
Versioning and Archiving Resources
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.
Query based dereferencing
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.
This will be extended on in a W3C Specification, following this New Work Item request.
IMPORTANT: DID URL queries should be fully qualified so that they uniquely identify a single resource, or single resource version unless expressly specified.
How this improves the way resources are stored and retrieved
Through referencing resources with resolvable DID URLs, and authenticating them using DID Documents, the DID-Linked Resourceswill be:
Highly available and easily retrievable
Resources are identified by a DID URL which allows them to be retrieved easily from a distributed ledger using existing DID Resolvers.
Using a distributed ledger like cheqd to store and index resources removes the problem identified by centralised systems creating single points of failure, such as schema.org.
Schemas, for example, would therefore become on-ledger resources. Click the link below to resolve a DID URL to fetch an on-ledger schema!
and see the associated linkedResourceMetadata in the fully resolved DID Document:
https://resolver.cheqd.net/1.0/identifiers/did:cheqd:testnet:z6jKUJA5YcZsNxZgsrQPKPipL2FRTf4s
You can dive into further detail on the syntax of resources and how they can be retrieved within the Resources section of our Identity Documentation.
Controllable and self-attestable
Resources can be tied to DID Documents and control over resources can be exerted via the same verification method keys as those written into an associated DID Document.
This allows persons to authenticate with a DID Document to update or prove control of a Resource, which addresses the problem of tamper-proofing identified around centralised cloud providers.
Built to be consumed by client applications
Resources must specify a name, and resource type and compile into a media type, which provides specific information to any client application about what data format and syntax the data are expected to be retrieved in.
This allows client applications to apply business rules to what types of resources are expected, and which should be accepted, making resources far easier to be consumed by third-party software. This differs from existing Hyperledger Indy resources, which require the client applications to be familiar with Indy in order to process and consume Indy resources.
Conversely, our method gracefully allows “dumb” applications, that do not understand specific DID protocols, to still fetch and access a resource over HTTP/REST APIs. In addition, “smart” applications, that do understand these protocols, can process, query, and get their own resources from DID resolution and dereferencing.
Indexable
Resources are versioned with unique identifiers (UUIDs), allowing previous versions to be archived within a collection, and retrieved through querying a unique ID or a version time.
This mitigates the problem identified of link rot when using centralised storage systems since each version is archived immutably.
Conclusion
In building DID-Linked resources, we want to avoid the risks associated with relying on centralised infrastructure for storing resources, while importantly, remaining conformant with W3C standards and avoiding ledger lock-in.
We believe that we have achieved this compromise by enabling the management of resources through the use of DID Documents, identifying resources using DID URLs and retrieving resources using existing DID Resolvers.
Not only does this work solve existing problems, but it opens the door for far more innovation using DIDs, including:
- Fully identifiable and resolvable governance documentation and schemes on ledger, tied to DIDs and DID Documents
- Full AnonCreds support on non-Indy ledgers (explained further in this blog)
- Trust registries, governance files and trust establishment files.
- On-ledger revocation lists, where each revocation entry can be uniquely versioned and retrieved efficiently (this is our next priority roadmap item)
- Logos and company information easily accessible on-ledger, referenced within that company’s DID
We look forward to working with our partners and the broader SSI community to see how we can innovate together using this new functionality, and properly securing SSI architecture in a decentralised end-to-end flow.
As always, we’d love to hear your thoughts on our writing and how DID-Linked Resources could improve your product offering. Feel free to contact the product team directly — product@cheqd.io, or alternatively start a thread in either our Slack channel or Discord.
