OpenID4VP in an EUDI verifier: where the protocol should live

Separate the wallet-facing protocol from the product-facing API

The official EUDI verifier reference implementation exposes a useful architectural split: a verifier-facing API initializes a transaction and retrieves the wallet response, while separate wallet-facing endpoints serve the authorization request and receive the presentation response.

That separation is valuable even if you do not reuse the reference implementation. It stops protocol parameters, request-object handling and wallet response modes from leaking into every feature that needs verified identity data.

Transaction state is part of the verifier

A presentation is not a stateless API call. The verifier creates a request, binds it to nonce and configuration, waits for a wallet response and then validates the response against the original transaction.

The business application should receive a transaction identifier and a small set of states rather than becoming responsible for protocol state.

• Created and awaiting wallet interaction.
• Presented and under validation.
• Verified with normalised claims.
• Rejected or validation failed.
• Cancelled or expired.

DCQL, intended use and registration context belong close to request creation

The current EU verifier reference exposes DCQL-based credential requests and can associate a transaction with an intended-use identifier or a registration certificate. That is a strong signal that request policy belongs in the verifier boundary.

For multi-tenant SaaS, tenant configuration can determine which intended use and claim request is allowed while the protocol engine remains shared.

Production concerns go beyond the reference implementation

The EU repository explicitly says the current verifier endpoint is a development tool and that concerns such as protecting the Verifier API are not solved by the reference version.

A production service therefore still needs authentication, tenant isolation, secret and key management, rate limits, observability, replay protection and a clear retention model for transaction data.

The goal is a stable business contract

If the rest of the product can ask for a verification and receive a normalised verified result, protocol upgrades stay local to the verifier. That is the main architectural payoff.

It also makes it easier to test wallet-specific behaviour separately from the business workflow that consumes verified information.