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
Using the cheqd Schema Request Format and associated resource metadata, the ledger has enough information to compile the following data structure as a response format.
This can either be compiled by the associated SDK handling cheqd AnonCreds, or it can be assembled by the cheqd DID resolver.
The cheqd DID resolver will use the following logic to compile the standardised response format:
If "resourceType=anonCredsSchema" then append "issuerId" to the beginning of the Response Format for the resource presented
To create a schema on cheqd, you should follow the tutorials for creating a DID-Linked Resource here, and pass the relevant JSON file for the object in the transaction.
Existing DID Resolvers will be able to query for any AnonCreds Object Content using the following parameters:
Resource file field | Payload file field |
---|---|
Additional parameter | Expected input | Rationale |
---|---|---|
Parameter | Type | Example |
---|---|---|
"name"
"name"
"version"
"version"
"resourceType"
"anonCredsSchema"
The Payload file drawing inputs from the Resource file does not provide the ledger the requisite amount of information to create a full DID-Linked Resource. resourceType must be provided as an additional input parameter
"resourceId"
did:cheqd:mainnet:46e2af9a-2ea0-4815-999d-730a6778227c?resourceId=0f964a80-5d18-4867-83e3-b47f5a756f02
"resourceName"
did:cheqd:mainnet:46e2af9a-2ea0-4815-999d-730a6778227c?resourceName=degreeLaw
"resourceType"
did:cheqd:mainnet:46e2af9a-2ea0-4815-999d-730a6778227c?resourceName=degreeLaw&resourceType=JSONSchema2020
"resourceVersionId"
did:cheqd:mainnet:46e2af9a-2ea0-4815-999d-730a6778227c?resourceName=degreeLaw&resourceVersionId=1.3.1
"versionTime"
did:cheqd:mainnet:46e2af9a-2ea0-4815-999d-730a6778227c?resourceName=degreeLaw&resourceType=JSONSchema2020&versionTime=2015-03-11T05:30:02Z
"versionId"
did:cheqd:mainnet:46e2af9a-2ea0-4815-999d-730a6778227c?versionId=0f964a80-5d18-4867-83e3-b47f5a756f02
"versionTime"
did:cheqd:mainnet:46e2af9a-2ea0-4815-999d-730a6778227c?resourceName=degreeLaw&resourceType=JSONSchema2020&versionTime=2018-07-19T08:40:00Z
"linkedResource"
did:cheqd:mainnet:46e2af9a-2ea0-4815-999d-730a6778227c?linkedResource=true // note that this would only be a valid query if there is ONLY ONE resource associated with the DID and DID Document.
"resourceMetadata"
did:cheqd:mainnet:46e2af9a-2ea0-4815-999d-730a6778227c?resourceName=degreeLaw&resourceType=JSONSchema2020&versionTime=2018-07-19T08:40:00Z&resourceMetadata=true or, did:cheqd:46e2af9a-2ea0-4815-999d-730a6778227c?resourceMetadata=true // note that this would only be a valid query if there is ONLY ONE resource associated with the DID and DID Document.
"latestResourceVersion
"
did:cheqd:mainnet:46e2af9a-2ea0-4815-999d-730a6778227c?resourceName=degreeLaw&resourceType=JSONSchema2020&latestResourceVersion=true
"allResourceVersions
"
did:cheqd:mainnet:46e2af9a-2ea0-4815-999d-730a6778227c?resourceName=degreeLaw&resourceType=JSONSchema2020&allResourceVersions=true
cheqd AnonCreds Object Method Specification
cheqd intends to directly support AnonCreds using its DID-Linked Resource module in an AnonCreds Object Method. With its resource module, cheqd will identify each on-ledger resource with a DID Core compliant DID URL. This DID URL will be able to be dereferenced in order to fetch the resource and associated metadata.
While AnonCreds are only one flavour of Verifiable Credentials, they are currently in a functional state and are heavily used by cheqd's partners. Other Credential types, such as JSON-LD with BBS+ signatures, can provide a lot of equivalent functionality, but are currently not production ready.
Therefore, it is important for cheqd to provide support for AnonCreds in order to enable partners with existing clients using AnonCreds to use cheqd and existing Indy ledgers concurrently, within existing applications.
Our aim is to support the functionality enabled by identity-domain transactions in by Hyperledger Indy into cheqd-node
. This will reach the goal of allowing use cases of existing SSI networks on Hyperledger Indy to be supported by the cheqd network.
Importantly, we want to make sure that this work is done in a manner which brings AnonCreds closer to W3C compliance and wide-scale interoperability.
cheqd support for Ledger-Agnostic AnonCreds Revocation Registry Definitions
In the ledger-agnostic AnonCreds specification, a Revocation Registry Definition Object acts as an on-ledger hub for revocation, providing a central point information about the:
type
of Revocation Registry (In Indy this is always "CL_ACCUM
").
cred_def_id
: Each Revocation Registry must be linked to one specific Credential Definition.
tag
: An issuer-specified name for the Revocation Registry, to ensure consistency when referencing the registry.
maxCredNum
: The maximum amount of Credentials that can be revoked in the Revocation Registry before a new one needs to be started.
tailsLocation
: A URL resolving to the location of the Tails File.
A Tails File is a large file containing a cryptographic accumulator value of prime numbers multiplied together. When a Credential is revoked, the value of the accumulator changes, removing the cryptographic value of the Credential as a factor of the accumulator value.
Each credential issued using the Revocation Registry Definition is given its own index (1 to the maxCredNum
).
While not required, the Indy community has created a component, the “Indy Tails Server,” which is basically a web server for storing Tails Files.
This documentation will guide an implementor of AnonCreds on cheqd on how the cheqd AnonCreds Object Method defines and structures Revocation Registry Definition IDs and associated content.
If you are not familiar with the latest Ledger-Agnostic AnonCreds Revocation Registry Definition 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 module uses the following format:
did:cheqd:mainnet:<issuerDid>/resources/<revRegDefResourceId>
Rather than using a composite string for the Revocation Registry Definition Resource ID. The cheqd AnonCreds object method uses a UUID to identify the Revocation Registry Definition Object Content.
For example, the following DID URL is cheqd's representation of a revocRegDefId
:
did:cheqd:mainnet:zF7rhDBfUt9d1gJPjx7s1J/resources/af20b1f0-5c4d-4037-9669-eaedddb9c2df
Another supported format for a revocRegDefId
may be used in applications where it is important to derive the credDefId
, revocRegDefId
and statusListId
from the same root.
This format uses query-based syntax, for example:
did:cheqd:mainnet:<IssuerDid>?resourceName=<resourceName>&resourceType=<resourceType>
For example:
did:cheqd:mainnet:zF7rhDBfUt9d1gJPjx7s1J?resourceName=universityDegree&resourceType=anonCredsRevocRegDef
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 revocation registry definition request format comprises of:
A Resource file for the Revocation Registry Definition object content (e.g. degreeRevocRegDef.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 revocation registry definition object in the Response format.
Before creating any on-ledger resource transaction, it is important to assemble the required Revocation Registry Definition Object Content and save it as a file locally.
In the example below, the content should be saved as a file, for example: degreeRevocRegDef.json
with the following content:
Note: The associated Credential Definition specified must have enabled revocation support for the Revocation Registry Definition to be able to be used properly in an SDK.
This Revocation Registry Definition Resource file fields should be replicated where possible within the Payload file, to populate a DID-Linked resource stored on cheqd, with the following mapping:
What this means is that if the Resource file has an object of "type" = "CL_ACCUM" then this should be written as "resourceType" = "anonCredsRevocRegDef" when creating the Payload file.
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 Revocation Registry as a resource on cheqd, the following metadata will be generated in the DID Document Metadata associated with did:cheqd:mainnet:zF7rhDBfUt9d1gJPjx7s1J
Using the cheqd Revocation Registry Definition Request format and associated resource metadata, the ledger has enough information to compile the following data structure as a response format.
This can either be compiled by the associated SDK handling cheqd AnonCreds, or it can be assembled by the cheqd DID resolver.
The cheqd DID resolver will use the following logic to compile the standardised response format:
If "resourceType=anonCredsRevocRegDef" then append "issuerId" to the beginning of the Response Format for the resource presented
To create a Revocation Registry Definition on cheqd, you should follow the tutorials for creating a DID-Linked Resource here, and pass the relevant JSON file for the object in the transaction.
Across the cheqd CredDef Object Method, the Revocation Registry Definition Object Method and the StatusList Object Method - each resource is associated with the same issuer DID and Collection ID.
Importantly, this allows each new resource to be indexed and versioned by their:
resourceName
resourceType
New resources can be created to update the existing CredDef or RevRegDef, whilst maintaining the historical state of the previous versions. See the documentation on Publishing a New Version of a Resource to understand this further.
Existing DID Resolvers will be able to query for the Revocation Registry Definition Object Content using the same patterns and parameters as the Schema Object found here.
The cheqd AnonCreds method also enables applications to derive the CredDef, Revocation Registry Definition Object and Status Lists from the same root:
We propose that the resourceName
for CredDefs, Revocation Registry Definitions and Status Lists should remain the same when each of these resources is part of the same AnonCred. This will make it easier for resources to query by resourceName
and resourceType
to delineate between the three resources using a common root.
Using this logic, the following queries can be used to dereference to CredDefs, Revocation Registry Definitions and Status Lists, in a way which can derive all three resources from the same root:
did:cheqd:mainnet:zF7rhDBfUt9d1gJPjx7s1J?resourceName=universityDegree&resourceType=anonCredsCredDef
did:cheqd:mainnet:zF7rhDBfUt9d1gJPjx7s1J?resourceName=universityDegree&resourceType=anonCredsRevocRegDef
did:cheqd:mainnet:zF7rhDBfUt9d1gJPjx7s1J?resourceName=universityDegree&resourceType=anonCredsStatusList
Note: across all three of these queries, the resolver would fetch the latest version of the resource by default
The AnonCreds construction below uses this logic to demonstrate how an application could derive the latest Revocation Status List using the "rev_reg_id
" since it shares the same root and would only require replacing "anonCredsRevocRegDef" with "anonCredsStatusList".
This is similar to how Hyperledger Indy uses composite strings to derive assoicated AnonCreds Objects from others. For example:
cheqd support for Ledger-Agnostic AnonCreds CredDefs
In the ledger-agnostic AnonCreds specification, Credential Definitions are used to specify the following information all in one place, to create an immutable record of:
The DID of the credential issuer
The schema the issued credentials will be based upon
The public/private key pairs that will be used to sign the claims within an issued credential
A cryptographic secret, embedded within the CredDef Object content, creating an uncorrelatable 'link secret' between the issuer and holder
Information necessary for the revocation of credentials, if revocation is to be enabled by the Issuer for this type of credential (Optional).
This documentation will guide an implementor of AnonCreds on cheqd on how the cheqd AnonCreds Object Method defines and structures cheqd CredDef IDs, CredDef Request formats and CredDef Response formats, with and without revocation enabled.
If you are not familiar with the latest Ledger-Agnostic AnonCreds CredDef 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 module uses the following path-based syntax:
did:cheqd:mainnet:<IssuerDid>/resources/<CredDefResourceId>
Rather than using a composite string for the CredDef Resource ID. The cheqd AnonCreds object method uses a UUID to identify the CredDef Object Content which includes additional CredDef Object Content Metadata, providing the required fields for equivalence with Hyperledger Indy implementations.
For example, the following DID URL is cheqd's representation of a credDefId
:
did:cheqd:mainnet:zF7rhDBfUt9d1gJPjx7s1J/resources/77465164-5646-42d9-9a0a-f7b2dcb855c0
Another supported format for a credDefId
may be used in applications where it is important to derive the credDefId
, revocRegDefId
and statusListEntryId
from the same root.
This format uses query-based syntax, for example:
did:cheqd:mainnet:<IssuerDid>?resourceName=<resourceName>&resourceType=<resourceType>
For example:
did:cheqd:mainnet:zF7rhDBfUt9d1gJPjx7s1J?resourceName=universityDegree&resourceType=anonCredsCredDef
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 CredDef request format comprises of:
A Resource file for the CredDef object content (e.g. degreeCredDef.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 CredDef object in the Response format.
Before creating any on-ledger resource transaction, it is important to assemble the required CredDef Resource file and save it as a file locally.
In the example below, the content should be saved as a file, for example: degreeCredDef.json
with the following content (without revocation):
Or with revocation:
This CredDef 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:
What this means is that if the Resource file has an object of "type" = "CL" then this should be represented as the "resourceType" = "anonCredsCredDef" within the Payload file.
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:zF7rhDBfUt9d1gJPjx7s1J
Using the cheqd CredDef Request format and associated resource metadata, the ledger has enough information to compile the following data structure as a response format.
This can either be compiled by the relevant SDK handling cheqd AnonCreds, or it can be assembled by the cheqd DID resolver.
The cheqd DID resolver will use the following logic to compile the standardised response format:
If "resourceType=anonCredsCredDef" then append "issuerId" to the beginning of the Response Format for the resource presented
To create a CredDef on cheqd, you should follow the tutorials for creating a DID-Linked Resource here, and pass the relevant JSON file for the object in the transaction.
Across the cheqd CredDef Object Method, the Revocation Registry Definition Object Method and the StatusListEntry Object Method - each resource is associated with the same issuer DID and Collection ID.
Importantly, this allows each new resource to be indexed and versioned by their:
resourceName
resourceType
New resources can be created to update the existing CredDef or RevRegDef, whilst maintaining the historical state of the previous versions. See the documentation on Publishing a New Version of a Resource to understand this further.
Existing DID Resolvers will be able to query for the CredDef Object Content using the same patterns and parameters as the Schema Object found here.
The cheqd AnonCreds method also enables applications to derive the CredDef, Revocation Registry Definition Object and Status List from the same root:
We propose that the resourceName
for CredDefs, Revocation Registry Definitions and Status Lists should remain the same when each of these resources is part of the same AnonCred. This will make it easier for resources to query by resourceName
and resourceType
to delineate between the three resources using a common root.
Using this logic, the following queries can be used to dereference to CredDefs, Revocation Registry Definitions and Status List, in a way which can derive all three resources from the same root:
did:cheqd:mainnet:zF7rhDBfUt9d1gJPjx7s1J?resourceName=universityDegree&resourceType=anonCredsCredDef
did:cheqd:mainnet:zF7rhDBfUt9d1gJPjx7s1J?resourceName=universityDegree&resourceType=anonCredsRevocRegDef
did:cheqd:mainnet:zF7rhDBfUt9d1gJPjx7s1J?resourceName=universityDegree&resourceType=anonCredsStatusList
Note: across all three of these queries, the resolver would fetch the latest version of the resource by default
The AnonCreds construction below uses this logic to demonstrate how an application could derive the latest Status List using the "rev_reg_id
" since it shares the same root and would only require replacing "anonCredsRevocRegDef" with "anonCredsStatusList".
This is similar to how Hyperledger Indy uses composite strings to derive assoicated AnonCreds Objects from others. For example:
cheqd support for Ledger-Agnostic AnonCreds Revocation Status List Objects
In the ledger-agnostic AnonCreds specification, Status List Objects contain the state of the cryptographic accumulator and revocation indices at a given point in time. This enables:
Holders of Verifiable Credentials to generate a proof of non-revocation (or not) about their specific credential; and
Verifiers to be able to verify that proof.
A Status List is generated and published immediately on creation of the Revocation Registry Definition Object so that it can be used immediately by holders. Over time, additional Status Lists may be generated and published as the revocation status of one or more credentials within the Revocation Registry change.
In each of these subsequent Revocation Status List Objects, there is an updated cryptographic accumulator value AND an updated list of revoked indices, pointing to the Revocation Registry Definition Object and a location within a Tails File, associated with an index value.
This documentation will guide an implementor of AnonCreds on cheqd on how the cheqd AnonCreds Object Method defines and structures Status List IDs, Request Formats and Response Formats.
If you are not familiar with the latest Ledger-Agnostic AnonCreds Revocation Registry Definition 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 module uses the following format:
did:cheqd:mainnet:<issuerDid>/resources/<statusListId>
Rather than using a composite string for the Status List ID. The cheqd AnonCreds object method uses a UUID to identify the Revocation Status List Object.
For example, the following DID URL is cheqd's representation of a statusListId
:
did:cheqd:mainnet:zF7rhDBfUt9d1gJPjx7s1J/resources/9d26b902-555d-43bd-bac3-0bedeb462887
Another supported format for a statusListId
may be used in applications where it is important to derive the credDefId
, revocRegDefId
and statusListId
from the same root.
This format uses query-based syntax, for example:
did:cheqd:mainnet:<IssuerDid>?resourceName=<resourceName>&resourceType=<resourceType>
For example:
did:cheqd:mainnet:zF7rhDBfUt9d1gJPjx7s1J?resourceName=universityDegree&resourceType=anonCredsStatusList
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 AnonCreds Status List request format comprises of:
A Resource file for the Status List object content (e.g. degreeStatusList.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 Revocation Registry Definition object in the Response format.
Before creating any on-ledger resource transaction, it is important to assemble the required Status List Content and save it as a file locally.
In the example below, the content should be saved as a file, for example: degreeStatusList.json
with the following content:
This Status List 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:
What this means is that if the Resource file has an object of "type" = "currentAccumulator" then this should be written as "resourceType" = "anonCredsStatusList" when creating the Payload file.
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 Status List Object as a resource on cheqd, the following metadata will be generated in the DID Document Metadata associated with did:cheqd:mainnet:zF7rhDBfUt9d1gJPjx7s1J
Next and Previous Status Lists will appear in the resource Metadata when a new Status List is made with the same resourceName
and resourceType
Using the cheqd Status List Request format and associated resource metadata, the ledger has enough information to compile the following data structure as a response format.
This can either be compiled by the relevant SDK handling cheqd AnonCreds, or it can be assembled by the cheqd DID resolver.
The cheqd DID resolver will use the following logic to compile the standardised response format:
If "resourceType=anonCredsStatusList" then append "created" into a field called "timestamp" to the end of the Response Format for the resource presented
To Create a Status List as a new version of a previous Status List, you need to create a new resource.
You must:
Generate a new UUID for the resourceId
Specify the same collectionId
Specify the same resourceName
Specify the same resourceType
Attach to the transaction the new resourceFile
with the latest accum
value and index
values.
Once the transaction has been created, the resourceMetadata
will look like the following:
Note: The previousVersionId will now link to the previous Revocation Status List ID
Across the cheqd CredDef Object Method, the Revocation Registry Definition Object Method and the StatusList Object Method - each resource is associated with the same issuer DID and Collection ID.
Importantly, this allows each new resource to be indexed and versioned by their:
resourceName
resourceType
New resources can be created to update the existing CredDef or RevRegDef, whilst maintaining the historical state of the previous versions. See the documentation on Publishing a New Version of a Resource to understand this further.
Existing DID Resolvers will be able to query for the Status List Object Content using the same patterns and parameters as the Schema Object found here.
The cheqd AnonCreds method also enables applications to derive the CredDef, Revocation Registry Definition Object and Status Lists from the same root:
We propose that the resourceName
for CredDefs, Revocation Registry Definitions and Revocation Status Lists should remain the same when each of these resources is part of the same AnonCred. This will make it easier for resources to query by resourceName
and resourceType
to delineate between the three resources using a common root.
Using this logic, the following queries can be used to dereference to CredDefs, Revocation Registry Definitions and Status Lists, in a way which can derive all three resources from the same root:
did:cheqd:mainnet:zF7rhDBfUt9d1gJPjx7s1J?resourceName=universityDegree&resourceType=anonCredsCredDef
did:cheqd:mainnet:zF7rhDBfUt9d1gJPjx7s1J?resourceName=universityDegree&resourceType=anonCredsRevocRegDef
did:cheqd:mainnet:zF7rhDBfUt9d1gJPjx7s1J?resourceName=universityDegree&resourceType=anonCredsStatusList
Note: across all three of these queries, the resolver would fetch the latest version of the resource by default
Using existing DID Resolvers, it is possible to traverse the history of Status List versions in order to produce proofs of non-revocation required in the AnonCreds Specification.
A DID URL such as the following will display all of the accumulators associated with a particular Status List:
did:cheqd:mainnet:zF7rhDBfUt9d1gJPjx7s1J?resourceName=universityDegree&resourceType=anonCredsStatusList&allResourceVersions=true
Furthermore, it will be possible to query Status Lists at certain times. This may be very useful if you want to prove whether a Verifiable Credential was valid in the past:
did:cheqd:mainnet:zF7rhDBfUt9d1gJPjx7s1J?universityDegree&resourceType=anonCredsStatusList&versionTime=2022-08-21T08:40:00Z
It will be very common for a proof of non-revocation to require the latest Status List and work its way back from there.
The following DID URL will be able to call the latest Status List:
did:cheqd:mainnet:zF7rhDBfUt9d1gJPjx7s1J?universityDegree&resourceType=anonCredsStatusList
The AnonCreds construction below uses this logic to demonstrate how an application could derive the latest Status List using the "rev_reg_id
" since it shares the same root and would only require replacing "anonCredsRevocRegDef" with "anonCredsStatusList".
This is similar to how Hyperledger Indy uses composite strings to derive assoicated AnonCreds Objects from others. For example:
``
Resource file field | Resource file input | Payload file field | Payload file input |
---|---|---|---|
Additional parameter | Expected input | Rationale |
---|---|---|
CredDef Object field | CredDef Object expected input | Mapped Payload file field | Mapped Payload file input |
---|---|---|---|
Additional parameter | Expected input | Rationale |
---|---|---|
Resource file field | Resource file input | Payload file field | Payload file input |
---|---|---|---|
Additional parameter | Expected input | Rationale |
---|---|---|
"type"
"CL_ACCUM"
"resourceType"
"anonCredsRevocRegDef"
"tag"
""
"resourceVersion"
""
"name"
"<insert same name as CredDef>"
The Payload file drawing inputs from the Resource file on its own does not provide the ledger the requisite amount of information to create a full DID-Linked Resource. resourceName must be provided as an additional input parameter
"type"
"CL"
"resourceType"
"anonCredsCredDef"
"tag"
""
"resourceVersion"
""
"name"
"universityDegree"
The Payload file drawing inputs from the Resource file on its own does not provide the ledger the requisite amount of information to create a full DID-Linked Resource. resourceName must be provided as an additional input parameter
"type"
"currentAccumulator"
"resourceType"
"anonCredsStatusList"
"name"
"<insert same name as CredDef and RevocRegDef>"
The Payload file drawing inputs from the Resource file on its own does not provide the ledger the requisite amount of information to create a full DID-Linked Resource. resourceName must be provided as an additional input parameter
Schemas
Create Schemas using DID-Linked Resources to support AnonCreds on cheqd.
Credential Definitions
Create CredDefs using DID-Linked Resources to support AnonCreds on cheqd.
Revocation Registry Definitions
Create Revocation Registry Definitions using DID-Linked Resources to support AnonCreds on cheqd.
Revocation Status Lists
Create Revocation Status Lists using DID-Linked Resources to support AnonCreds on cheqd.