Overview
The Trust Registry Service manages ETSI trust lists for credential verification. It enables verifying whether a credential issuer is listed in an official trust list—such as an EU member state's Trusted Service List (TSL) or an industry-specific trust list.
When linked to a Verifier2 Service, the Trust Registry enables the etsi-trust-list verification policy to match issuer certificates — or, for issuers registered by public key only, issuer public keys — against trust sources already loaded in the registry. That match does not fetch the trust list again. If the credential has no x5c header, the policy first resolves the issuer signing key: did:jwk is self-contained, while other DID methods and HTTPS issuer identifiers require a network call. See Public-Key and DID-Based Issuers.
When linked to a Wallet2 Service, the Trust Registry supplies relying-party certificates used to authenticate signed OpenID4VP Request Objects (x509_hash / x509_san_dns).
The Trust Registry Service is controlled by the trust-registry feature flag. Enable it by adding it to enabledFeatures in your _features.conf.
Key Capabilities
- Standards-based trust list support — Load ETSI TS 119 612 TSL/LoTL XML and ETSI TS 119 602 LoTE JSON/XML.
- Signed-source validation — Verify TSL XML with XMLDSig and LoTE JSON carried in a compact JWS.
- Certificate resolution — Match certificates directly or build a certificate path to a registry-owned trust anchor.
- Public key resolution — Match issuers registered by public key only (ETSI TS 119 602
PublicKeyValues, no certificate) by RFC 7638 SHA-256 JWK thumbprint — the standard way to register DID-based issuers that don't hold an X.509 certificate. - Verifier2 integration — Link to Verifier2 for automatic trust verification during credential presentation. For SD-JWT/JWT VC credentials with no
x5cheader, the linkedetsi-trust-listpolicy resolves the issuer's signing key via DID resolution or HTTPS well-known JWT VC issuer metadata before matching it against the trust list. - Wallet2 integration — Link to Wallet2 so signed Request Objects can authenticate against relying-party identities.
- Multi-tenant isolation — Each organization/tenant gets its own trust registry instance.
Service Dependencies
Other services can use the Trust Registry as a dependency:
- Verifier2 Service — When Verifier2 has the Trust Registry as a dependency, the
etsi-trust-listpolicy automatically uses it for certificate resolution. - Wallet2 Service — When Wallet2 has the Trust Registry as a dependency, signed
x509_hash/x509_san_dnsRequest Objects authenticate againstRELYING_PARTY_PROVIDERidentities unioned with any PEM pins. See Wallet2 Integration.
Supported Trust List Formats
| Format | Standard | Example |
|---|---|---|
| National TSL XML | ETSI TS 119 612 | Austria, Italy |
| EU LoTL XML | ETSI TS 119 612 (EUlistofthelists) | EU List of Trusted Lists |
| LoTE JSON/XML | ETSI TS 119 602 V1.1.1, annex A.1/A.2.1 | Schema-valid ecosystem trust lists |
| Signed LoTE JSON | ETSI TS 119 602 JSON in RFC 7515 compact JWS | LoTE JSON protected by an authenticated source signer |
The service rejects non-standard JSON/XML shapes. LoTE JSON is checked against the ETSI JSON Schema and explicit-scheme LoTE XML against the ETSI XSD before normalization.
The EU LoTL contains pointers to national TSLs, not providers. The service validates and records the LoTL and its pointer count, but does not fetch the referenced TSLs automatically.
Entity Types
Trust lists contain entities classified by their role in the credential ecosystem:
| Entity Type | Description |
|---|---|
PID_PROVIDER | Personal ID credential issuers (mDL, national ID) |
WALLET_PROVIDER | Authorized wallet applications |
ATTESTATION_PROVIDER | Attestation and certificate issuers |
TRUST_SERVICE_PROVIDER | Generic eIDAS trust services |
ACCESS_CERTIFICATE_PROVIDER | Providers of access certificates |
RELYING_PARTY_PROVIDER | Registered relying parties |
OTHER | Ecosystem-specific entity types |
Trust Decision Model
When resolving a certificate, the service returns a rich decision object:
| Decision | Meaning |
|---|---|
TRUSTED | An eligible entity and trusted service matched in an admitted source |
NOT_TRUSTED | No eligible match was found |
STALE_SOURCE | A match was found, but its source has expired |
MULTIPLE_MATCHES | The identity matched more than one entity |
UNSUPPORTED_SOURCE | The requested resolution method or source is unsupported |
PROCESSING_ERROR | The input could not be processed |
UNKNOWN | Unable to determine trust status |
Each decision includes:
- Source assurance — Signature status, signer trust, the applied acceptance policy, and whether the source was admitted (
AUTHENTICATED,INTEGRITY_VERIFIED,UNVERIFIED,FAILED) - Freshness state — Whether the source is current (
FRESH,STALE,EXPIRED) - Matched entity details — Information about the trusted entity and service that matched
Permissions
Trust Registry operations use separate Enterprise permissions:
| Permission | Operations |
|---|---|
ES_TRUST_REGISTRY_MANAGE | Load and refresh trust sources |
ES_TRUST_REGISTRY_READ | List sources, source health, and trusted entities |
ES_TRUST_REGISTRY_RESOLVE | Resolve certificates, chains, fingerprints, public keys, and provider IDs |
Current Operational Limitations
- Source refresh is manual. No background scheduler currently uses
autoRefreshIntervalSeconds. - Loading an EU List of Trusted Lists (LoTL) does not follow its pointers automatically. Load the member-state TSLs you need.
- Certificate revocation checking is outside the Trust Registry source-resolution flow.
Get Started
- Setup — Create the service.
- Trust Source Management — Load, list, monitor, and refresh trust sources.
- Trust Resolution — Resolve certificates and provider identifiers.
- Verifier Integration — Link to Verifier2 for automatic trust verification.
- API Reference — Complete endpoint documentation.