Handling Trust Information

The Core can resolve trust information during issuance and verification, and optionally restrict interactions to only trusted entities.

Resolving trust information

When handling issuance offers and verification requests, the system captures any trust information provided and stores it alongside the proof request. This is surfaced in the detail response as trustInformation, which includes the entity's name and a timestamp indicating when the information was received.

To resolve the full trust detail, call:

• Credentials → GET /api/credential/v1/{id}/trust-detail
• Proof requests → GET /api/proof-request/v1/{id}/trust-detail

These endpoints retrieve and resolve the stored trust information at request time. For EUDI issuers, the resolved response includes details such as the issuer's name, contact information, registered services, and supervisory authority.

Restricting interactions to trusted entities

The Core can be configured to block interactions with entities that cannot be verified as trusted. This requires conditions to be met at both the wallet provider and wallet level.

Wallet provider requirements

• The trustEcosystemsEnabled feature flag must be enabled for the wallet provider.

Wallet requirements

• The wallet must be registered with the Wallet Provider and have trustedRpRequired enabled. This is typically configured during onboarding.
• For credential issuance specifically, requestSignedMetadata must be set to true in the issuance protocol configuration — this ensures the issuer's metadata is signed and can be verified against trust registries. See OID4VC configuration.

How trust is evaluated

When all requirements are met, the Core resolves trust information during the interaction and runs the following checks:

• Signatures on any access certificates and registration certificates are verified
• If no registration certificate is present, the national registry API is queried instead
• The registration information is matched against the offer or request to confirm the entity is registered to issue or request the specific data involved
• The certificate and registration authorities — the entities whose signatures were verified above — are checked for presence on their respective trusted lists

If any check fails, the interaction is blocked.

Embedded disclosure policies

When a credential schema includes an embedded disclosure policy, the wallet evaluates it during verification before presenting the credential to a relying party. This happens as part of processing the presentation definition returned by GET /api/proof-request/v1/{id}/presentation-definition.

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, and the serial is matched against the serial number of that certificate.

If a violation is detected, the response includes an embeddedDisclosurePolicyViolation field. The wallet should surface this to the holder as a warning before they decide whether to proceed with disclosure.

For details on configuring embedded disclosure policies on credential schemas, see Embedded Disclosure Policy.