Skip to content

Trust and Governance

A verifiable credential is only useful if the verifier can answer one question: “Can I trust the organization that issued this?”

Without a trust framework, anyone could issue credentials claiming anything. A fraudulent entity could issue fake university degrees or employment certificates that are cryptographically valid but meaningless. The signature proves the credential was not tampered with — but it says nothing about whether the issuer should be believed.

TCS solves this by providing a machine-readable Trust Anchor and Governance Layer. While other platforms provide SDKs and libraries for credential operations, TCS is fundamentally different: it embeds trust and schema governance as core infrastructure — not optional add-ons.

Two governance services form this layer: the Trust Registry and the Schema Registry. Together, they answer the questions that protocols alone cannot: who is trusted to issue? and what can be issued?


The Trust Registry is TCS’s root of trust. It maintains a list of approved organizations — issuers and verifiers — that have been vetted and registered.

What it does:

  • Onboards issuers and verifiers, issues API keys, and manages DID provisioning
  • Creates and manages DIDs (Decentralized Identifiers) for each organization
  • Publishes tenant-scoped DID Configuration documents so external parties can verify domain-to-DID linkage
  • Enforces that only approved organizations can issue credentials through TCS

Tenant-scoped endpoints:

  • Issuer metadata: /.well-known/openid-credential-issuer/:tenant
  • Domain linkage: /.well-known/did-configuration.json/:tenant

The governance model:

  1. Apply — Organization submits an application to join the ecosystem
  2. Review — Application is reviewed and vetted
  3. Approve — Organization is approved as a trusted participant
  4. Provision — API key and DID are issued to the organization
  5. Operate — Organization can now issue and verify credentials through TCS

An organization applies to join the ecosystem, receives approval, and is provisioned with API credentials and a DID. From that point, every credential it issues is linked to its verified identity in the Trust Registry.

When a verifier receives a credential, it can check the Trust Registry to confirm that the issuer is a recognized, approved participant — not an unknown entity.


The Schema Registry defines what credentials look like. It stores standardized credential type definitions (called VCT — Verifiable Credential Types) that specify:

  • Which fields a credential must contain (required claims)
  • Which fields are optional
  • What data types each field uses
  • Which fields support selective disclosure

Why this matters: Without standardized schemas, every issuer would define credentials differently. A university degree credential from one institution might have completely different field names and structures from another. This makes automated verification unreliable.

TCS ships with 28 production-ready credential schemas across 8 categories:

CategoryExamples
IdentityPassport, National ID, Driver’s License, Proof of Human
EducationUniversity Degree, Academic Transcript, Student ID, Course Completion
ProfessionalEmployee Credential, Professional Certification, Medical License
HealthcareVaccination Certificate, Health Check
FinancialInsurance Claim, KYC Credential
AccessAccess Card, Membership, Event Ticket
HumanitarianRefugee Status, Disability Status
PlatformTuringCerts Standard Credential

The Schema Registry publishes and versions these credential metadata contracts. All credential types must be registered and machine-discoverable through it before issuance — enforcing governance at the format layer, not just the transport layer.

Each schema is discoverable through the Schema Registry’s API, so wallets and verifiers can automatically understand the structure of any credential they encounter.


Rendering diagram...

The Trust Registry answers “who can issue?” and the Schema Registry answers “what can be issued?” Together, they form the governance layer that makes verifiable credentials trustworthy at scale — and this layer is what distinguishes TCS from SDK-based toolkits. Trust Registry + Schema Registry are the infrastructure moat.


TCS Overview -- Issuer and Verifier applications connected through TCS Governance Framework

Issuer applications (e.g. Turing Certs, ticketing platforms, identity providers) connect to TCS through the Issuer API. Verifier applications connect through the Verifier API. Both sides interact with the TCS Governance Framework (Trust Registry + Schema Registry) at the center — ensuring that every credential issued is governed and every presentation verified is validated against the same trust and schema rules. Holders receive VCs and present VPs, completing the ecosystem loop.