ADR 008: cheqd on-ledger resources

Status

Category
Status
Authors
Ankur Banerjee, Alexandr Kolesov, Alex Tweeddale, Renata Toktar
ADR Stage
ACCEPTED
Implementation Status
Implemented
Start Date
2021-09-23
Last Updated
2022-09-06

Summary

This ADR defines how on-ledger resources (e.g., text, JSON, images, etc) can be created and referenced using a persistent and unique did:cheqd DID URL.
Each on-ledger resource will be linked with a DID Document, with create/update operations controlled using the specified verification methods in the associated DID Document.

Context

"Resources" in decentralised identity

Trust over IP Foundation (ToIP) describes how "resources" could be generically defined and accessed using DID URLs. In a self-sovereign identity (SSI) ecosystem, such resources are often required in tandem with W3C Verifiable Credentials, which is a standard way of representing portable digital credentials that represent claims about its subjects and can be verified via digital proofs.
Common types of resources that might be required to issue and validate Verifiable Credentials are:
Mobile boarding passes for Apple Wallet from British Airways
Figure 1: Mobile boarding passes in Apple Wallet showing different visual styles (source: British Airways media centre)
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, "human-friendly" display.
More broadly, there are other resources that might be relevant for issuers and verifiers in a self-sovereign identity exchange:

Rationale for storing resources on-ledger

Decentralized 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).

Drawbacks of hosting resources on traditional web endpoints

DIDs can be stored on traditional centralised-storage endpoints (e.g., did:web, did:git) but this comes with certain drawbacks:
  1. 1.
    DIDs could be tampered by compromising the hosting provider: DIDs and DID Documents ("DIDDocs") stored at a centralised web endpoint can be compromised and replaced by malicious actors.
  2. 2.
    Hosting providers could unilaterally cease to host particular clients: Hosting providers could terminate accounts due to factors such as non-payment of fees, violation of Terms of Service, etc.
  3. 3.
    Single point-of-failure in resiliency: 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 DID anchored on their systems inaccessible.
    Figure 2: Graph showing drop in Facebook traffic from their global service outage in 2021 (source: Kentik)
    1. 1.
      In particular, the 2021 global Facebook outage also 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.
  4. 4.
    Link rot: "Link rot" happens when over time, URLs become inaccessible, 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 of linkrot shows degradation over time of URLs.
Figure 3: Linkrot analysis over 1996-2019 by New York Times (source: Columbia Journalism Review / New York Times)

Risks applicable in the context of Verifiable Credentials

The issues highlighted above a material difference to the longevity of Verifiable Credentials.
For example, a passport (which typically have 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.
Despite these issues, many self-sovereign identity (SSI) implementations - even ones that use ledgers / distributed systems for DIDs - often utilise centralised storage. From the W3C Verifiable Credential Implementation Guide:
Example schema.org 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"
}
}
Using traditional web endpoints to store resources (such as schemas) that are critical for a Verifiable Credential to function undermines the benefits that persistently-accessible Decentralized Identifiers offer.

Design principles

We took the following design principles into consideration, along with an explanation of how we addressed them:
  1. 1.
    Built using existing, familiar DID Core Spec patterns: Wherever possible, our design attempts to utilise existing patterns and behaviours within the W3C DID Core specification (such as the use of DID URLs to identify resources), instead of trying to implement proprietary/custom approaches. We believe that similar designs could be adopted by other DID methods if they choose.
  2. 2.
    Protection against linkrot for long-term retrieval: Any Resource stored on-ledger is replicated across multiple nodes.
    1. 1.
      If any individual node or endpoint is down, lookup requests can be sent to any other node on the network.
    2. 2.
      In a catastrophic scenario where the network itself stops to exist, e.g., companies shutting down, getting acquired etc the on-ledger data can still be restored by digital archivists using ledger snapshots. A practical example of this is how Cosmos Hub makes historical chain archives available which can be restored. While this can be cumbersome, we wanted to design for this as a fail-safe.
  3. 3.
    Extensible by default: Our objective was to build a flexible design pattern that allowed developers to define and extend their their own resource types. Trying to control what kinds of resources could be written to ledger would make the ledger-side logic complex. Instead, we opted for a design where the cheqd ledger acts agnostically to store resources, as long as correctly authorised, as a permanently-accessible endpoint.
  4. 4.
    Design for DID-spec "dumb" as well as DID-spec "smart" client applications: Many approaches in this space assume that client applications must be adept at parsing DIDDocs and resolving complex inter-DIDDoc relationships. We saw describing resources using DIDDocs as metadata about the resource which could be independently-parsed by "smart" client applications; while also providing a fallback approach for "dumb" client applications. We internally considered this as "What if an identity wallet understood how to parse JSON, but didn't understand the DID Core spec?"
  5. 5.
    Version controlled: The ability to evolve a resource over time is critical for identity use cases. As described above, examples of this include when identity document schemas change, logos evolve, etc. Current approaches (such as Hyperledger Indy CredDefs) deal with this by creating entirely new, unlinked resources. We designed to make it easy, using existing DID Core specification techniques, so that client applications could query "What was the version of a resource with this name on this date/time?"
  6. 6.
    Make re-use of resources simple: We liked the concept of Schema.org in the sense that it promotes a common, machine-readable specification. Therefore, our design allows for patterns where the controllers of a DID can reference resources created by other DID owners/controllers, e.g., referencing a pre-existing schema. Taking this line of thought further, it allows for an arbitrary depth of how resources can be nested, as long as they are discoverable/resolvable.
  7. 7.
    Not all types of resources should be stored on a ledger...but can be made discoverable through similar design patterns: Distributed ledgers are great for redundancy, but the cost of this duplication (in terms of storage required by node, block size, transaction finality speeds, etc) can be quite significant. For instance, a distributed ledger is probably not the best storage and retrieval mechanism for a video file (which can run into many GBs/TBs); or even a PDF larger than a few MBs. cheqd network restricts the block size for an individual block to ~200 KB. This can be updated via an on-ledger vote, but the trade-off of asking node operators to provision ever-expanding storage would be not ideal. Our design therefore restricts the file/payload size of on-ledger resources (in our case, ~190 KB - giving enough room for transaction data besides the resource itself), while allowing the same techniques below to be used for describing off-ledger resources. E.g., our first DID on cheqd network references a 7+ MB image accessible via IPFS. We recognise and accept that DID owners/creators may choose to use their own centralised/decentralised storage, and the design patterns described below accommodate that.

Resources on cheqd ledger

Resources on cheqd ledger are collated under Resource Collections, which are defined as a list of resources linked to and controlled using a DID Document ("DIDDoc").
Simplified on-ledger Resource creation flow on cheqd network
Figure 4: Overview of Resource and Resource Collection creation (editable version)
To create a new Resource, a client application first needs to create a DID (or use an existing DID) along with its associated DIDDoc. This resource-linked DID is the lowest, direct level of create/update/deactivate operation control that exists.
Individual Resources are uniquely identified by a common Resource Name and common Resource Type that MUST remain consistent across versions. The specific version number of a Resource is described using the Resource ID, which is a Universally-Unique Identifier (UUID). Since UUIDs can be generated by any compatible software library, client applications are able to define this version number independent of the cheqd ledger. (This same technique and rationale is described in ADR-002: cheqd DID method).
This allows a specific Resource version to be referenced in a Verifiable Credential, as well as allowing client applications to query historical/updated Resource versions along with metadata that describes how the Resource evolved within a Resource Collection.

Discoverability via DIDDoc Metadata

Once a Resource has been created under a Resource Collection, the parent DIDDoc will automatically have an updated didDocumentMetadata section, including linkedResourceMetadata.
The syntax of the linked Resource metadata is as follows:
"didDocumentMetadata": {
"created": "2020-12-20T19:17:47Z",
"updated": "2020-12-20T19:19:47Z",
"deactivated": false,
"versionId": "1B3B00849B4D50E8FCCF50193E35FD6CA5FD4686ED6AD8F847AC8C5E466CFD3E",
"linkedResourceMetadata": [
{ // First version of a Resource called PassportSchema
"resourceURI": "did:cheqd:testnet:DAzMQo4MDMxCjgwM/resources/44547089-170b-4f5a-bcbc-06e46e0089e4",
"resourceCollectionId": "DAzMQo4MDMxCjgwM", // Common collection ID
"resourceId": "44547089-170b-4f5a-bcbc-06e46e0089e4", // Old Resource ID and version number
"resourceName": "PassportSchema", // Resource name must remain the same
"resourceType": "CL-Schema", // Resource type must remain the same
"mediaType": "application/json",
"created": "2022-07-19T08:40:00Z",
"checksum": "7b2022636f6e74656e74223a202274657374206461746122207d0ae3b0c44298", // Old version checksum
"previousVersionId": null, // null, since no previous version
"nextVersionId": "bb2118f3-5e55-4510-b420-33ef9e1726d2", // Points to next version below
},
{ // Second version of a Resource called PassportSchema
"resourceURI": "did:cheqd:testnet:DAzMQo4MDMxCjgwM/resources/bb2118f3-5e55-4510-b420-33ef9e1726d2",
"resourceCollectionId": "DAzMQo4MDMxCjgwM", // Common collection ID
"resourceId": "bb2118f3-5e55-4510-b420-33ef9e1726d2", // New Resource ID and version number
"resourceName": "PassportSchema", // Resource name must remain the same
"resourceType": "CL-Schema", // Resource type must remain the same
"mediaType": "application/json",
"created": "2022-08-07T08:40:00Z",
"checksum": "9123dcbb0b42652b0e105956c68d3ca2ff34584f324fa41a29aedd32b883e131", // New version checksum
"previousVersionId": "44547089-170b-4f5a-bcbc-06e46e0089e4", // Points to previous version above
"nextVersionId": null // null if no new version
}
]
}
Importantly, we decided not to populate the actual resource data into the didDocumentMetadata, but instead, what we refer to as a Resource Preview which contains all the metadata about the associated resources.

Optional Discoverability via DIDDoc Services

Once a Resource has been created under a Resource Collection, the linked DIDDoc can be updated to provide a link to access it in the service section.
The rationale for linking to Resources in this manner, instead of creating a new top-level section, are as follows:
  1. 1.
    Client applications capable of doing DID Resolution may have strong architectural assumptions to only expect the default DID Core specification sections in a response. We considered the possibility that such applications might (incorrectly) reject the entire DIDDoc as malformed, or crash in the process of trying to parse the DIDDoc.
  2. 2.
    On the other hand, the Service section in a DIDDoc is designed to be flexible and extensible by design. New DID Service types can be registered through DID Specification Registries by anyone. We suggest a new service type called LinkedResource should be used to reference any resource on cheqd within the service section. This is conceptually similar to the existing LinkedDomains.
  3. 3.
    In practice, we noted that client applications capable of DID Resolution will gracefully fail/ignore unknown Service types. Client applications that do understand a particular Service type can continue parsing/resolving content they are designed to handle.
  4. 4.
    DIDDocs can reference other DIDDocs, such as when the DID Controller in one DIDDoc is specified as a Verification Method in another DIDDoc. These links can be traversed using DID URL dereferencing.
  5. 5.
    Historical versions of Resources can always be accessed by traversing forwards/backwards in the Resource Collection by checking if a particular Service ID has old/new versions.
  6. 6.
    Multi-party control on Resource Collection updates is possible, since DIDs with multiple controllers specified in them already handle this scenario. In the normal process of updating a DIDDoc with multiple controllers, rules can be defined by client applications and/or the ledger on whether all controllers sign an update, or whether an m-of-n threshold needs to be applied. (Currently, the cheqd ledger requires all controllers to sign off on updates.)
  7. 7.
    Since the cheqd ledger does not co-relate the on-ledger cheqd/Cosmos accounts to keys that control DIDDocs, this provides another layer of access control by allowing DIDDoc controllers to rotate keys, if required.
Example of referencing a resource using the service section:
{
"service": [{
"id":"did:cheqd:testnet:DAzMQo4MDMxCjgwM#PassportSchema",
"type": "LinkedResource",
"serviceEndpoint": "https://resolver.cheqd.net/1.0/identifiers/did:cheqd:testnet:DAzMQo4MDMxCjgwM/resources/bb2118f3-5e55-4510-b420-33ef9e1726d2"
}]
}

Creating a new Resource within a Resource Collection

To create a new Resource, a client application first needs to create a DID (or use an existing DID) along with its associated DIDDoc. This resource-linked DID is the lowest, direct level of create/update/deactivate operation control that exits.
Resource Creation Flow
Figure 5: Detailed sequence diagram of Resource creation on cheqd (editable version)
Resources must be under the maximum block size restrictions to be able to fit into a transaction. Currently this is estimated to be ~190 KB on cheqd mainnet, based on the ~200 KB block size limit plus additional headroom for metadata that needs to be described in the ResourceHeader.

Resource creation

Each request to create a Resource must provide the following parameters, supplied by the client application:
  • Resource Collection ID: (did:cheqd:...:) (supplied client-side)
  • Resource ID: UUID ➝ specific to resource, also effectively a version number (supplied client-side)
  • Resource Name: String (e.g., CL-Schema1 (supplied client-side)
  • Resource Type (supplied client-side. It is recommended that new Resource Types are included in the DID Spec Registries)
In addition to the above client-provided parameters, the ledger-side code will populate the following additional header fields (for properly-authenticated requests):
  • MediaType: (e.g. application/json/image/application/octet-stream/text/plain) (computed ledger-side) This is based on the file extension of the associated resource file.
  • Created: XMLDatetime (computed ledger-side)
  • Checksum: SHA-256 (computed ledger-side)
  • previousVersionId: null if first, otherwise ID as long as Name, ResourceType, and MimeType match previous version (computed ledger-side)
  • nextVersionId: null if first/latest, otherwise ID as long as Name, ResourceType, and MimeType match previous version (computed ledger-side)
Example using the Veramo CLI:
{
"kms": "local",
"payload": { // example of resource header
"collectionId": "DAzMQo4MDMxCjgwM",
"id": "bb2118f3-5e55-4510-b420-33ef9e1726d2",
"name": "PassportSchema",
"resourceType": "CL-Schema",
"data": "SGVsbG8sIHdvcmxk" // file with resource encoded into base64
},
"signInputs": [{
"verificationMethodId": "did:cheqd:testnet:DAzMQo4MDMxCjgwM#key-1",
"keyType": "Ed25519",
"privateKeyHex": "0f5c124886178037952e87e0cdc55d185732577fca19ae877e64ac9ab24a0cc534e5326e70f1a42d785d93048aee806c359ec75a7b06f39253befd1746708438"
}]
}

ResourcePreview

  • Resource Collection ID: (did:cheqd:...:) (supplied client-side)**
  • Resource ID: UUID ➝ specific to resource, also effectively a version number (supplied client-side)
  • Resource Name: String (e.g., CL-Schema1 (supplied client-side)
  • Resource Type (supplied client-side)
  • MediaType: (e.g. application/json/image/application/octet-stream/text/plain) (computed ledger-side)
  • Created: XMLDatetime (computed ledger-side)
  • Checksum: SHA-256 (computed ledger-side)
  • previousVersionId: null if first, otherwise ID as long as Name, ResourceType, and MimeType match previous version (computed ledger-side)
  • nextVersionId: null if first/latest, otherwise ID as long as Name, ResourceType, and MimeType match previous version (computed ledger-side)
Example:
{
"resourceCollectionId": "DAzMQo4MDMxCjgwM",
"resourceId": "bb2118f3-5e55-4510-b420-33ef9e1726d2",
"resourceName": "PassportSchema",
"resourceType": "CL-SChema",
"mediaType": "application/json",
"created": "2022-04-20T20:19:19Z",
"checksum": "a7c369ee9da8b25a2d6e93973fa8ca939b75abb6c39799d879a929ebea1adc0a",
"previousVersionId": null,
"nextVersionId": null
}

MsgCreateResource

  • Collection ID: (did:cheqd:...:)<identifier> (supplied client-side)
  • ID: UUID ➝ specific to resource, also effectively a version number (supplied client-side)
  • Name: String (e.g., CL-Schema1 (supplied client-side)
  • ResourceType (supplied client-side)**
  • Data: resource-file Path to file with resource content
Example:
{
"kms": "local",
"payload": { // example of resource header
"collectionId": "DAzMQo4MDMxCjgwM",
"id": "bb2118f3-5e55-4510-b420-33ef9e1726d2",
"name": "PassportSchema",
"resourceType": "CL-Schema",
"data": "SGVsbG8sIHdvcmxk" // file with resource encoded into base64
},
"signInputs": [{
"verificationMethodId": "did:cheqd:testnet:DAzMQo4MDMxCjgwM#key-1",
"keyType": "Ed25519",
"privateKeyHex": "0f5c124886178037952e87e0cdc55d185732577fca19ae877e64ac9ab24a0cc534e5326e70f1a42d785d93048aee806c359ec75a7b06f39253befd1746708438"
}]
}

MsgCreateResourceResponse

Example:
{ "resource": <Resource> }

QueryGetCollectionResourcesRequest

  • Collection ID: String - an identifier of linked DIDDoc
Example:
{ "collectionId": "DAzMQo4MDMxCjgwM" }

QueryGetCollectionResourcesResponse

Example:
{ "resources": [<ResourceHeader1>, <ResourceHeader2>] }

QueryGetResourceRequest

  • Collection ID: String - an identifier of linked DIDDoc
  • ID: String - unique resource id
Example:
{
"collectionId": "DAzMQo4MDMxCjgwM",
"id": "bb2118f3-5e55-4510-b420-33ef9e1726d2"
}

QueryGetResourceResponse

Example:
{ "resource": <Resource> }

QueryGetAllResourceVersionsRequest

  • Collection ID: String - an identifier of linked DIDDoc
  • Name: String
  • ResourceType: String
Example:
{
"collectionId": "DAzMQo4MDMxCjgwM",
"name": "PassportSchema",
"resourceType": "CL-Schema"
}

QueryGetAllResourceVersionsResponse

Example:
{ "resources": [<ResourceHeader1>, <ResourceHeader2>] }

State

  • resources:<collection-id>:<resource-id>Resource
    • <collection-id> is the last part of DID. It can be UUID, Indy-style or whatever is allowed by ledger. It allows us to evolve over time more easily.
    • <resource-id> is a unique resource identifier on UUID format

Transactions

CreateResource

  • Input:
  • Processing logic:
    • Check that associated DIDDoc exists;
    • Authenticate request the same way as DIDDoc creation and updating;
    • Validate properties;
    • Validate that ID is unique;
    • Set created date time;
    • Set previousVersion and nextVersion if this is a new version (a resource with the same collection-id, resource-name and resource-type exists);
    • Compute checksum;
    • Persist the resource in state;
cheqd Cosmos CLI Example:
cheqd-noded tx resource create-resource "{
\"collection-id\": \"DAzMQo4MDMxCjgwM\",
\"resource-id\": \"bb2118f3-5e55-4510-b420-33ef9e1726d2\",
\"resource-name"\": \"PassportSchema\",
\"resource-type"\": \"CL-Schema\",
\"resource-file" <resource-file>
<ver-method-id-1> <priv-key-1>
<ver-method-id-N> <priv-key-N>

Queries

GetCollectionResources

GetResource

GetAllResourceVersions

DID Resolver

We need to support resource resolution in the DID resolver.

Resource resolution

  • Input DIDUrl:
    • https://resolver.cheqd.net/1.0/identifiers/<did>/resources/<resource-id>
  • Output:
    • Resource data value
  • Processing logic:

Linked DIDDoc

CollectionId field is an identifier of existing DIDDoc. There are no restrictions on the fields of this DIDDoc other than those described in cheqd DID Method ADR and W3C DID specification. DIDDoc must be located in the same ledger where the resource is created. A list of resources related to DIDDoc can be found in its metadata:
QueryGetDidResponse {
"did": {
"id": "did:cheqd:mainnet:DAzMQo4MDMxCjgwM",
...
},
"didDocumentMetadata": {
"created": "2020-12-20T19:17:47Z",
"updated": "2020-12-20T19:19:47Z",
"deactivated": false,
"versionId": "1B3B00849B4D50E8FCCF50193E35FD6CA5FD4686ED6AD8F847AC8C5E466CFD3E",
"linkedResourceMetadata": [
{
"resourceURI": "did:cheqd:mainnet:DAzMQo4MDMxCjgwM/resources/bb2118f3-5e55-4510-b420-33ef9e1726d2",
"resourceCollectionId": "DAzMQo4MDMxCjgwM",
"resourceId": "bb2118f3-5e55-4510-b420-33ef9e1726d2",
"resourceName": "PassportSchema",
"resourceType": "CL-Schema",
"mediaType": "application/json",
"created": "2022-04-20T20:19:19Z",
"checksum": "a7c369ee9da8b25a2d6e93973fa8ca939b75abb6c39799d879a929ebea1adc0a",
"previousVersionId": null,
"nextVersionId": null
}
]
}
}

Resource versioning

Resource are immutable, but it is possible to create new versions of it under a new identifier(id field). When creating a resource whose fields collectionId, name and resourceType match an existing resource:
  • The latest version of the current resource will be added with a link to the new one. That is, field nextVersionId will contain the new resource identifier.
  • A new resource with data from the transaction will be created with the previous version resource id in field previousVersionId.
Example:
Step 1. Resource exists in the ledger:
{
"resourceURI": "did:cheqd:testnet:DAzMQo4MDMxCjgwM/resources/44547089-170b-4f5a-bcbc-06e46e0089e4",
"resourceCollectionId": "DAzMQo4MDMxCjgwM", // Common collection ID
"resourceId": "44547089-170b-4f5a-bcbc-06e46e0089e4", // Old Resource ID and version number
"resourceName": "PassportSchema", // Resource name must remain the same
"resourceType": "CL-Schema", // Resource type must remain the same
"mediaType": "application/json",
"created": "2022-07-19T08:40:00Z",
"checksum": "7b2022636f6e74656e74223a202274657374206461746122207d0ae3b0c44298", // Old version checksum
"previousVersionId": null, // null, since no previous version
"nextVersionId": null // null, since no next version
}
Step 2. Client send request for creating a new resource with a transaction MsgCreateResource
MsgCreateResource for creating Resource2
{
"collectionId": "DAzMQo4MDMxCjgwM", // same collection ID
"id": "bb2118f3-5e55-4510-b420-33ef9e1726d2", // new unique ID
"name": "PassportSchema", // same resource name
"resourceType": "CL-Schema", // same resource type
"data": ...
}
Step 3. After the transaction applying
"linkedResourceMetadata": [
{ // First version of a Resource called PassportSchema
"resourceURI": "did:cheqd:testnet:DAzMQo4MDMxCjgwM/resources/44547089-170b-4f5a-bcbc-06e46e0089e4",
"resourceCollectionId": "DAzMQo4MDMxCjgwM", // Common collection ID
"resourceId": "44547089-170b-4f5a-bcbc-06e46e0089e4", // Old Resource ID and version number
"resourceName": "PassportSchema", // Resource name must remain the same
"resourceType": "CL-Schema", // Resource type must remain the same
"mediaType": "application/json",
"created": "2022-07-19T08:40:00Z",
"checksum": "7b2022636f6e74656e74223a202274657374206461746122207d0ae3b0c44298", // Old version checksum
"previousVersionId": null, // null, since no previous version
"nextVersionId": "bb2118f3-5e55-4510-b420-33ef9e1726d2", // Points to next version below
},
{ // Second version of a Resource called PassportSchema
"resourceURI": "did:cheqd:testnet:DAzMQo4MDMxCjgwM/resources/bb2118f3-5e55-4510-b420-33ef9e1726d2",
"resourceCollectionId": "DAzMQo4MDMxCjgwM", // Common collection ID
"resourceId": "bb2118f3-5e55-4510-b420-33ef9e1726d2", // New Resource ID and version number
"resourceName": "PassportSchema", // Resource name must remain the same
"resourceType": "CL-Schema", // Resource type must remain the same
"mediaType": "application/json",
"created": "2022-08-07T08:40:00Z",
"checksum": "9123dcbb0b42652b0e105956c68d3ca2ff34584f324fa41a29aedd32b883e131", // New version checksum
"previousVersionId": "44547089-170b-4f5a-bcbc-06e46e0089e4", // Points to previous version above
"nextVersionId": null // null if no new version
}
]

Decision

Assumptions

  • Immutability:
    • Resources are immutable, so can't be updated/removed;
  • Limitations
    • Resource size is now limited by maximum tx/block size;

Future improvements

  • Limitations
    • Introduce module level resource size limit that can be changed by voting

'Resources' module on ledger

A new module will be created: resource.

Dependencies

  • It will have cheqd module as a dependency.
    • Will be used for DIDs existence checks.
    • Will be used for authentication

References

Export as PDF
Copy link
Edit on GitHub
Outline
Status
Summary
Context
"Resources" in decentralised identity
Rationale for storing resources on-ledger
Design principles
Resources on cheqd ledger
Discoverability via DIDDoc Metadata
Optional Discoverability via DIDDoc Services
Creating a new Resource within a Resource Collection
State
Transactions
Queries
DID Resolver
Linked DIDDoc
Resource versioning
Decision
Assumptions
Future improvements
'Resources' module on ledger
Dependencies
References