Ecosystem Enforcement Reference for Wallets

This page provides a reference of all checks and validations performed when holding with an ecosystem enforced. For instructions on enforcing an ecosystem as a wallet, see Enforcing an Ecosystem as a Wallet.

EUDI

During issuance

When using POST /api/interaction/v1/handle-invitation for an issuance, the system performs the following checks:

• The Access Certificate contained in the issuer metadata must be signed by a trusted Access Certificate provider
• If the request includes a Registration Certificate, this must be signed by a trusted Registration Certificate provider
• If the request does not include a Registration Certificate, the relying party must appear on the National Registry API as specified in the Access Certificate
• The credential offered must match what the issuer is registered to issue

If any of these checks fail, the call returns an error and nothing is issued.

When using POST /api/interaction/v1/issuance-accept, the system performs the following checks:

• For the following types of credentials offered, 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 call returns an error and nothing is issued.

During presentation

When using POST /api/interaction/v1/handle-invitation for a verification, the system performs the following checks:

• The Access Certificate contained in the verifier metadata must be signed by a trusted Access Certificate provider
• If the request includes a Registration Certificate, this must be signed by a trusted Registration Certificate provider
• If the request does not include a Registration Certificate, the relying party must appear on the National Registry API as specified in the Access Certificate
• The request must match the intended use the verifier is registered for

If any of these checks fail, the call returns an error and the interaction stops.

Embedded disclosure policies

Separately, if the credential schema includes an embedded disclosure policy, the wallet evaluates it while processing the presentation definition (GET /api/proof-request/v2/{id}/presentation-definition), before disclosing the credential. This check triggers whenever the schema has a policy configured, independent of whether an ecosystem is enforced on the interaction, and is not yet integrated with ecosystem enforcement.

The check depends on the policy type:

Type	Description
None	No check is performed.
Allow list	Each entry is checked against the relying party's certificates. A dn entry is matched against the DN of the RP's access certificate. An entitlement entry is matched against the entitlements declared in the RP's registration certificate or public API.
Root of trust	The dn is matched against the issuer of the RP's access certificate (or other ancestor CA in the PKI chain in case of multi-level PKI setup), and the serial is matched against the serial number of that certificate.

Unlike the checks above, a policy violation does not block presentation. If a violation is detected, the response includes an embeddedDisclosurePolicyViolation field, and the wallet should surface this to the holder as a warning before they decide whether to proceed with disclosure.

Trust verdicts

A credential or proof request in the wallet either shows TRUSTED in its trustInformation, or has no trustInformation at all. If an ecosystem was enforced during issuance, an issuance that failed trust checks would have been blocked before the credential reached the wallet.

For credentials you hold

For further lookup of issuers:

GET /api/credential/v1/{id}/trust-detail

{
  "ecosystem": "EUDI",
  "issuer": {
    "country": "DE",
    "email": "contact@example-authority.de",
    "identifier": "DE-EXAMPLE-AUTHORITY-001",
    "intermediary": {
      "country": "DE",
      "email": "contact@example-intermediary.de",
      "identifier": "DE-EXAMPLE-INTERMEDIARY-001",
      "name": "Example Registration Intermediary",
      "phone": "+49 30 1112222",
      "website": "https://example-intermediary.de/"
    },
    "isPublicSector": true,
    "name": "Example National ID Authority",
    "phone": "+49 30 1234567",
    "serviceDescription": [
      {
        "de": "Ausstellung von Personalausweisen (PID)",
        "en": "Issuance of national ID (PID) credentials"
      }
    ],
    "supervisoryAuthority": {
      "email": "supervision@example-authority.de",
      "phone": "+49 30 7654321",
      "uri": "https://example-authority.de/supervision"
    },
    "website": "https://example-authority.de/"
  }
}

If no ecosystem was applied to the credential, this endpoint returns an empty object ({}).

For proof requests you're asked to respond to

For further lookup of verifiers:

GET /api/proof-request/v1/{id}/trust-detail

{
  "ecosystem": "EUDI",
  "verifier": {
    "country": "FR",
    "email": "contact@example-retailer.fr",
    "identifier": "FR-EXAMPLE-RETAILER-001",
    "intermediary": {
      "country": "FR",
      "email": "contact@example-intermediary.fr",
      "identifier": "FR-EXAMPLE-INTERMEDIARY-001",
      "name": "Example Registration Intermediary",
      "phone": "+33 1 23456789",
      "website": "https://example-intermediary.fr/"
    },
    "isPublicSector": false,
    "name": "Example Retailer S.A.",
    "phone": "+33 1 98765432",
    "serviceDescription": [
      {
        "fr": "Vérification de l'âge pour l'achat de produits soumis à restriction d'âge",
        "en": "Age verification for age-restricted purchases"
      }
    ],
    "supervisoryAuthority": {
      "email": "supervision@example-authority.fr",
      "phone": "+33 1 11223344",
      "uri": "https://example-authority.fr/supervision"
    },
    "website": "https://example-retailer.fr/"
  }
}

If no ecosystem was applied to the proof request, this endpoint returns an empty object ({}).