Skip to main content

Enforcing an Ecosystem as a Verifier

This page explains how to enforce ecosystem constraints — such as those required by EUDI — during verification. Once an ecosystem is enforced, Procivis One automatically validates each proof request and its results against that ecosystem's requirements, and rejects anything that does not comply.

For an overview of how ecosystems operate, see Ecosystem Enforcement Overview.

Prerequisites​

The verifying organization must have an ecosystem enabled. See Enabling Ecosystems for instructions.

Enforcing an ecosystem​

To enforce an ecosystem on any given verification, use ecosystem during creation of a proof request.

POST /api/proof-request/v1

{
  {{...}}
  "ecosystem": "EUDI"
}

A successful call returns 201. The ecosystem will be enforced during the when sharing this proof request with a wallet.

If the proof request itself cannot be created due to an ecosystem constraint — for example, EUDI is the ecosystem and you attempt to create the request with a DID instead of a certificate — the call returns 400 instead, with an ecosystemErrors map in data explaining which constraint was breached.

Checking the outcome​

After creating the proof request, call the share endpoint and offer it to a wallet, then poll GET /api/proof-request/v1/{id} to see what happens.

info

See Creating a Proof Request and Sharing a Proof Request for more on the issuance flow, and Proof States as a Verifier for the full state reference.

If the wallet responds and the proof request reaches ACCEPTED, the ecosystem checks passed. If it reaches ERROR instead, that could be because a check failed, or for a reason unrelated to ecosystems entirely.

Whatever the state, if an ecosystem was applied, each presented credential's trustInformation, at proofInputs.<item>.credential.trustInformation, tells you whether its issuer is trusted:

{
  "proofInputs": [
    {
      {{...}},
      "trustInformation": {
        "result": "TRUSTED",
        "name": "EUDI",
        "receivedAt": "2026-09-17T14:19:35.685Z",
        "ecosystemErrors": {
          "EUDI": {
            "result": "TRUSTED",
            "error": {
              "code": "BR_0486",
              "message": "..."
            }
          }
        }
      }
    }
  ]
}

A result of TRUSTED requires that the proof is internally consistent, and that 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.

This resolution is also recorded as an ECOSYSTEMS_RESOLVED history event on the proof request.

Requiring ecosystem enforcement​

Any ecosystem selected for a verifying organization is available for use in verification, but its use is optional. To require every proof request to use an ecosystem, update the verifying organization:

PATCH /api/organisations/v1/{id}

{
  "configuration": {
    "enforceEcosystemAsVerifier": true
  }
}

When this flag is set, every proof request must have an ecosystem assigned. To force all verifications from this organization to use one and only one ecosystem, make sure that selectedEcosystems only contains one ecosystem.