ETSI Trust Lists

Sphereon supports two separate ETSI trust profiles. They are not interchangeable registries. Enterprise deployments refresh external material in the platform service and expose validated local snapshots to verifier services.

Standards and role matrix

Standard and source	Authorized role	Format	Trust boundary
ETSI TS 119 612 EU List of Trusted Lists and referenced national Trusted Lists	QEAA Provider only	Signed XML	A valid QEAA issuance service is derived from a validated local LoTL snapshot.
ETSI TS 119 612 custom LoTL and referenced national Trusted Lists	QEAA Provider only	Signed XML	The source uses explicit HTTPS configuration and pinned signer or pivot references.
ETSI TS 119 602 LoTE	PID Provider	Signed JSON with JAdES	The logical LoTE profile and country-qualified provider identity must match the trust request.
ETSI TS 119 602 LoTE	Wallet Provider	Signed JSON with JAdES	The logical LoTE profile and country-qualified provider identity must match the trust request.
ETSI TS 119 602 LoTE	PuB-EAA Provider	Signed JSON with JAdES	This role never authorizes a QEAA decision.
ETSI TS 119 602 LoTE	Access CA	Signed JSON with JAdES	Access CA is an issuance role in this profile, not a generic relying-party role.
ETSI TS 119 602 LoTE	Registration Certificate Provider	Signed JSON with JAdES	This role uses the WRPRC profile. It is not the EU registrars or Register service type.

There is no cross-profile or cross-territory fallback. A TS 119 612 QEAA entry cannot satisfy a TS 119 602 provider request. A TS 119 602 PuB-EAA entry cannot satisfy a QEAA request. A direct trust anchor does not bypass a registry-qualified role decision. Revocation-only services do not establish issuer trust.

TS 119 612 LoTL management

The EU source is a fixed per-domain singleton. Its product-owned URL is https://ec.europa.eu/tools/lotl/eu-lotl.xml, its format is application/xml, its scheme identity is the EU List of Trusted Lists identity, and its signer or pivot bootstrap is product-controlled. The Trust Domain API exposes only its enabled flag.

Custom sources are tenant-domain resources. A custom source requires an HTTPS URL, a format, a scheme identity, and signer anchor identifiers that belong to the same trust domain. Changing any of these values creates a new candidate revision. The current valid revision remains active until the candidate has been validated and activated.

The platform validates the exact source artifact against configured signer or pivot roots, sequence rules, URL and egress policy, XML signature rules, and signed freshness. Embedded x5c material cannot establish its own authority. A validated artifact is stored as an immutable snapshot with its digest, sequence, signed issue time, signed NextUpdate, and derived QEAA entries.

Trust-source API

The API uses the existing /api/trust-domain/v1 base and keeps the specification version at 0.1.0.

Method and path	Purpose	Concurrency
GET /domains/{domainId}/trust-sources	List EU and custom source records in the {items:[...]} envelope.	None.
PUT /domains/{domainId}/trust-sources/eu	Create the EU singleton or change only enabled.	Requires If-Match.
PUT /domains/{domainId}/trust-sources/{sourceId}	Create or replace a custom candidate revision.	Requires If-Match.
GET /domains/{domainId}/trust-sources/{sourceId}/revisions	List immutable revisions in the {items:[...]} envelope.	None.
POST /domains/{domainId}/trust-sources/{sourceId}/revisions/{revision}/validate	Validate and persist a candidate snapshot.	Requires If-Match.
POST /domains/{domainId}/trust-sources/{sourceId}/revisions/{revision}/activate	Activate one exact validated revision and snapshot.	Requires If-Match.
POST /domains/{domainId}/trust-sources/{sourceId}/refresh	Queue a platform-owned refresh and return 202.	Uses the dedicated refresh permission.
GET /domains/{domainId}/trust-sources/{sourceId}/snapshot	Read the immutable active local snapshot.	None.
GET /domains/{domainId}/trust-sources/{sourceId}/derived-entries	List normalized QEAA entries in the {items:[...]} envelope.	None.
GET /domains/{domainId}/trust-sources/{sourceId}/refresh-attempts	List refresh attempts and diagnostics in the {items:[...]} envelope.	None.
GET /domains/{domainId}/trust-sources/{sourceId}/diagnostics	Read runtime state and non-sensitive diagnostics.	None.

Source management and activation are separate permissions. Mutations return a strong ETag. Missing If-Match is a 428 PRECONDITION_REQUIRED response. A stale value is a 412 PRECONDITION_FAILED response.

Custom source example

Use the externally hosted test LoTL URL and signer anchor references supplied by the accepted deployment configuration. Do not put a private key, secret, or guessed URL in the request.

PUT /api/trust-domain/v1/domains/trust-domain-eu-wallet/trust-sources/webuild-test-lotl
If-Match: "source:webuild-test-lotl:1"
Content-Type: application/json

{
  "url": "https://<approved-we-build-host>/<path-to-test-lotl>",
  "format": "application/xml",
  "schemeIdentity": "<accepted-we-build-scheme-identity>",
  "signerAnchorIds": ["<accepted-we-build-signer-anchor-id>"],
  "egressPolicy": {
    "allowedHosts": ["<approved-we-build-host>"],
    "maxArtifactBytes": 10485760
  },
  "enabled": true
}

The response is a TrustSourceRevision with a new revision number. It is not active until validation and activation succeed.

Refresh and expiry behavior

Refresh runs in the platform service. It follows only configured, allowed external URLs and stores the resulting immutable artifact and normalized entries. Verifier services read the local snapshot and do not fetch an EU LoTL, a national Trusted List, or another external trust URL during a presentation.

The runtime state is one of DRAFT, VALIDATED, ACTIVE, DEGRADED, EXPIRED, or DISABLED. DEGRADED means that the previous snapshot is still within its signed NextUpdate. EXPIRED means that the signed freshness window has ended and no entry from that snapshot is usable. A refresh failure never makes an expired snapshot trusted again.

TS 119 602 LoTE management

Each domain can contain logical LoTE resources. A logical LoTE has one editable draft and immutable published versions. The supported profiles are exactly these five values:

Profile	LoTE type	Required issuance service type
PID_PROVIDER	http://uri.etsi.org/19602/LoTEType/EUPIDProvidersList	http://uri.etsi.org/19602/SvcType/PID/Issuance
WALLET_PROVIDER	http://uri.etsi.org/19602/LoTEType/EUWalletProvidersList	http://uri.etsi.org/19602/SvcType/WalletSolution/Issuance
PUB_EAA_PROVIDER	http://uri.etsi.org/19602/LoTEType/EUPubEAAProvidersList	http://uri.etsi.org/19602/SvcType/PubEAA/Issuance
ACCESS_CA	http://uri.etsi.org/19602/LoTEType/EUWRPACProvidersList	http://uri.etsi.org/19602/SvcType/WRPAC/Issuance
REGISTRATION_CERTIFICATE_PROVIDER	http://uri.etsi.org/19602/LoTEType/EUWRPRCProvidersList	http://uri.etsi.org/19602/SvcType/WRPRC/Issuance

The EURegistrarsAndRegistersList type and the Register service type are not the Registration Certificate Provider profile. QEAA is not a TS 119 602 profile.

Draft and publication lifecycle

Draft provider mutations, validation, and publication use the draft ETag returned by the previous read. The service validates the profile, country-qualified provider identity, exact issuance service type, exact NOTIFIED service status, certificate data, and signed validity requirements. A published version stores the exact JSON payload bytes, exact JAdES artifact bytes, signer key reference, certificate-chain references, verification trust-anchor references, publication receipt, sequence number, and signed nextUpdate.

The signing key is an opaque reference to a non-exportable KMS key. The API never accepts private key material. Publication can use the EDK-hosted store, S3, or Azure Blob through the existing publication adapters and an opaque secret reference. The service independently verifies the signed artifact before atomically publishing it. The sequence increments only after successful publication.

POST /api/trust-domain/v1/domains/trust-domain-eu-wallet/lotes/eu-pid-providers/publish
If-Match: "draft:eu-pid-providers:7"
Content-Type: application/json

{
  "signingKeyReference": "<non-exportable-kms-key-reference>",
  "publication": "EDK_HOSTED",
  "publicationSecretReference": null,
  "signingAlgorithm": "ES256",
  "signingCertificateChainReferences": ["<signing-certificate-chain-reference>"],
  "verificationTrustAnchorReferences": ["<lote-signer-trust-anchor-reference>"]
}

The response is 201 Created with an immutable LoTEPublishedVersion and a new ETag. It includes validFrom and nextUpdate. Once published, the version cannot be edited or replaced. Later edits apply to the editable draft and require a later publication.

EUDI TS2 provider-management routes

The provider-management methods are available under each logical LoTE:

GET    /api/trust-domain/v1/domains/{domainId}/lotes/{loteId}/v1/providers
POST   /api/trust-domain/v1/domains/{domainId}/lotes/{loteId}/v1/{country}/providers
GET    /api/trust-domain/v1/domains/{domainId}/lotes/{loteId}/v1/{country}/providers/{providerId}
PUT    /api/trust-domain/v1/domains/{domainId}/lotes/{loteId}/v1/{country}/providers/{providerId}
DELETE /api/trust-domain/v1/domains/{domainId}/lotes/{loteId}/v1/{country}/providers/{providerId}

The list response is { "providers": [...] }. Provider create, replace, and delete use If-Match. The same providerId may appear in two countries because the effective identity is (country, providerId). A provider is trusted only when the active published LoTE profile, country, service type, service status, and signed validity all match the request.

Signature and status rules

TS 119 612 artifacts use the configured XML or XAdES trust roots and the exact QEAA issuance service type http://uri.etsi.org/TrstSvc/Svctype/EAA/Q. A service that is revoked, withdrawn, suspended, unknown, or outside its validity window is not usable trust. National-level status does not silently become EU-wide trust.

TS 119 602 artifacts use exact JSON bytes and JAdES verification. The five profile-specific issuance service types and the NOTIFIED service status are required by the current LoTE lifecycle. A revocation-only service, an unknown status, an expired publication, or an ambiguous active publication produces a fail-closed decision.

IDK library boundary

The IDK ETSI parser and validator remain available for library-level processing. Enterprise trust decisions must use the Trust Domain API and its platform-owned local snapshots. Signature verification must remain enabled in production, and configured signer roots must be supplied. Do not disable signature verification or treat embedded certificate material as a trust bootstrap.