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. Naming an ecosystem makes it binding: every credential presented against this proof request must resolve as TRUSTED under that ecosystem for the proof request to reach ACCEPTED.

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 ecosystem validation error message.

Omitting ecosystem​

If you omit ecosystem from a proof request, the system runs auto-detection, instead checking every presented credential against every ecosystem available to your organization. In this mode, failure to validate against an ecosystem does not block acceptance. The proof request can still reach ACCEPTED regardless of what those checks find; see Checking the outcome below for how to read the results either way.

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.

When the presentation is trusted​

If the proof request reaches ACCEPTED, and you named an ecosystem, its checks passed. A result of TRUSTED requires two things: the proof is internally consistent, and every credential input resolves to the same ecosystem.

If the proof request reaches ERROR instead, that could be because a named ecosystem's checks failed, or for a reason unrelated to ecosystems entirely.

Reading trustInformation​

Each presented credential's trustInformation, at proofInputs[].trustInformation, tells you what was actually found, whether or not an ecosystem was named:

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

ecosystemErrors gives every ecosystem provider that evaluated this credential and its individual result — most useful when no ecosystem was named, since a credential can be tried against several providers. result reflects whichever provider actually validated it and name references that provider.

Note the naming: entries here use NOT_TRUSTED, while trustInformation.result itself uses UNTRUSTED,

Why results can be UNKNOWN or UNTRUSTED​

Even when every individual credential resolves cleanly, the presentation as a whole can still fail to make sense as trusted:

  • Each credential comes back TRUSTED, but under different ecosystems.
  • Credentials nominally share an ecosystem type, but resolve to different roots of trust.

There is no single field showing this collective judgment — it is a property of how the individual results relate to each other, which you determine by comparing them.

A single credential's own result can also come back UNKNOWN rather than TRUSTED or NOT_TRUSTED, if its 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.

UNTRUSTED at trustInformation.result means the credential was evaluated against an ecosystem and broke at least one of its constraints. The error.message explains which constraint was broken.

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.