Setup AI Agent Trust Registry
Walkthrough for setting up Trust Registries for your AI Agents.
Users are able to build AI Agent Trust Registries using our cheqd Studio APIs. The following steps will enable organisations, governance authorities, auditors and AI Agents to establish permissions, rules and hierarchy between each other.
Step 1: Set up your cheqd Studio account
Make sure you have set up your account with cheqd Studio and are logged in, using our guide below:
Step 2: Create a Root DID
The first step for any trust registry is a Root DID, which acts as a trust anchor for the chain of trust below. This DID should be for the highest level of trust in your ecosystem, such as a governance authority, a managing company or an auditor.
For more basic trust registries, the company issuing the AI Agent credentials may also be the Root of Trust with the Root DID.
Step 3: Design Schemas for your Ecosystem
When you accredit an AI Agent or Organisation that builds AI Agents, you need to do so for a particular purpose. These purposes are defined in schemas, containing the fields that MUST or MAY be present in an accreditation or credential.
We have created some template schemas that we suggest you use within your trust registry!
3.1 Verifiable Attestation
This is a schema for a Verifiable Credential issued to your AI Agent from a Trusted Issuer. The Issuer attests to features of the AI Agent, hence we call it a Verifiable Attestation.
This schema can be always retrieved from the cheqd ledger at:
3.2 Verifiable Accreditation
This is a schema for a Verifiable Credential between two DIDs, to accredit the DIDs for specific purposes. The accreditedFor
section of the Accreditation can be modified with specific schemas for AI Agents.
This schema can be always retrieved from the cheqd ledger at:
We suggest that you use the same schemas that we have already made for Verifiable Accreditations and Attestations, although this is not a requirement
3.3 Custom Schemas
Builders can create custom schemas for their AI Agents, or for the accreditations between different organisations in their ecosystems. This is achieved through editing the accreditedFor
section of a Verifiable Attestation above.
For example, the following schema shows how the configuration of an AI Agent can be represented within a schema:
Step 4: Publish your schemas to cheqd as DID-Linked Resources
With the Root DID you created in Step 2, you can create links to your schemas, storing them on-chain in a resolvable format.
You can follow the tutorial here to publish your schemas as DID-Linked Resources. Generally we use the resourceType
of JSONSchemaValidator2020
for JSON schemas written to the ledger.
This will store the schemas securely on the cheqd Network, where they can be fetched using DID URLs.
Step 5: Issue a Root Authorisation for the Trust Chain
The Root Authorisation in trust registries on cheqd is called a rootAuthorisationForTrustChain
. This authorisation contains informartion about the governance framework the AI Agents will operate in, and signifies to trust registry resolvers that they have reached the intended Root.
Authorisations are issued between two DIDs (which may be the same). As such, if you are managing the entire ecosystem, you may need to create multiple DIDs for different roles in the ecosystem. Otherwise, you need to be aware of the DIDs of the organisations you are seeking to authorise.
Generally, the Root Authorisation also contains the schemas and types of credentials that will be issued below in the trust chain.
5.1 Verifiable Authorisation for Trust Chain
Using POST /trust-registry/accreditation/issue
Use the following request format:
"issuerDid"
Yes
The DID of the Issuer of the Accreditation
"subjectDid"
Yes
The DID of the Recipient of the Accreditation
"types"
Yes
The "types" of credential you are authorising for your trust chain
"url"
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
You can use the API below to make this transaction, using the parameter 'authorise'.
Generate and publish a Verifiable Accreditation for a subject DID as a DID Linked resource.
Select the type of accreditation to be issued.
Input fields for the creating a Verifiable Accreditation.
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
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.
["https://schema.org/schema.jsonld","https://veramo.io/contexts/profile/v1"]
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.
["Person"]
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
Possible values: Terms of use can be utilized by an issuer or a holder to communicate the terms under which a verifiable credential was issued.
{"type":"IssuerPolicy","id":"http://example.com/policies/credential/4","profile":"http://example.com/profiles/credential","prohibition":[{"assigner":"https://example.edu/issuers/14","assignee":"AllVerifiers","target":"http://example.edu/credentials/3732","action":["Archival"]}]}
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.
{"type":"ManualRefreshService2018","id":"https://example.edu/refresh/3732"}
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.
{"type":["DocumentVerification"],"id":"https://example.edu/evidence/f2aeec97-fc0d-42bf-8ca7-0548192d4231","verifier":"https://example.edu/issuers/14","evidenceDocument":"DriversLicense","subjectPresence":"Physical","documentPresence":"Physical","licenseNumber":"123AB4567"}
Step 6: Issue your next Accreditation
Depending on how many layers deep you want your trust registry, you now need to issue an accreditationToAccredit
or an accreditationToAttest.
In essence, you need to decide whether you want to accredit a subordinate entity to accredit other organisations (creating a deeper trust chain), or accredit a subordinate entity to issue Credentials to your AI Agent.
6.1 Verifiable Accreditation to Accredit
"issuerDid"
Yes
The DID of the Issuer of the Accreditation
"subjectDid"
Yes
The DID of the Recipient of the Accreditation
"url"
Yes
A schema or multiple schemas that the recipient is accredited to issue
"types"
Yes
The types of credential the subject 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.
"rootAuthorisation"
Yes
A URL or DID URL of the root authorization governing the ecosystem
"credentialStatus"
Optional
An object detailing the status information of the Accreditation
For a trusted ecosystem, these attestations are required to trace the legitimacy of a credential issuer to a root-of-trust.
6.2 Verifiable Accreditation to Attest
If you just want to accredit the subordinate DID to issue credentials to your AI Agent, use a Verifiable Accreditation to Attest.
"issuerDid"
Yes
The DID of the Issuer of the Accreditation
"subjectDid"
Yes
The DID of the Recipient of the Accreditation
"url"
Yes
A schema or multiple schemas that the recipient is accredited to issue
"types"
Yes
The types of credential the subject 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.
"rootAuthorisation"
Yes
A URL or DID URL of the root authorization governing the ecosystem
"credentialStatus"
Optional
An object detailing the status information of the Accreditation
For a trusted ecosystem, these attestations are required to trace the legitimacy of a credential issuer to a root-of-trust.
Core Trust Registry Setup Complete!
Great! Now you have set up the core functionality for your trust registry. Next you will want to issue a Verifiable Attestation from the "trusted issuer" in the Trust Registry to an AI Agent:
Last updated
Was this helpful?