Use Cases

TCS handles the full credential lifecycle across industries. The following scenarios illustrate how organizations integrate with TCS to issue, hold, and verify credentials using the OID4VCI pre-authorized code flow.

Enterprise Employee Credentials

An HR department issues verifiable employee credentials through TCS. Employees store these credentials in their wallets and present them to third parties — building access systems, partner companies, or government agencies — without HR involvement for each verification request.

With selective disclosure, an employee can prove their position and department to a partner company without revealing their employee ID number or start date.

Relevant schemas: EmployeeCredential, AccessCardCredential

Rendering diagram...

Key benefit: Once issued, the credential lives in the employee’s wallet. Verification happens instantly without contacting the issuing organization. The employee controls exactly which claims are shared through selective disclosure.

Academic Credentials

A university issues degree and transcript credentials to graduates through TCS. When a graduate applies for a job, the employer’s verification system can instantly validate the credential — no phone calls to the registrar, no waiting for sealed transcripts.

The same flow supports student IDs for campus services and awards for scholarship applications.

Relevant schemas: UniversityDegreeCredential, AcademicTranscriptCredential, StudentIDCredential

Rendering diagram...

Key benefit: Instant verification replaces manual transcript requests that can take days or weeks. The university issues once; the graduate presents to any number of employers or institutions without re-contacting the university.

KYC/AML Compliance

A KYC provider verifies a customer’s identity and issues a verifiable credential through TCS. The customer can then present this credential to multiple financial institutions — banks, exchanges, insurance companies — without repeating the full identity verification process each time.

With selective disclosure, the customer can prove their identity verification status to a service provider while only sharing the minimum required fields (e.g., nationality and date of birth without revealing the full document number).

Relevant schemas: TuringCerts_Standard_KYCCredential, PassportCredential, IdentityCardCredential

Rendering diagram...

Key benefit: Reduces repeated KYC checks across institutions. The customer verifies once and reuses the credential, while each institution can trust the verification because TCS provides cryptographic proof tied to the original KYC provider’s identity in the Trust Registry.

Verifier-First — Bank Customer Onboarding (KYC reuse)

This scenario is told from the Verifier’s point of view: a bank needs to onboard a new customer and accept a KYC credential issued by a registered upstream KYC provider, without rebuilding its own OID4VP / SD-JWT verification stack. (For business onboarding, the same flow applies — the credential schema covers customer-due-diligence claims; entity-only schemas are not yet shipped.)

Key services involved: Verifier Service, Trust Registry, Schema Registry.

Rendering diagram...

What the Bank does: two API calls — one to create the request, one to poll the result. No SD-JWT parsing, no DCQL implementation, no DID resolution, no signature validation, no Trust Registry lookup in the bank’s own code. The Verifier Service does all of it and returns a structured result.

Key benefit: Compresses the verifier-side integration to a CRUD shape. The bank’s risk and compliance team review the result of a verified presentation; they don’t audit the SD-JWT parser. The Trust Registry guarantees the KYC provider is vetted (per the deployment’s governance model — see Trust & Governance). Cross-institution trust without bilateral integration.

AI Agent Identity Verification

As organizations delegate real work to AI agents — procurement, scheduling, customer operations, transactions — the counterparty’s first question shifts from “who is this user?” to “whose authority does this agent act under?” A system prompt or a self-description can’t answer that. A verifiable credential can.

In the IHV model, an agent can take either non-issuer role:

Agent as Holder — an organization issues a credential to its agent the same way it issues one to an employee: a schema registered in the Schema Registry, claims describing the delegating organization and scope of authority. The agent presents it programmatically — there is no human wallet UI in the loop.
Agent as Verifier — an agent that needs to screen its counterparty makes the same two API calls as the bank onboarding flow above: create the request, poll the result. Omitting redirect_uri keeps the flow fully headless (see Verifier · Verify Credential).

The exchange is standard OID4VP — nothing agent-specific is required on the wire:

Rendering diagram...

What the agent does: the same two API calls as any backend verifier. Its decision input is a structured verdict — the proven claims, the issuer’s identity, and the issuer’s Trust Registry status — instead of unverifiable self-description.

Key benefit: Autonomous systems need trust decisions they can act on — and that a human can audit afterward. A cryptographic verification result gives both: a deterministic “proceed / don’t proceed” basis for the agent, and a verifiable record of who issued the credential, whether the issuer is registered, and which claims were proven for whoever reviews the log. The same property works in reverse: a credential held by an agent gives its counterparties a verifiable answer to “who does this agent act for?”

No agent-specific schema ships today — delegation credentials follow the same custom-schema registration path as any other credential type (see Trust & Schema Governance).

What’s Next

Quick Start — Issue your first credential in 5 minutes
Standards and Interoperability — The open standards behind TCS