#Verifier Integration

Link the Trust Registry to a Verifier2 Service to enable automatic trust verification during credential presentation. This allows the etsi-trust-list policy to resolve issuer certificates without external network calls at verification time.

#Architecture

┌─────────────────────────────────────────────────────────────────┐
│                     Verification Flow                            │
│                                                                  │
│  Credential  ──►  Verifier2  ──►  etsi-trust-list policy        │
│                       │                    │                     │
│                       │ dependency         │ resolves via        │
│                       ▼                    ▼                     │
│              Trust Registry Service  ◄─────┘                     │
│                       │                                          │
│                       │ queries                                  │
│                       ▼                                          │
│                   Loaded Trust Sources (TSL, LoTE)               │
└─────────────────────────────────────────────────────────────────┘

#Prerequisites

1. A Trust Registry Service with at least one trust source loaded (see Setup and Trust Source Management).
2. A Verifier2 Service in the same tenant.

#Link Trust Registry to Verifier2

Add the Trust Registry as a dependency of your Verifier2 service:

curl -X 'POST' \
  'https://{orgID}.enterprise-sandbox.waltid.dev/v1/{verifier2Target}/verifier2-service-api/dependencies/add' \
  -H 'accept: */*' \
  -H 'Authorization: Bearer {yourToken}' \
  -H 'Content-Type: text/plain' \
  -d 'myorg.tenant1.trust-registry'

#Verify the Link

List the Verifier2 dependencies to confirm the Trust Registry is linked:

curl -X 'GET' \
  'https://{orgID}.enterprise-sandbox.waltid.dev/v1/{verifier2Target}/verifier2-service-api/dependencies/list' \
  -H 'accept: application/json' \
  -H 'Authorization: Bearer {yourToken}'

[
  {
    "_id": "myorg.tenant1.trust-registry",
    "type": "trust-registry"
  }
]

#Use the etsi-trust-list Policy

The etsi-trust-list policy is a standard Verifier2 VC policy. You add it to the vc_policies array when creating a verification session — the same way you would add signature or any other policy.

The policy snippet looks like this:

{
  "policy": "etsi-trust-list",
  "expectedEntityType": "PID_PROVIDER",
  "allowStaleSource": false,
  "requireAuthenticated": true
}

Place this inside the policies.vc_policies array of your session creation request body. For a complete walkthrough of creating a verification session — including the full request structure, flow_type, dcql_query, and response fields — see Credential Verification.

#Certificate Chain Construction

The policy sends the complete leaf-first credential chain to the linked Trust Registry. The registry uses certificates stored in loaded trust sources as independent trust anchors and performs PKIX path building.

The credential should contain:

1. the credential-signing leaf certificate;
2. any intermediate certificates required to reach the registered anchor.

Do not include the root trust anchor when the applicable profile prohibits it. OpenID4VC HAIP 1.0, Section 6.1.1 states that the X.509 trust-anchor certificate MUST NOT be included in the SD-JWT VC x5c header. The Trust Registry must contain the anchor certificate itself, not only its SHA-256 fingerprint, so it can construct the certification path.

#Policy Resolution Modes

The etsi-trust-list policy supports three resolution modes. Choose the one that fits your deployment:

If more than one mode is configured, precedence is remote service (trustRegistryUrl), inline sources (trustLists), then the linked Enterprise service.

#1. Linked Service Mode (Recommended)

Uses the Trust Registry you linked in the previous step. The policy discovers and queries it automatically at verification time — no extra configuration needed.

{
  "policy": "etsi-trust-list",
  "expectedEntityType": "PID_PROVIDER"
}

This is the recommended mode for enterprise deployments. Trust lists are pre-loaded into the Trust Registry Service, so verification requires no outbound network calls.

#2. Remote Service Mode

Queries a compatible external Trust Registry API. The policy appends /trust-registry/resolve/certificate-chain to trustRegistryUrl and does not attach an Enterprise bearer token.

{
  "policy": "etsi-trust-list",
  "trustRegistryUrl": "https://trust-registry.example.com",
  "expectedEntityType": "PID_PROVIDER"
}

#3. Inline Mode

Fetches and processes a trust list directly at verification time, without a Trust Registry service. Suitable for testing or simple deployments where operating a dedicated Trust Registry Service is not warranted.

{
  "policy": "etsi-trust-list",
  "trustLists": [
    "https://www.signatur.rtr.at/vertrauensliste.xml"
  ],
  "expectedEntityType": "PID_PROVIDER"
}

With validateSignatures: true, inline mode verifies source signature integrity. Use requireAuthenticated: true together with independently configured signer certificates when the source signer must also be authorized.

#Policy Configuration Options

The following parameters are supported across all resolution modes unless noted otherwise:

#Example Configurations

Strict linked-service mode — entity type enforced, stale sources rejected, and the previously loaded source must be authenticated:

{
  "policy": "etsi-trust-list",
  "expectedEntityType": "PID_PROVIDER",
  "allowStaleSource": false,
  "requireAuthenticated": true
}

The linked Trust Registry must have admitted the source with REQUIRE_AUTHENTICATED; setting requireAuthenticated on the verification policy does not authenticate a source retroactively.

Permissive development mode — useful for controlled testing when trust sources are not independently authenticated:

{
  "policy": "etsi-trust-list",
  "expectedEntityType": "PID_PROVIDER",
  "allowStaleSource": true,
  "requireAuthenticated": false
}

#Verification Result

Once a wallet has responded to the verification request and the session is complete, retrieve the session result using the session info endpoint. The policyResults field contains one entry per applied policy.

For the etsi-trust-list policy, a successful result looks like this:

{
  "policy": "etsi-trust-list",
  "success": true,
  "result": {
    "trusted": true,
    "decision": "TRUSTED",
    "matchedEntity": {
      "entityId": "entity-123",
      "entityType": "PID_PROVIDER",
      "legalName": "Example PID Provider",
      "country": "DE"
    },
    "matchedService": {
      "serviceId": "service-456",
      "serviceType": "http://uri.etsi.org/TrstSvc/Svctype/IdV",
      "status": "GRANTED"
    },
    "matchedSource": {
      "sourceId": "pid-providers",
      "sourceFamily": "LOTE",
      "format": "ETSI_TS_119_602_JSON",
      "displayName": "EU PID Providers"
    },
    "sourceFreshness": "FRESH",
    "authenticity": "AUTHENTICATED"
  }
}

Result fields:

• trusted: Always true for a successful policy result.
• decision: The trust resolution outcome. TRUSTED means the issuer was found in a valid trusted source. STALE_SOURCE means the source was found but is stale — only returned as a success when allowStaleSource: true is set.
• matchedEntity (optional): The entity in the trust source whose certificate matched.
  • entityId: The entity's identifier within the trust source.
  • entityType: The type of the entity, e.g. PID_PROVIDER, WALLET_PROVIDER, ATTESTATION_PROVIDER.
  • legalName: The registered legal name of the entity.
  • country (optional): The country code of the entity, when available.
• matchedService (optional): The specific trust service entry that matched the certificate.
  • serviceId: The service's identifier within the trust source.
  • serviceType: The service type URI as defined in the trust list.
  • status: The service status URI as defined in the trust list.
• matchedSource: The trust source that produced the match.
  • sourceId: The ID of the trust source as registered in the Trust Registry.
  • sourceFamily: The trust list family, e.g. TSL or LOTE.
  • displayName: The human-readable name of the trust source.
• sourceFreshness: Freshness state of the trust source at verification time. Possible values: FRESH, STALE, EXPIRED, UNKNOWN.
• authenticity: Source assurance projection. Possible values: AUTHENTICATED, INTEGRITY_VERIFIED, UNVERIFIED, FAILED, or UNKNOWN.
• warnings (optional): Array of warning strings, present only when the policy succeeded with caveats (e.g. stale source accepted).

#Troubleshooting Verification

• No trust source configured: link a Trust Registry dependency, set trustRegistryUrl, or provide trustLists.
• Trust source is not authenticated: load the source with REQUIRE_AUTHENTICATED and an independently trusted signer certificate, or correct the inline signer configuration.
• Trust source is stale or expired: refresh the source and inspect its nextUpdate value. Enable allowStaleSource only after assessing the risk.
• No valid path: ensure the credential presents the leaf and required intermediates, while the Trust Registry stores the full anchor certificate.