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 — identified by the schema IDs set in pidSchemaIds of your ecosystems configuration. The issuer must be found on the PID Provider trust list.
  • QEAA — auto-detected from the claims on the credential. The issuer (a Qualified Trust Service Provider, or QTSP) must be found on the QEAA Provider trust list.

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.

Biometric user data consent

EUDI Wallets must explicitly inform users whenever a request involves sharing biometric data, such as the portrait on a PID, and must obtain their explicit consent before disclosing it.

To support this, mark the claims that hold biometric data in the requireBiometricDataUserConsent block of your ecosystems configuration. For example, to mark the portrait claim on both SD-JWT VC and mdoc PIDs:

requireBiometricDataUserConsent:
  enabled: true
  schemas:
    - id: urn:eudi:pid:1
      claims:
        - picture
    - id: eu.europa.ec.eudi.pid.1
      claims:
        - portrait

When the wallet processes the presentation definition (GET /api/proof-request/v2/{id}/presentation-definition), every claim in the response includes a requireBiometricDataUserConsent field. It is true for claims matching an entry in schemas and false for all others:

{
  "credentialQueries": {
    "<queryId>": {
      "applicableCredentials": [
        {
          "claims": [
            {
              "requireBiometricDataUserConsent": true,
              ...
            }
          ],
          ...
        }
      ],
      ...
    }
  }
}

The system only marks these claims. It does not block presentation or collect consent itself. Use the flag to tell the user that biometric data is being requested and to get their explicit consent before proceeding with disclosure.

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.