ETSI: Scheme Operators

Overview

Procivis One supports the full scheme operator workflow for ETSI TS 119 602 trust lists — creating and configuring trust lists, managing trusted entity entries, and publishing signed lists for consumption by relying parties and wallets. The system handles signing, sequence number management, and republication automatically.

If you are new to ETSI trust lists, see What are ETSI Trust Lists? before continuing.

Configuring

See the ETSI Trust List Configuration Guide.

Publishing a trust list

Creating a trust list is a single API call. You provide the profile type, the signing certificate, and any scheme information that the system cannot derive on its own. The system derives as much as possible from the profile type and signing certificate — including all profile-specific URIs and, where applicable, scheme operator identity.

POST /api/trust-list/v1

{
  "type": "LOTE_PUBLISHER",
  "name": "My Wallet Providers List",
  "role": "EUWalletProvidersList",
  "identifierId": "uuid",
  "params": {
    "schemeOperatorAddress": { ... },
    "schemeInformationUri": [ ... ]
  }
}

Required fields:

• type — the name of the trust list provider instance as defined in your configuration. This identifies which configured provider to use when creating the list. In the example above, the instance is named LOTE_PUBLISHER, but this can be any name you have assigned in your trustListPublisher configuration.
• name — an internal label for this trust list within Procivis One.
• role — the EU profile this list conforms to. The system uses this to derive profile-specific URIs in the published list. See Profile types for accepted values.
• identifierId — the identifier holding the signing certificate for this list. Scheme operator identity in the published list is derived from this certificate.

Optional fields:

• organisationId — required only when not using STS authentication mode.
• keyId — specifies which key to use if the identifier contains multiple keys. If omitted, the system selects automatically.
• certificateId — specifies which certificate to use if the identifier contains multiple certificates. If omitted, the system selects automatically.
• params — scheme information that cannot be derived from the profile type or signing certificate. See Scheme information parameters.

The POST call returns the trust list's ID. Once created, the trust list is immediately available to consumers at /ssi/trust-list/v1/{trustListPublicationId}.

Profile types

Role value	Profile
EUPIDProvidersList	Providers of person identity data
EUWalletProvidersList	Wallet providers
EUWRPACProvidersList	Providers of wallet-relying party access certificates
EUWRPRCProvidersList	Providers of wallet-relying party registration certificates
EUPubEAAProvidersList	Public sector bodies issuing electronic attestations of attributes
EURegistrarsAndRegistersList	Registrars and registers of wallet-relying parties

Scheme information parameters

Use the params object to provide scheme information that the system cannot derive, or to override derived values. The fields map directly to components in the ETSI TS 119 602 data model.

Fields the system derives automatically from the profile type include schemeTerritory, historicalInformationPeriod, and pointersToOtherLoTE. schemeOperatorName may be derived from the signing certificate. All other fields should be provided here if applicable to your scheme.

The most commonly needed fields are:

• schemeOperatorAddress — postal and electronic contact details for the scheme operator. Required for explicit scheme information.
• schemeInformationUri — URI(s) where users can find information about the scheme and retrieve previous list versions.
• schemeName — the formal name of the scheme.
• policyOrLegalNotice — the scheme policy or legal notice text or URI.

Additional fields available in params: schemeOperatorName, schemeTerritory, historicalInformationPeriod, pointersToOtherLoTE, distributionPoints, schemeExtensions.

Managing trust entries

Entries are added to the trust list individually. Each entry represents a trusted entity and at least one service that entity provides. You provide the entity's certificate identifier and any additional information about the entity and its service that the platform cannot derive.

tip

See Certificates for guidance creating certificate identifiers.

Adding an Entry

POST /api/trust-list/v1/{id}/entry

{
  "identifierId": "uuid",
  "params": {
    "entity": {
      "name": [ ... ],
      "tradeName": [ ... ],
      "address": { ... },
      "informationUri": [ ... ]
    },
    "service": {
      "name": [ ... ],
      "supplyPoints": [ ... ],
      "definitionUri": [ ... ]
    }
  }
}

• identifierId — the certificate identifier for the trusted entity. The entity's digital identity in the published list is derived from this certificate.
• params.entity — identifying information about the trusted entity: name, trade name, address, and information URI. Most of these fields are entity-specific and must be provided by the scheme operator.
• params.service — information about the service the entity provides: service name, supply points where the service can be accessed, and definition URIs.

Updating an entry

Send a PATCH request with only the fields you want to update. All other fields remain unchanged.

PATCH /api/trust-list/v1/{id}/entry/{entryId}

{
  "params": {
    "entity": { ... },
    "service": { ... }
  }
}

Removing an entry

DELETE /api/trust-list/v1/{id}/entry/{entryId}

In most EU profiles, removing an entry is how approval is withdrawn — there is no explicit status field, and absence from the list signals that an entity is no longer approved. The published list is updated automatically on the next regeneration. For details on how the Pub-EAA profile handles status differently, see What are ETSI Trust Lists?.

Trust list lifecycle

The platform manages republication automatically. You do not need to trigger republication manually.

On change — whenever an entry is added, updated, or removed, the platform regenerates and re-signs the list immediately. The sequence number is incremented automatically with each new version.

On a schedule — when a consumer requests the public endpoint and the time since the last regeneration exceeds the configured refreshIntervalSeconds, the platform regenerates and re-signs the list before returning it. This ensures the list remains fresh even when no changes have occurred, satisfying the next update obligation defined by ETSI TS 119 602.