How it works

TSP ingestion

Trust Registry ingests the EU Trusted Lists (ETSI TS 119 612) — each member state publishes its Trust Service Providers and the qualified signing keys they operate. On boot and on a schedule, the registry syncs these lists, de-duplicates, and exposes a normalised view: issuer identifier, JWKS URL, authorised credential types, expiry.

Federation resolution

For issuers outside the eIDAS trust list (private sectors, consortia, bilateral relationships), the registry supports OpenID Federation 1.0. Verifiers query /registry/issuers/{id}; the registry returns the issuer's JWKS + trust status, chaining up to a federation root if needed.

Accreditation chain

Each issuer entry carries: accreditation source (eIDAS member state / private federation / self-signed), accreditation date, authorised VCTs, valid-from / valid-until timestamps. Verifiers can enforce policy ("only eIDAS-qualified issuers for this credential type") by reading these fields.

JWKS caching

Verifiers call the registry on every presentation. To avoid per-request load, the registry fronts issuer JWKS with a Redis-backed cache keyed by issuer identifier. TTL tuned per issuer (e.g. 5 minutes for stable issuers, 30 seconds during key rotation). Multi-node-safe — see SSO-659.

Instant revocation

DELETE /registry/admin/issuers/{id} removes an issuer. The next trust query from any verifier returns { trusted: false, reason: "issuer_revoked" }. No long-lived cache; revocations are effective on the next verification.

Audit trail

Every admin action (issuer add, VCT grant, revocation) is persisted with timestamp, actor, and rationale. Query-time audit (which verifier asked for which issuer, when) is available via Prometheus metrics; full per-query logging is optional per deployment.