Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
As a Trusted Accreditation Organisation (TAO), it is possible to accredit Trusted Issuers (TIs) to issue Verifiable Attestations.
The Verifiable Accreditation should include:
Field | Description | Example |
---|---|---|
Root TAOs can set permissions under which TAOs must abide. This creates a level of codified governance for the trust ecosystem.
Whereby:
The Root TAO can also set polices known as the AccreditationPolicy
within the termsOfUse
section of the Verifiable Accreditation.
Whereby:
Verifiable Credentials (VCs) are, in most cases, issued by legal entities. The purpose of Verifiable Credentials is to provide the Relying Party that receives the credentials a Level of Assurance (LoA) that the attributes and claims within the credential are legitimate. However, it is not currently easy to determine whether a legal entity issuing a credential is in fact the entity they claim to be, and not, a fraudulent misrepresentation of that legal entity. This is the challenge that Trust Infrastructure and Trust Registries are positioned to solve.
Note: This Trust Registry challenge is a significant problem for the digital credential industry, and often inhibits the technology reaching a production stage of readiness.
At present, legal entities that issue credentials have no mechanism to establish that they are trustworthy; thus, Relying Parties may not recognise the DIDs signing the Verifiable Credentials they receive. To fully establish trust, Relying Parties need to know who issued the VCs, whether the issuer is recognised as trusted within a particular governance framework, and who accredited the issuer for the purpose of issuing the credential.
To solve this industry-wide challenge, cheqd introduces a Verifiable Trust Infrastructure, that directly complements the model . Within cheqd's Trust Infrastructure, users can create hierarchical chains of trust "Trust Chains" that together encapsulate a "Trust Registry" for a given ecosystem.
The Trust Infrastructure Model also includes permissions and policies set via "Verifiable Accreditations" and an overall "Governance Framework". Herein, permissions govern the scope of , while policies are used to define who made the accreditation; which Trust Framework is followed; and, the legal basis of the credential.
cheqd Trust Infrastructure users make the whole Verifiable Trust Model publicly available by registering it as a collection of on cheqd. cheqd's Trust Infrastructure therefore enables verifiers to automatically resolve and establish trust in hierarchies of trust without needing to know each organisation directly, using industry-standard resolution mechanisms defined in the W3C DID-Core and the DID Resolution Spec.
There are many terms used within this guide, and as such, familiarise yourself or refer back to the concepts within the glossary below:
Abbreviation | Term | Description |
---|
Depending on their accreditations and authorisations, legal entities can play the following roles:
Root Trusted Accreditation Organisation (Root TAO)
Trusted Accreditation Organisation (TAO)
Trusted Issuer (TI)
A Trust Chain should contain all three roles, even if one single DID would represent all three roles. The roles must be RTAO, TAO, and TI, where only TI may issue domain-specific Verifiable Credentials.
The Root TAO is the owner of a Trust Chain, responsible for the governance of the whole Trust Chain. Root TAOs may:
accredit itself to govern or issue domain-specific Verifiable Credentials
accredit TAOs to govern a segment of the Trust Chain
accredit a Trusted Issuer to issue domain-specific Verifiable Credentials
revoke an accreditation from a legal entity that is participating in the Trust Chain
The RTAO permission is defined by VerifiableAuthorisationForTrustChain
, and the policies are contained in termsOfUse
as TrustFrameworkPolicy
.
A TAO governs an accredited segment on behalf of the RTAO. It may:
accredit itself to issue domain-specific Verifiable Credentials
accredit another TAO to govern a segment of the Trust Chain
accredit a Trusted Issuer to issue domain-specific Verifiable Credentials
revoke accreditation from a legal entity that was accredited by the TAO
The TAO permission is defined by VerifiableAccreditationToAccredit
, and the policies are contained in termsOfUse
as AccreditationPolicy
.
A Trusted Issuer represents the Issuer in a Trust Chain. It may issue domain-specific Verifiable Credential types defined by the received accreditation.
Note that issuers may issue Verifiable Credentials outside the Trust Chain, but these are not associated or recognised by a Root TAO and therefore contain no weight within the Trust Chain's governance framework.
The TI permission is defined by VerifiableAccreditationToAttest
, and the policies are contained in termsOfUse
as AccreditationPolicy
. When the Trusted Issuer is using their accreditation to issue a domain-specific VC, the issued domain VC must contain a termsOfUse
property with AttestationPolicy
type, which links to the Trusted Issuer's accreditation and into Root TAO's accreditation, where both are located in TIR.
The Governance Framework Policy is a document, written by a Governance Authority, that defines requirements that must be met for the Trust Ecosystem. These requirements may include security, legal, operational, or functional requirements and may relate to regulation, directives, national policy, or similar documents.
All Trust Model policies are located in the termsOfUse
property of the corresponding Accreditation or credential that contains the permissions related to the policy.
Accreditations are certifications of being qualified to accredit or attest. Accreditations are attribute-driven and are always restricted to domain-specific credential types. These restrictions cannot be extended. For example, if a legal entity is accredited to accredit Issuers of diploma VCs, they may only pass this or a subset downstream of the hierarchy. Depending on the accreditation, the accredited legal entity may govern (accredit) or issue (attest), but always within the Trust Model and the accredited boundaries.
Each Verifiable Accreditation is also associated with an AccreditationPolicy
in the termsOfUse
section of the credential. This Policy links to the parent or root accreditation to enable verifiers to traverse the trust registry.
All Verifiable Credentials are attestations of something. Any issuer may issue credentials (default), while accredited Trusted Issuers may issue domain-specific VCs with the accreditation, by attaching the AttestationPolicy
into termsOfUse
.
End Users (legal entities or natural persons) can accumulate multiple Verifiable Credentials from one or many Trust Models.
The following diagram show how a Root TAO accredits two TAOs lower in the hierarchy:
where:
Root of Trust (rTAO) DID:
Controls Verifiable Accreditations (VAs) issued from rTAO to TAOs.
Accredited Org (TAO) DID:
Controls Verifiable Accreditations (VAs) issued from TAOs to Trusted Issuers.
Trusted Issuer DID:
Issues Verifiable Credentials with Issuance Policies
Verifiable Credentials
Issued including the Issuance Policies in the TermsOfUse
section of the data model.
Issued to Digital Identity Wallet of user or organisation, which can be later verified up the entire trust chain.
Trust Registries are referenced within Accreditaiton Policies in the Verifiable Credential body. This enables Relying Parties to traverse the trust chain and verify that the issuer, accrediting entity (TAO) and Root of Trust (rTAO) are all legitimate entities.
Within the body of the Verifiable Credential, issuers will need to configure the termsOfUse
section to reference DIDs or DID URLs of trust registry entries, for example:
Issue Verifiable Accreditations as DID-Linked Resources
Users are able to issue Verifiable Accreditations as DID-Linked Resources on-ledger, which may be used to verify whether a particular recipient of an accreditation is accredited to issue a certain type of credential, under the scope of a particular governance framework. This implementation on cheqd builds on the principles of the EBSI Trust Chain model, using DID-Linked Resources to create a more standardised format for storing, retrieving and dereferencing to trust registry entries.
Make sure you have set up your account with cheqd Studio and are logged in, using our guide below:
Before you can create a Verifiable Accreditation, you need to create a DID which is used to link to one or multiple Verifiable Accreditations on-ledger. Use the API in the page below to create a DID:
Verifiable Accreditations are JSON objects that take the form of the Verifiable Credential data model. There are three types of Verifiable Accreditation:
Type | Description |
---|
For each accreditation type, the user will need to use a different request format for the API.
For a trusted ecosystem, these attestations are required to trace the legitimacy of a credential issuer to a root-of-trust.
For a trusted ecosystem, these attestations are required to trace the legitimacy of a credential issuer to a root-of-trust.
Owing to the design of DID-Linked Resources, following the creation of the a Verifiable Accreditation, users are able to reference the specific version, or create a query to always fetch the latest version of the Accreditation.
Using a DID Resolver or the search DID endpoint, users can find the DID URL and unique resourceId of the Verifiable Accreditation. The unique resourceId allows users to specify this exact version of the Accreditation.
In the DID Document Metadata, users should find "linkedResourceMetadata", like the following snippet:
Here, the "resourceURI
" specifies the DID URL of the specific Verifiable Accreditation that was created.
In order to reference the latest version of the Verifiable Accreditation, the following construction needs to be used:
did:cheqd:<namespace>:<resourceCollectionId>?resourceName=<resourceName>&resourceType=<resourceType>
For example:
did:cheqd:testnet:0a5b94d0-a417-48ed-a6f5-4abc9e95888d?resourceName=OxfordUniversityAccreditation&resourceType=VerifiableAccreditationToAccredit
In order to reference the Verifiable Accreditation at a particular point in time, the following construction needs to be used:
did:cheqd:<namespace>:<resourceCollectionId>?resourceName=<resourceName>&resourceType=<resourceType>&resourceVerionTime=<XMLDateTime>
For example:
did:cheqd:testnet:0a5b94d0-a417-48ed-a6f5-4abc9e95888d?resourceName=OxfordUniversityAccreditation&resourceType=VerifiableAccreditationToAccredit&resourceVersionTime=2023-02-22T06:58:18.61Z
As a Trusted Accreditation Organisation (TAO), it is possible to accredit Sub-Trusted Accreditation Organisations (SubTAOs) to issue Verifiable Accreditations or Verifiable Attestations.
The Verifiable Accreditation should include:
Field | Description | Example |
---|
Root TAOs can set permissions under which TAOs must abide. This creates a level of codified governance for the trust ecosystem.
Whereby:
The Root TAO can also set polices known as the AccreditationPolicy
within the termsOfUse
section of the Verifiable Accreditation.
Whereby:
Users are able to issue Verifiable Accreditations to determine the validity of the accreditation, as well to traverse the trust chain to a root of trust.
Make sure you have already created at least one Verifiable Accreditation that you are able to query in the verify API.
As a Root of Trust (RTAO) entity, it is possible to accredit Trusted Accreditation Organisations to issue Verifiable Accreditations or Verifiable Attestations.
The Verifiable Accreditation should include:
Field | Description | Example |
---|
Root TAOs can set permissions under which TAOs must abide. This creates a level of codified governance for the trust ecosystem.
Whereby:
The Root TAO can also set polices known as the TrustFrameworkPolicy
within the termsOfUse
section of the Verifiable Accreditation.
Whereby:
Establish end-to-end trust using cheqd's trust registry infrastructure
Trust Registries enable a Relying Party to determine the authenticity of a legal entity within a digital credential ecosytem. Trust Registries are crucial to establish for production environments, because they add extra levels of assurance to the authenticity of Decentralized Identifiers (DIDs).
cheqd has pioneered a industry-leading trust registry solution, allowing users to create hierarchical chains of trust, with each trust registry entry being DID-Resolvable.
cheqd supports multiple Trust Registry Data Models, using its flexible DID and DID-Linked Resource architecture. Users should familiarise themselves with each Trust Registry approach before getting started with our APIs.
Learn about a data model below:
Start building with our cheqd Studio APIs and configure a trust registry for your digital credential ecosystem:
cheqd's Trust Registry model can work in conjunction with the implementation for establishing secure Roots of Trust and Trust Registry policy resolution.
Field | Description |
---|---|
Field | Description |
---|---|
Request Parameter | Required | Description |
---|
Request Parameter | Required | Description |
---|
Request Parameter | Required | Description |
---|
Field | Description |
---|
Field | Description |
---|
Field | Description |
---|
Field | Description |
---|
Issuer
DID of the TAO
did:cheqd:testnet:e66a9416-d03e-4ced-95e3-07af16e25bc5
Subject
DID of the Trusted Issuer that is being accredited
did:cheqd:testnet:f6e731f0-5bfb-429b-b2c7-e65a951d7b5e
Credential Subject
A set of structured permissions around what credentials the Trusted Issuer is accredited to issue, and in which jurisdiction.
See below
Terms of use
A set of policies setting out the scope of Trust Chain for Relying parties to validate against.
See below
schemaId
Schema of the Verifiable Accreditation that the SubTAO is accredited to issue themselves
types
Types of Credential that the SubTAO is accredited to issue
limitJurisdiction
Permission that the TAO can set to limit the jurisdictional scope of the credentials issued in the ecosystem
type
Must be AccreditationPolicy
parentAccreditation
The DID URL of the Accreditation issued by another TAO or the Root TAO to the TAO
rootAuthoroisation
The DID URL of the Root of Trust Verifiable Authorsation
trustFramework
Name of Governance Framework set by the Governance Authority
trustFrameworkId
URL linking to where the written Governance Framework is stored
"issuerDid" | Yes | The DID of the Issuer of the Accreditation |
"subjectDid" | Yes | The DID of the Recipient of the Accreditation |
"schemas" | Yes | A schema or multiple schemas that the recipient is accredited to issue |
"format" | Optional | Defaults to "jwt" but may also be "json-ld" |
"accreditationName" | Yes | Name of the accreditation which is used for chronological versioning of the accreditation. |
"trustFramework" | Yes | A URL that points to an Ecosystem Governance Framework |
"trustFrameworkId" | Yes | The name of the Ecosystem Governance Framework |
"credentialStatus" | Optional | An object detailing the status information of the Accreditation |
"issuerDid" | Yes | The DID of the Issuer of the Accreditation |
"subjectDid" | Yes | The DID of the Recipient of the Accreditation |
"schemas" | Yes | A schema or multiple schemas that the recipient is accredited to issue |
"format" | Optional | Defaults to "jwt" but may also be "json-ld" |
"accreditationName" | Yes | Name of the accreditation which is used for chronological versioning of the accreditation. |
"parentAccreditation" | Yes | A URL or DID URL of Accreditation of the Issuer demonstrating capacity to issue this Accreditation. |
"rootAuthorization" | Yes | A URL or DID URL of the root authorization governing the ecosystem |
"credentialStatus" | Optional | An object detailing the status information of the Accreditation |
"issuerDid" | Yes | The DID of the Issuer of the Accreditation |
"subjectDid" | Yes | The DID of the Recipient of the Accreditation |
"schemas" | Yes | A schema or multiple schemas that the recipient is accredited to issue |
"format" | Optional | Defaults to "jwt" but may also be "json-ld" |
"accreditationName" | Yes | Name of the accreditation which is used for chronological versioning of the accreditation. |
"parentAccreditation" | Yes | A URL or DID URL of Accreditation of the Issuer demonstrating capacity to issue this Accreditation. |
"rootAuthorization" | Yes | A URL or DID URL of the root authorization governing the ecosystem |
"credentialStatus" | Optional | An object detailing the status information of the Accreditation |
schemaId | Schema of the Verifiable Accreditation that the SubTAO is accredited to issue themselves |
types | Types of Credential that the SubTAO is accredited to issue |
limitJurisdiction | Permission that the TAO can set to limit the jurisdictional scope of the credentials issued in the ecosystem |
type | Must be |
parentAccreditation | The DID URL of the Accreditation issued by another TAO or the Root TAO to the TAO |
rootAuthoroisation | The DID URL of the Root of Trust Verifiable Authorsation |
trustFramework | Name of Governance Framework set by the Governance Authority |
trustFrameworkId | URL linking to where the written Governance Framework is stored |
schemaId | Schema of the Verifiable Accreditation that the TAO is accredited to issue themselves |
types | Types of Credential that the TAO is accredited to issue |
limitJurisdiction | Permission that the RTAO can set to limit the jurisdictional scope of the credentials issued in the ecosystem |
type | Must be |
trustFramework | Name of Governance Framework set by the Governance Authority |
trustFrameworkId | URL linking to where the written Governance Framework is stored |
- | Accreditation Policy | Part of a Verifiable Credential, using the |
DID | Decentralised Identifier | Legal entity identifier for Trust Registry, cannot be natural person in context of Trust Infrastructure |
GA | Governance Authority | The legal entity or consortia responsible for writing the Governance Framework. In many instances the Governance Authority is also a Root TAO |
GF | Governance Framework | A policy document outlining the purpose, roles, scopes and permissions for a given ecosystem using the Trust Infrastructure. |
Root TAO | Root Trusted Accreditation Organization | Legal entity governing the whole trust chain |
TAO | Trusted Accreditation Organization | Legal entity governing a trust chain segment |
- | Trust Chain | Hierarchy of Verifiable Accreditations. Multiple Trust Chains may comprise a Trust Registry. |
TI | Trusted Issuer | Legal entity participating in a trust chain as an issuer |
- | Trust Infrastructure | The overall set of technical and governance components to establish end-to-end trust. |
- | Verifiable Accreditation | Type of on-ledger Verifiable Credential that is specifically used for establishing governance permissions and policies |
- | Verifiable Trust Model | Permissions with policies to either accredit, or to attest |
Verifiable Authorisation for Trust Chain | This Accreditation authorises the recipient to issue Accreditations with reference to a particular governance framework. |
Verifiable Accreditation to Accredit | This Accreditation verifies that an organisation has the permissions needed to accredit other organisations for issuing a particular type of Verifiable Accredittion. |
Verifiable Accreditation to Attest | This Accreditation verifies that an organisation has the permissions needed to issue Verifiable Credentials, defined by a particular schema. |
Issuer | DID of the TAO | did:cheqd:testnet:a2b675de-33d0-4044-8183-0d74f210cceb |
Subject | DID of the SubTAO that is being accredited | did:cheqd:testnet:e66a9416-d03e-4ced-95e3-07af16e25bc5 |
Credential Subject | A set of structured permissions around what credentials the SubTAO is accredited to issue, and in which jurisdiction. | See below |
Terms of use | A set of policies setting out the scope of Trust Chain for Relying parties to validate against. | See below |
Issuer | DID of the Root of Trust (RTAO) | did:cheqd:testnet:8ea036da-f340-480d-8952-f5561ea1763c |
Subject | DID of the TAO that is being accredited | did:cheqd:testnet:a2b675de-33d0-4044-8183-0d74f210cceb |
Credential Subject | A set of structured permissions around what credentials the TAO is accredited to issue, and in which jurisdiction. | See below |
Terms of use | A set of policies setting out the Governance Framework for the ecosystem | See below |
Generate and publish a Verifiable Accreditation for a subject DID as a DID Linked resource.
If set to true
the verification will also check the status of the accreditation. Requires the VC to have a credentialStatus
property.
If set to true
allow to verify accreditation which based on deactivated DID.
DID of the Verifiable Accreditation holder/subject. This needs to be a did:key
DID.
"did:cheqd:testnet:5efa5126-c070-420f-a9c2-d22ae6eefb92"
DID URL of the Verifiable Accreditation to be verified as a VC-JWT string or a JSON object.
"did:cheqd:testnet:7c2b990c-3d05-4ebf-91af-f4f4d0091d2e?resourceName=cheqd-issuer-logo&resourceType=CredentialArtwork"
DID of the Verifiable Accreditation holder/subject
"did:cheqd:testnet:7c2b990c-3d05-4ebf-91af-f4f4d0091d2e"
Unique resource identifier of the Verifiable Accreditation
"398cee0a-efac-4643-9f4c-74c48c72a14b"
Resource name of the Verifiable Accreditation
"cheqd-issuer-logo"
Resource type of the Verifiable Accreditation
"CredentialArtwork"
The list of schemas the subject DID is accredited for.
Custom verification policies to execute when verifying Accreditation.
Policy to skip the issuanceDate
(nbf
) timestamp check when set to false
.
Policy to skip the expirationDate
(exp
) timestamp check when set to false
.
Policy to skip the audience check when set to false
.
The request was successful.
"2023-06-08T13:49:28.000Z"
"did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0"
"did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"
"https://resolver.cheqd.net/1.0/identifiers/did:cheqd:testnet:7c2b990c-3d05-4ebf-91af-f4f4d0091d2e?resourceName=cheqd-suspension-1&resourceType=StatusList2021Suspension#20"
20
"suspension"
"2023-06-08T13:49:28.000Z"
Generate and publish a Verifiable Accreditation for a subject DID as a DID Linked resource.
Select the type of accreditation to be issued.
DID of the Verifiable Accreditation issuer. This needs to be a did:cheqd
DID.
"did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0"
DID of the Verifiable Accreditation holder/subject. This needs to be a did:cheqd
DID.
"did:cheqd:testnet:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"
The list of schemas the subject DID is accredited for.
Unique name of the Verifiable Accreditation.
JSON object containing the attributes to be included in the Accreditation.
Optional properties to be included in the @context
property of the Accreditation.
DID URL of the parent Verifiable Accreditation, required for accredit/attest operation.
DID URL of the root Verifiable Accreditation, required for accredit/attest operation.
Name or Type of the Trust Framework, required for authorise operation.
Url of the Trust Framework, required for authorise operation.
Optional properties to be included in the type
property of the Accreditation.
Optional expiration date according to the <a href=https://www.w3.org/TR/vc-data-model/#expiration> VC Data Model specification.
"2023-06-08T13:49:28.000Z"
Format of the Verifiable Accreditation. Defaults to VC-JWT.
"jwt"
Optional credentialStatus
properties for VC revocation or suspension. Takes statusListName
and statusListPurpose
as inputs.
Terms of use can be utilized by an issuer or a holder to communicate the terms under which a verifiable credential was issued.
RefreshService property MUST be one or more refresh services that provides enough information to the recipient's software such that the recipient can refresh the verifiable credential.
Evidence property MUST be one or more evidence schemes providing enough information for a verifier to determine whether the evidence gathered by the issuer meets its confidence requirements for relying on the credential.
The request was successful.
"2023-06-08T13:49:28.000Z"
"did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0"
"did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"
"https://resolver.cheqd.net/1.0/identifiers/did:cheqd:testnet:7c2b990c-3d05-4ebf-91af-f4f4d0091d2e?resourceName=cheqd-suspension-1&resourceType=StatusList2021Suspension#20"
20
"suspension"
"2023-06-08T13:49:28.000Z"