Organisations that must accept EU Digital Identity Wallets, mobile driving licences or other verifiable credentials face a build or buy decision on a stack whose standards only reached final status in 2025. OpenID for Verifiable Presentations 1.0, OpenID for Verifiable Credential Issuance 1.0 and the OpenID4VC High Assurance Interoperability Profile (HAIP) 1.0 are now Final at the OpenID Foundation, Selective Disclosure for JWTs was published as RFC 9901 in November 2025, and implementing regulations on wallet relying party registration and wallet certification were published in the Official Journal on 7 May 2025. This vendor-neutral buyer's guide is written mainly for relying parties choosing a verifier platform to accept wallets, with a shorter section for organisations that will also issue credentials. The standards themselves are explained in the Digital Identity Wallets Guide and the integration work in the Relying Party Integration with Digital Identity Wallets Guide; issuance-led platform selection is covered in more depth in the Verifiable Credentials Platform Buyer's Guide.
Key takeaways
- Start from your obligation and your use cases: whether you must accept the EUDI Wallet, which attributes you need and for which journeys decides the protocol and format scope.
- Insist on the final standards: OpenID4VP 1.0, HAIP 1.0, SD-JWT VC and ISO/IEC 18013-5 mdoc, with evidence from interoperability testing, not draft-era implementations.
- Verification is more than a signature check: trust list handling, status and revocation, device binding, nonce and audience checks must all be in the product and visible in its logs.
- Registration and keys are your risk: relying party access certificate keys and registration certificates must be managed like other high-value machine credentials.
- Data minimisation is a product feature: the platform should make it easy to request only registered attributes and hard to store more than you need.
Define requirements
- Obligation and timing: whether you are a public body or a private relying party in a sector that must accept wallets under Article 5f of the amended eIDAS Regulation, and your target date. See the eIDAS 2.0 and the European Digital Identity Framework Guide.
- Use cases and attributes: onboarding, login, age checks, address proof, qualifications, payments authorisation; for each, the attributes needed and the legal basis to request them.
- Credential types: EUDI person identification data (PID), electronic attestations of attributes, mobile driving licences, sector credentials, your own issued credentials.
- Flows: remote same-device and cross-device web and app flows, browser Digital Credentials API support, and proximity flows at counters or kiosks.
- Jurisdictions and ecosystems: EU Member States you serve, and non-EU schemes such as mDL programmes based on ISO/IEC 18013-5.
- Issuance: whether you will issue credentials yourself, which formats and to which wallets.
- Deployment: SaaS, private cloud or on premises; HSM requirements; data residency; whether an intermediary model (vendor registers as relying party on your behalf) is acceptable.
- Integration: existing CIAM, identity verification and fraud tooling. See the CIAM Buyer's Guide.
Capability areas
| Area | What to look for |
|---|---|
| Presentation protocols | OpenID4VP 1.0 with HAIP 1.0, DCQL queries, signed requests, same-device and cross-device flows, Digital Credentials API in browsers, ISO/IEC 18013-5 for proximity |
| Credential formats | SD-JWT VC with selective disclosure per RFC 9901 and key binding, ISO mdoc with device authentication; clear statement of any format not supported |
| Trust management | Automatic download and validation of Trusted Lists and lists of trusted entities, configurable trust frameworks per ecosystem, alerting on trust anchor changes |
| Verification checks | Issuer signature to a trust anchor, validity period, revocation and status (token status lists), device or key binding, nonce, audience and replay protection, wallet attestation checks where required |
| Relying party registration support | Management of access certificates per relying party instance and registration certificates per intended use, request templates that match registered attributes, expiry and revocation monitoring |
| Key protection | HSM or cloud KMS storage for access certificate and issuer signing keys, rotation, separation of duties, signing logs |
| Data handling | Attribute-level minimisation, configurable retention, deletion on request, no storage of full credentials by default, audit of who saw what |
| Issuance (if needed) | OpenID4VCI 1.0 pre-authorised and authorisation code flows, wallet attestation checks before issuance, status list publication, re-issuance and revocation workflow. See the OpenID for Verifiable Credential Issuance Guide |
| Fraud and assurance | Signals for emulated wallets, failed device binding and replay, integration with fraud tooling. See the Digital Identity Wallet Fraud Risks Guide |
| Operations | SDKs, sandbox with test trust lists and test wallets, monitoring, SLAs, change management as profiles and the ARF evolve |
Evaluation criteria
| Criterion | Illustrative weight | How to evidence it |
|---|---|---|
| Standards conformance and interoperability | 25% | Versions supported, results from interoperability events or conformance tests, live presentations from several wallets in your PoC |
| Verification completeness | 20% | Demonstrated rejection of revoked, expired, replayed and unbound credentials, with logged reasons |
| Trust and certificate management | 15% | Trusted List updates, access and registration certificate lifecycle, HSM integration |
| Privacy and data minimisation | 15% | Request templates, default retention, deletion, data protection documentation |
| Integration and user experience | 10% | Time to integrate one journey, SDK quality, completion rates in usability tests |
| Roadmap and change handling | 10% | How the vendor tracks ARF releases, implementing acts and profile changes; upgrade commitments |
| Commercials | 5% | Pricing metric (verifications, credentials, instances), exit terms |
Weights are illustrative. A bank meeting an acceptance obligation will weight conformance and verification higher; a university issuing diplomas will weight issuance and status management higher.
Questions to ask vendors
- Which exact versions of OpenID4VP, OpenID4VCI and HAIP do you implement, and what changed when they moved from drafts to Final?
- Show us verification failing for a revoked credential, an expired credential, a replayed presentation and a presentation with no valid key binding. What does the log show?
- How do you obtain, validate and update Trusted Lists, and what happens when a trust anchor is withdrawn?
- How do you manage our access certificates and registration certificates, where are the private keys, and who at your company can use them?
- If you act as an intermediary, how is that reflected in our registration, and how do you guarantee deletion of wallet data after passing it to us?
- Which wallets and mDL implementations have you tested against, and can we see the results?
- Do you support the browser Digital Credentials API and proximity presentation, and on which platforms?
- What attributes do you store by default, for how long, and can we turn storage off?
- How quickly do you ship changes required by new ARF versions or implementing acts?
Red flags
- Support claimed for "OpenID4VP" with no version, or only pre-final drafts.
- Verification that checks signatures but not status, device binding or nonce.
- Trusted Lists loaded manually or hard-coded.
- Relying party or issuer keys held in software with no HSM option.
- Default storage of full credentials or all disclosed attributes.
- A proprietary wallet required for your users, presented as the only route.
- No sandbox with test trust lists and test wallets.
- Vague answers on intermediary data deletion and support staff access.
Proof of concept
- Choose two journeys, for example remote onboarding with PID and an age check, and define the minimum attributes for each against your intended registration.
- Set up the platform in a sandbox with test Trusted Lists, test access and registration certificates and HSM-backed keys.
- Run presentations from at least two independent wallet implementations, same-device and cross-device, plus one mdoc proximity flow if relevant.
- Run negative tests: revoked, expired, tampered, replayed and unbound credentials, a request for more attributes than registered, and a withdrawn trust anchor.
- Check logs and data stores: confirm only requested attributes are kept, for the configured period, with an audit trail.
- If issuing, issue a credential via OpenID4VCI to two wallets, revoke it and confirm verifiers see the status change.
- Measure integration effort, completion rates and operational tasks, then compare total cost over three years.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support across customer identity, digital identity wallets, IAM and NHI, including protection of the relying party and issuer keys these platforms depend on. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Digital Identity Wallets Guide · Relying Party Integration with Digital Identity Wallets Guide · OpenID for Verifiable Presentations (OpenID4VP) Guide · EUDI Wallet Architecture and Reference Framework Guide · Wallet Unit Attestation and Device-Bound Keys Guide