Skip to content

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.


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.


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.


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)

Section titled “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.

Related schemas: TuringCerts_Standard_KYCCredential, PassportCredential.

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.