How it works

Metadata shape

VCT Registry hosts JSON documents following the SD-JWT VC type-metadata spec: the credential's vct identifier, a display name and description, claim schema, and versioning metadata including deprecation and superseded_by links.

Resolution endpoint

GET /vct/{id} returns the metadata with content-type application/vc+sd-jwt-vc-metadata+json and a Cache-Control: max-age=300 header. The endpoint is public — verifiers and wallets resolve without authentication.

Versioning

Credential types evolve. The versioning model (URL-embedded semver, on roadmap) lets operators publish a v2 schema, mark v1 as deprecated, and set superseded_by so wallets can surface the new version to users. Outstanding v1 credentials continue to resolve — deprecation doesn't break credentials already in circulation.

Caching

HTTP-layer caching (Cache-Control) at the edge; in-process cache inside verifiers for hot paths. 5-minute TTL balances freshness with load — schemas don't change often, but when they do the cache cycles through quickly.

Storage + admin API

Today: in-memory registry with seeded demo VCTs. Roadmap: Postgres persistence + admin API for CRUD, authorised by operator API keys, with Trust-Registry-style admin UI cross-linking.

Public vs. private surfaces

GET /vct/{id} is public. Admin endpoints are API-key protected. No credential data ever lives in VCT Registry — only type metadata, which is by design public.