Trust and Governance
Why trust matters
Section titled “Why trust matters”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?
Trust Registry
Section titled “Trust Registry”The Trust Registry is TCS’s root of trust. It maintains a list of registered organizations — issuers and verifiers — that verifiers can resolve and act on.
What it does:
- Registers 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:
- Register — Organization makes one call to the Trust Registry, which creates its tenant, provisions its credential configurations, and returns its first API key. Approval is automatic; there is no review queue
- Provision an identity — Organization creates or imports a DID
- Operate — Organization can now issue and verify credentials through TCS
From that point, every credential the organization issues is linked to its identity in the Trust Registry.
When a verifier receives a credential, it can check the Trust Registry to confirm that the issuer is a registered participant — not an unknown entity.
What the registry tells a verifier: two things, and only two. Whether the organization is listed at all, and which capability flags it holds — the Issuer Role (may issue credentials) and the Verifier Role (may verify presentations). An organization commonly holds both. These are orthogonal capabilities, not ranked standing: the registry confers no badge, grade or level, so there is nothing for a verifier to compare between two listed organizations beyond what each is permitted to do.
Schema Registry
Section titled “Schema Registry”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:
| Category | Examples |
|---|---|
| Identity | Passport, National ID, Driver’s License, Proof of Human |
| Education | University Degree, Academic Transcript, Student ID, Course Completion |
| Professional | Employee Credential, Professional Certification, Medical License |
| Healthcare | Vaccination Certificate, Health Check |
| Financial | Insurance Claim, KYC Credential |
| Access | Access Card, Membership, Event Ticket |
| Humanitarian | Refugee Status, Disability Status |
| Platform | TuringCerts 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.
How trust flows through the system
Section titled “How trust flows through the system”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.
How it all connects
Section titled “How it all connects”
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.
What’s next
Section titled “What’s next”- Standards and Interoperability — The open standards behind TCS
- Trust and Schema Governance Guide — Register your organization and start using schemas