Skip to main content

Ecosystem Enforcement Reference for Verifiers

This page provides a reference of all checks and validations performed when verifying with an ecosystem enforced. For instructions on enforcing an ecosystem during verification, see Enforcing an Ecosystem as a Verifier.

EUDI​

Before verification​

When you create a proof request with EUDI ecosystem enforced, the system performs the following checks:

  • Verifying identifier (verifier) must be a certificate
  • Verification protocol must be OpenID4VP 1.0
  • Schema must use SD-JWT VC and/or ISO mdoc as the credential format
  • If the verifying identifier contains a Registration Certificate (found in trustInformation of identifier), the proof schema being used must match the intended use in this certificate

If any of these checks fail, the call to create a proof request returns an error.

During verification​

The system performs the following checks:

  • For the following types of credentials presented, the issuer must be trusted:
    • PID (as determined by the schema IDs set in pidSchemaIds of your ecosystems configuration)
    • QEAA (auto-detected from the claims on the credential)

If any of these checks fail, the presentation is rejected.

Trust verdicts​

Each presented credential carries its own trustInformation, at proofInputs.<item>.credential.trustInformation, containing a result and the issuer's name. No further issuer detail is currently available to verifiers.

A result of TRUSTED requires two things: the proof is internally consistent, and every credential input resolves to the same ecosystem.

UNKNOWN currently occurs in a few situations:

  • An issuer validly signs a non-PID credential without their Access Certificate. This is permitted under the EUDI ARF, but leaves no way to look up validated metadata about that issuer.
  • A proof includes credentials from genuinely different ecosystems (for example, one EUDI credential alongside a future swiyu credential).
  • A proof includes multiple credentials that nominally share an ecosystem type but resolve to different roots of trust.

None of these cross-input or under-specified cases are precisely defined as trusted or untrusted at this stage — trust is deliberately narrow right now, and UNKNOWN is effectively a placeholder for gaps in the ARF and EUDI more broadly that later rulebooks are expected to close.

UNTRUSTED is a legacy result from proof requests created before ecosystem enforcement existed. It should not appear on new proof requests.