Process for creating a trust chain

1. Create did:cheqd DID for Root TAO

2. Establish root of trust, by:

   1. Associating Root TAO DID with X.509 certificate;

   2. Publishing Root TAO DID as a Well-Known DID;

   3. Associating Root TAO DID with cheqd Validator.

3. Create did:cheqd DIDs for TAOs or TIs within the ecosystem

4. Create body of Verifiable Accreditation, specifying:

   1. The did:cheqd DID of the subject organisation that the Accreditation is being issued to

   2. A UUID as a reservedAttributeId which aligns with the resourceId of the DID-Linked Resource

5. Encode Verifiable Accreditation as a hexidecimal and as a base64 encoded value

6. Compile payload file for writing Verifiable Accreditation as a DID-Linked Resource

7. Publish transaction as a DID-Linked Resource, using the same UUID for the resourceId as the value specified in the reservedAttributeId

Resource Payload File fields

Example payload file

```json
{
  "attribute": {
    "did": "did:cheqd:testnet:098c4f66-b461-4037-9cf0-c5db75b270c6",
    "hash": "bcdb6bc952c8c897ca1e605fce25f82604c76c16d479770014b7b262b93c0250",
    "body": "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImRpZDplYnNpOnpqSFpqSjRTeTdyOTJCeFh6RkdzN3FEI1Q2aVBNVy1rOE80dXdaaWQyOUd3TGUtTmpnNDBFNmpOVDdoZExwSjNaU2cifQ.eyJpYXQiOjE2OTE1OTA3NjgsImp0aSI6InVybjp1dWlkOmZmMzFhZmM4LTFmNGUtNGMxMy04ZjdhLTM0MDQ0ODZlYWRlYSIsIm5iZiI6MTY5MTU5MDc2OCwiZXhwIjoxNzIzMTI2NzY4LCJzdWIiOiJkaWQ6ZWJzaTp6akhaako0U3k3cjkyQnhYekZHczdxRCIsInZjIjp7IkBjb250ZXh0IjpbImh0dHBzOi8vd3d3LnczLm9yZy8yMDE4L2NyZWRlbnRpYWxzL3YxIl0sImlkIjoidXJuOnV1aWQ6ZmYzMWFmYzgtMWY0ZS00YzEzLThmN2EtMzQwNDQ4NmVhZGVhIiwidHlwZSI6WyJWZXJpZmlhYmxlQ3JlZGVudGlhbCIsIlZlcmlmaWFibGVBdHRlc3RhdGlvbiIsIlZlcmlmaWFibGVBY2NyZWRpdGF0aW9uIiwiVmVyaWZpYWJsZUFjY3JlZGl0YXRpb25Ub0F0dGVzdCJdLCJpc3N1ZXIiOiJkaWQ6ZWJzaTp6akhaako0U3k3cjkyQnhYekZHczdxRCIsImlzc3VhbmNlRGF0ZSI6IjIwMjMtMDgtMDlUMTQ6MTk6MjhaIiwiaXNzdWVkIjoiMjAyMy0wOC0wOVQxNDoxOToyOFoiLCJ2YWxpZEZyb20iOiIyMDIzLTA4LTA5VDE0OjE5OjI4WiIsImV4cGlyYXRpb25EYXRlIjoiMjAyNC0wOC0wOFQxNDoxOToyOFoiLCJjcmVkZW50aWFsU3ViamVjdCI6eyJpZCI6ImRpZDplYnNpOnpqSFpqSjRTeTdyOTJCeFh6RkdzN3FEIiwiYWNjcmVkaXRlZEZvciI6W3sic2NoZW1hSWQiOiJodHRwczovL2FwaS1jb25mb3JtYW5jZS5lYnNpLmV1L3RydXN0ZWQtc2NoZW1hcy1yZWdpc3RyeS92My9zY2hlbWFzL3ozTWdVRlVrYjcyMnVxNHgzZHY1eUFKbW5ObXpERmVLNVVDOHg4M1FvZUxKTSIsInR5cGVzIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiVmVyaWZpYWJsZUF0dGVzdGF0aW9uIiwiVmVyaWZpYWJsZUF1dGhvcmlzYXRpb25Gb3JUcnVzdENoYWluIl19XSwicmVzZXJ2ZWRBdHRyaWJ1dGVJZCI6IjRlYzcwN2YxZDMxZjBlOTg5OTZlYzY2MmQ3ZDk4MjA4NzRiNGRkMjNjZGMwM2Y3OGEyYWIxNDgzYzM5NjlmM2EifSwiY3JlZGVudGlhbFNjaGVtYSI6eyJpZCI6Imh0dHBzOi8vYXBpLWNvbmZvcm1hbmNlLmVic2kuZXUvdHJ1c3RlZC1zY2hlbWFzLXJlZ2lzdHJ5L3YzL3NjaGVtYXMvempWRk52YkVCUEFyM2E3MjREdHRpb1pwZ1ptTnI3NUJCdFJ6WnFrN3BrRGUiLCJ0eXBlIjoiRnVsbEpzb25TY2hlbWFWYWxpZGF0b3IyMDIxIn19LCJpc3MiOiJkaWQ6ZWJzaTp6akhaako0U3k3cjkyQnhYekZHczdxRCJ9.o6olFmrYFpWy36N2Jnz1DHKBkAcSt3vN7RzSU-j6HGyhzHVZAEG7W20EtZDw4LVvKE0GzH9burBAdfJkAWR_6w",
  },
  "metadata": {
    "type": "VerifiableAccreditation",
    "issuerType": "RootTAO",
    "tao": "did:cheqd:testnet:098c4f66-b461-4037-9cf0-c5db75b270c6",
    "rootTao": "did:cheqd:testnet:098c4f66-b461-4037-9cf0-c5db75b270c6",
    "revoked": false,
    "encrypted": false
  }
}
```

<todo>

Supported Roots of Trust

cheqd supports two predominant Root of Trust Models.

Well-Known DIDs

X.509 Certificates linked to DIDs

For existing trust frameworks such as eIDAS, organisations need to establish a root of trust using X.509 certificates in traditional "Trusted List" infrastructure. These certificates establish that an organisation is authorised to provide a service under a particular jurisdiction.

Article 22 of the eIDAS Regulation obliges Member States to establish, maintain and publish trusted lists. These lists should include information related to the qualified trust service providers for which they are responsible, and information related to the qualified trust services provided by them. The lists are to be published in a secured manner, electronically signed or sealed in a format suitable for automated processing.

Standard information in an X509 certificate includes:

• Version — The version of X.509 that applies to the certificate.

• Serial number — Serial number assigned by certificate authority to distinguish one certificate from other certificates.

• Algorithm information — The hashing algorithm used by the CA to sign the certificate (SHA-2 in almost all cases).

• Issuer distinguished name — The name of the entity issuing the certificate (usually a certificate authority)

• Validity period of the certificate — The period during which certificate is valid to use.

• Subject distinguished name — The name of the identity the certificate is issued to (individual, organization, domain name, etc.)

• Subject public key information — The public key of the certificate

As such, one method of establishing a root of trust is associating a DID on cheqd with an existing X.509 certificate. This concept has been written on recently, with there being various approaches to achieving this.

As a first iteration of trust infrastructure on cheqd, we suggest that:

1. did:cheqd DIDs can be derived from the same public/private key pair as existing X.509 certificates

2. did:cheqd DIDs can reference X.509 certificates using a serviceEndpoint

3. X.509 certificates can reference did:cheqd DIDs using the "Subject Alternative Name" field within the X.509 certificate.

This will enable Root TAOs to create a reciprocal root of trust across European Trusted Lists for eIDAS compliance, and equally on cheqd.

Decentralised Root of Trust

For ecosystems that do not require a "traditional" root of trust, we can leverage the cheqd network itself to create reputable, "weighted" roots of trust.

For this model, we suggest that "Root TAOs" set up a cheqd Validator on the cheqd Network and include their DID in the "description" field of their Validator. This will tie the reputation and weight of the Validator with the DID itself.

Then, when traversing the trust chain and resolving to the Root of Trust, the validating application can apply logic to validate the "reputation" of the Root TAO, based on the voting power of the Validator within the active set.

cheqd is a purpose-built network for decentralised identity. This documentation site provides technical and product information for all identity features & functionality on the cheqd network.

Integrate with cheqd

cheqd maintains an array of products and packages with varying levels of integration complexity to allow its partners and customers to have a variety of ways of plugging into cheqd's identity functionality. Via these different packages, customers and partners can create cheqd DIDs, DID-Linked Resources, Status Lists, Trust Registries and Schemas, as well as use cheqd's Credential Payments model, with different levels of integration effort and flexibility.

There are three core ways of integrating and building with cheqd:

What functionality does cheqd offer?

cheqd's identity functionality is fully standards compliant, ensuring interoperability and no vendor lock-in. cheqd's tooling and different product offerings offer a variety of building blocks for any Trusted Data Market.

Industry Standard DID Support

If you want to utilise cheqd DIDs or DID-Linked Resources within applications without a specific cheqd integration, you can incorporate a Universal Registrar or Universal Resolver driver to support did:cheqd alongside other commonly adopted DID methods.

Get started with cheqd Studio

cheqd Studio is the easiest route to get started with cheqd's identity functionality, or for testing with very low integration effort. Using simple REST APIs, it is possible to integrate cheqd Studio in a few lines of code.

Under the hood, cheqd Studio utilises the Veramo SDK cheqd Plugin, providing the most feature complete set of functionality and tooling.

If you'd rather build a deeper integration using a Software Development Kit (SDK) or lower level package, we've created a simple diagram to show how our packages are structured below.

Understanding the structure of cheqd's packages

One of cheqd's primary motives is to make itself accessible to the widest set of identity applications possible. To accomplish this, cheqd has built a flexible set of packages and tooling to accommodate its identity capabilities into a broad set of external SDKs and applications.

These can be represented through the visual below:

Get involved

The cheqd Community Slack is our primary chat channel for the open-source community, software developers, and node operators.

Please reach out to us there for discussions, help, and feedback on the project.

🙋 Find us elsewhere

The user is required to Log In to our cheqd Studio portal, select a billing plan and then access their API key to authenticate with our APIs. The API key guards the API from unauthorized access and is required for both testing production environments.

Step 1: Get started with cheqd Studio

Head to our cheqd Studio and click Get Started.

Step 2: Select a Billing plan

You will be able to get started for free by selecting either plan, which includes a Free Trial. cheqd Studio billing uses Stripe as a payments processor and users will need to input their card information to initiate a billing plan.

Step 3: Create your account

cheqd Studio uses a third party service called LogTo to handle user authentication and login. This allows users to create new accounts as well as sign in using their email, Google single sign-on, or Discord login.

Step 3: Create a new API key and authenticate with cheqd Studio APIs

Step 4: Start using cheqd

Get started with our tutorials for cheqd Studio functionality.

Introduction

cheqd Studio is a set of guides, tutorials and APIs to help users establish an end-to-end trusted ecosystem for digital credentials.

Using REST APIs, customers can build cheqd's trust infrastructure into existing applications. All of cheqd’s existing open-source libraries remain available, and cheqd Studio does not necessitate developers to switch their SSI stack in their entirety, but allows them to build into their existing tooling, for example alongside APIs such as the Universal Resolver.

Get started

Features

cheqd Studio directly leverages our Veramo SDK Plugin, making a wide array of features available from launch, including:

Understanding the different modes and client choices

With cheqd Studio, there are multiple ways it can be deployed and hosted to support clients with different requirements.

Option 1: Custodied by cheqd (Custodian Mode)

This mode is the most simple for users, allowing cheqd to custody both Cosmos AND Identity keys in Veramo KMS. This means that manages both ledger-writes and signing identity transactions on behalf of the customer.

To ensure this is highly secure, we have deployed an instance of a Veramo Key Management Store (KMS) which uses a Postgress DB (TypeOrm) to store Cosmos AND identity keys in one encrypted table, so it cannot be read in plaintext. This design allows us to segment different customers' keys securely and efficiently.

We use similar techniques to Password Managers such as 1Password and Bitwarden to ensure that even if the database were to be compromised, the keys would remain encrypted and unusable.

User optionality and toggles:

Within Custodian mode, we also enable clients to toggle

Option 2: Self-custodied (Client-managed mode)

Client-managed mode gives the cheqd Studio user the ability to utilise their own identity keys for signing identity transactions, while still allowing cheqd Studio to manage the CHEQ account keys for writing to the cheqd network. This mode is intended to be used for more production environments where the user signs each identity transaction independently, affording a greater level of security and control to the client.

Architecture

Under the hood, cheqd Studio leverages our Veramo SDK Plugin for its identity functionality. Check out our guide on supported SDKs to understand how cheqd Studio fits together with our other Open Source packages.

Alternatives

Below are a list of alternatives for integrating with cheqd. Each offers a different set of protocols and underlying technical capabilities.