Skip to content
Turing Space TCS

Credential Lifecycle

Overview

Section titled “Overview”

TCS is more than a credential issuance API — it is a trust anchor and governance layer for verifiable credentials. Protocols like OID4VCI define how to issue credentials, but they do not answer who certifies the format, who defines the schema, or who maintains the trust list. TCS answers all three through its Trust Registry and Schema Registry, which act as governance gates across the entire lifecycle.

A credential in TCS passes through six stages: Register, Define, Issue, Hold, Verify, and Govern. This is a continuous cycle, not a linear pipeline. Governance decisions — trust list updates, schema revisions, issuer revocation — feed back into earlier stages and trigger new cycles.

TCS Credential Lifecycle

Stage 1: Register

Section titled “Stage 1: Register”

Before issuing credentials, an organization registers with the Trust Registry. This establishes the organization as a vetted participant and scopes all subsequent operations to a tenant.

During registration:

  • The organization submits an application and authenticates
  • A tenant is bootstrapped in TCS with isolated configuration
  • API keys are provisioned for authenticating with TCS services
  • The organization creates or imports a DID as its digital identity

Why this matters: Every credential traces back to a registered tenant. Anonymous issuance is not possible.

Security controls: API-key guard, tenant isolation.

Stage 2: Define

Section titled “Stage 2: Define”

Before any credential can be issued, its type must be registered in the Schema Registry. This creates a versioned, machine-readable contract that describes the credential’s structure and claims.

During definition:

  • The credential type is registered with a VCT (Verifiable Credential Type) metadata entry
  • Claims, display properties, and version history are declared
  • The schema becomes discoverable by issuers, verifiers, and wallets via API

Why this matters: Issuance is gated — the Credential Issuer rejects any offer that references an unregistered or deprecated schema. This enforces governance at the format layer, not just the transport layer.

Security controls: Schema governance gate.

Stage 3: Issue

Section titled “Stage 3: Issue”

With a registered tenant and a defined credential type, the organization creates a credential offer containing the claims it wants to certify. TCS signs and delivers the credential using the OID4VCI protocol.

The flow (pre-authorized code, the production path):

  1. The organization’s backend creates a credential offer via the TCS API
  2. The offer is delivered to the holder (via QR code, deep link, or push notification)
  3. The holder’s wallet exchanges the embedded pre-authorized code at the Authorization Server’s /v1/token endpoint for an access token — no PAR, no PKCE, no interactive login
  4. The wallet requests the signed SD-JWT VC from the Credential Issuer’s /credential endpoint with the access token + a proof JWT

The result is a cryptographically signed credential bound to the holder’s DID.

The interactive authorization code flow (PAR + PKCE + hosted login) is on the roadmap; it is not the path used by the production pre-authorized flow above.

Security controls: DPoP token binding (HAIP path), c_nonce proof freshness, signing trust anchor (EdDSA or X.509).

Stage 4: Hold

Section titled “Stage 4: Hold”

The holder stores the credential in their wallet.

  • In non-custodial mode, the credential lives in the holder’s own wallet. TCS does not retain a copy.
  • In custodial mode (with Holder Service), TCS stores the credential on behalf of the holder with wallet-level access controls.

The holder can:

  • View all claims in the credential
  • Choose which claims to disclose in any given presentation (selective disclosure)
  • Present the credential to any number of verifiers
  • Delete the credential at any time

Security controls: Holder DID key control, per-tenant wallet isolation.

Stage 5: Verify

Section titled “Stage 5: Verify”

When a verifier needs to confirm a claim, it creates an OID4VP authorization request specifying which credential type and claims it requires. The holder’s wallet responds with a presentation containing only the disclosed claims.

The verifier checks:

  • Is the credential signature valid? (Authenticity)
  • Has the credential been tampered with? (Integrity)
  • Is the issuer in the Trust Registry? (Trust)
  • Has the credential been revoked? (Status)
  • Is the presenter the rightful holder? (Binding)

All checks happen locally using public key material — without contacting the original issuer.

Security controls: JAR signed request object, DPoP on presentation, signature and revocation checks.

Stage 6: Govern

Section titled “Stage 6: Govern”

Governance is not a final step — it operates continuously alongside all other stages. The Trust Registry and Schema Registry are active governance surfaces that can modify the rules under which credentials are issued and accepted.

Governance actions include:

  • Updating the trust list (adding or revoking issuers and verifiers)
  • Publishing new schema versions or deprecating old ones
  • Revoking individual credentials via revocation lists
  • Maintaining Domain Linkage to bind DID identities to issuer domains

When a governance action occurs, it can trigger a new cycle: a revoked issuer must re-register, an updated schema may require re-issuance, and verifiers must update their policies to reflect the new trust state.

Security controls: Domain Linkage verification, revocation list enforcement.

The complete flow

Section titled “The complete flow”
Rendering diagram...

What’s next

Section titled “What’s next”
  • Trust and Governance — How the Trust Registry and Schema Registry establish and maintain trust
  • Quick Start — Issue your first credential in 5 minutes