cheqd support for Ledger-Agnostic AnonCreds schemas
Schemas are used to list a set of attributes. Issuers of Verifiable Credentials may reference schemas within Credentials they issue in order to provide a layer of semantic interoperability with other issuers utilising the same schema.
In the AnonCreds Specification, schemas are written directly to a Verifiable Data Registry, rather than using a centralized service such as schema.org. Schemas are also referenced within Credential Definitions, which are used to link the schema, issuer and holder together (detailed further here).
This documentation will guide an implementor of AnonCreds on cheqd on how the cheqd AnonCreds Object Method defines the structure of cheqd schema IDs, the schema request format and the schema response format.
If you are not familiar with the latest Ledger-Agnostic AnonCreds Schema structure, click the collapsible tile below to learn about the new format.
cheqd uses DID-Linked Resources to identify individual resources, associated with a DID, using fully resolvable DID URLs.
cheqd resources implementation uses the following path-based syntax:
did:cheqd:mainnet:<SchemaIssuerId>/resources/<SchemaId>
The cheqd AnonCreds object method uses a UUID to identify the Schema Object Content.
For example, the following DID URL is cheqd's representation of a schemaId
:
did:cheqd:mainnet:7BPMqYgYLQni258J8JPS8K/resources/6259d357-eeb1-4b98-8bee-12a8390d3497
It is important to differentiate between the Request format for creating an AnonCreds object on cheqd, and the Response format, for how an AnonCreds objectshould be compiled by SDKs and the cheqd DID Resolver.
The request format may be specific to each AnonCreds Object Method. However, the response format should be standardised to enable any AnonCreds supported application to understand the object, without needing custom or method-specific logic.
The cheqd schema request format comprises of:
A Resource file for the Schema object content (e.g. degreeSchema.json
); and
A Payload file (including the signing keys and additional inputs to create a DID-Linked Resource).
Both of these inputs are required to provide the ledger enough information to:
Populate a cheqd DID-Linked Resource; and
Compile a standardised AnonCreds schema object in the Response format.
Before creating any on-ledger transaction, it is important to assemble the required Schema Object Content and save it as a file locally.
In the example below, the content should be saved as a JSON file, for example: degreeSchema.json
with the following content:
This Schema Resource file inputs should be replicated where possible within the Payload file, to populate a DID-Linked resource stored on cheqd, with the following mapping:
The Payload file utilises the inputs from the Resource file where possible, mapping common fields across. The Payload file may also require additional inputs to be provided by the creator to create a DID-Linked Resource for inputs not provided in the Resource file.
Below is an example of a Payload file:
When passing the Payload file to the ledger, additional inputs may be required within the Payload file to populate the DID-Linked Resource. In this instance, the only additional information required is:
For example, the full request format using a CLI should be structured as follows:
Once you have created your resource on cheqd, the following metadata will be generated in the DID Document Metadata associated with did:cheqd:mainnet:7BPMqYgYLQni258J8JPS8K