EUDI Wallet · Credential verification

Bring EUDI Wallet verification into your product.

Your app asks for a credential, the person's wallet presents it, and ProofingTrust checks it against your policy. Your app gets one clear result. You integrate an API; we run the verifier.

Discuss an integration See how it works

Partner and pilot conversations open

1 · Your app
Asks for a credential
At sign-up, booking or check-in, you decide which attributes you need.
2 · EUDI Wallet
The person consents
A QR code on another device, a button on the same phone, or the browser's Digital Credentials API.
3 · ProofingTrust
Verifying…Verified
- Signature and holder binding
- Issuer trusted by your policy
- Not revoked
- Only the attributes you asked for

4 · Your app

Gets the result

result: valid
reference: booking-123
claims: given_name,
        birthdate

The real sequence of our API. Attributes are delivered once to your backend; by default we keep none of them.

For product teams

Add wallet verification to a product people already use.

We verify the credential; you keep your flow, your interface and your customer relationship. We don't replace your check-in or your onboarding.

Software vendors
Offer EUDI Wallet verification as a module of your platform, without building OpenID4VP, issuer trust and revocation yourself.
Module in your platform
Identity and IAM integrators
Add "sign in with a wallet" behind any OpenID Connect client or identity broker your customers already use.
OpenID Connect
Digital operators
Check one specific attribute, such as identity or age, inside a flow you already run.
One attribute, one flow

Exploring

Hospitality check-in
Mobility and rentals
Travel

Use cases we are researching with partners. Not live products.

Evidence

What we've proven, with dates.

Every row says how it was tested and when. We'd rather show you a row marked Preview than a claim we can't back.

15/15OpenID Foundation conformance test modules passing on every changeOID4VP 1.0 · HAIP · SD-JWT VC and ISO mdoc

0attribute values left in our database or logs after a verification, by defaultChecked by our end-to-end tests

Verified5 Sep 2026
Our verifier passed the hosted OpenID Foundation test plan for OID4VP 1.0 Verifier HAIP (SD-JWT VC). Conformance passed; we have not applied for formal certification.
Public test plan · Open the plan
Verified5 Sep 2026
Registered in the EU test registry for relying parties, with test access and registration certificates.
EU test registry
Verified12 Oct 2026
A real wallet (lissi) received a credential from our issuer and presented it to our verifier.
Real wallet
Verified24 Oct 2026
The OpenID Foundation conformance suite for OID4VP 1.0 verifiers (HAIP profile) passes on every change to our verifier: 15 of 15 test modules, for SD-JWT VC and ISO mdoc.
Official test suite, run automatically
Verified24 Oct 2026
Nothing a person presents is stored by default: our tests read the database and the logs after a verification and find no attribute values.
Automated end-to-end tests · What we keep
PreviewOpen now
Public sandbox: verify the EU test PID held in the EU reference wallet. Not yet completed with that wallet.
Sandbox · Open the sandbox
Exploring—
Wallet-based guest check-in, mobility and rental flows, with software partners.
Research, no live product

Verified tested, with the datePreview built, not yet completed end to endExploring research or conversations

Capabilities

What the verifier does today.

Built on the open standards of the EUDI Wallet ecosystem and tested end to end on every change. Pick a topic.

Open standards

The protocol and the credential formats of the EUDI Wallet ecosystem, as published.

ProtocolOpenID4VP 1.0 with the HAIP profile: signed requests, encrypted responses, DCQL queriesAvailable
FormatsSD-JWT VC, with selective disclosure and key bindingAvailable
FormatsISO mdoc and mDL (ISO/IEC 18013-5)Available

Flows and integration

Every way a wallet can answer, and every way your product can ask.

FlowsQR code across devicesAvailable
FlowsSame device, and the browser Digital Credentials APIAvailable
IntegrationREST API with API keys, OpenID Connect login, signed webhooksAvailable
IntegrationReact SDK, for customersAvailable

Trust and revocation

Only the issuers your policy trusts, and only credentials that are still valid.

TrustIssuers you trust by policy: X.509 chains to your anchors, EU trust lists, did:web, your own issuersAvailable
RevocationToken Status List checked on every presentation, strict by defaultAvailable

Privacy and hosting

What a person presents reaches your backend once. We keep the verdict, not the data.

PrivacyAttributes delivered once to your backend, then erased; optional sealed storage up to 24 hAvailable
HostingRuns on servers in the EU (Milan, Italy). Can be packaged for your own infrastructure: ask usAvailable

Issuance

When you also need to give people a credential, not only check one.

IssuanceIssuer: OpenID4VCI 1.0, SD-JWT VC, pre-authorized code flowAvailable

Available: built, and tested end to end on every change. The technical details, examples and what we keep are in the developer docs.

Integrate

Four ways in, one verifier behind them.

Pick the one that fits your product. Every example comes from our automated end-to-end tests.

Read the developer docs

Preview Try our public sandbox with the EU reference wallet and its test PID. No sign-up.

REST API

From your backend, with an API key.

# 1. Open a session (the API key never goes to a browser)
POST https://api.proofingtrust.xyz/v1/public/sessions
{ "reference": "booking-123" }
→ 201 { "sessionId", "deepLink": "openid4vp://…", "expiresAt" }

# 2. Show the QR or open the wallet, then read the result once
GET https://api.proofingtrust.xyz/v1/public/sessions/<sessionId>
→ { "status": "completed", "result": "valid",
    "reference": "booking-123",
    "credentials": [{ "accepted": true, "claims": { … } }] }

OpenID Connect

"Sign in with a wallet" in any OpenID Connect client.

// Discovery: https://api.proofingtrust.xyz/oidc/<tenantId>/.well-known/openid-configuration
const config = await client.discovery(issuer, "<client_id>")
// Authorization code with PKCE S256; the wallet presents, we verify
const tokens = await client.authorizationCodeGrant(config, callbackUrl, { … })
tokens.claims()  // { sub: "<pairwise>", given_name, family_name, … }

React SDK

A ready-made button for React apps, available to customers.

import { ProofingTrustLoginButton } from '@proofingtrust/react'

<ProofingTrustLoginButton
  clientId="ptc_live_…"
  onLogin={result => sendToYourBackend(result.sessionId)}
/>

Webhooks

Be told when a verification ends, signed as Standard Webhooks.

// verification.completed · verification.failed · session.expired
const event = wh.verify(rawBody, req.headers)  // webhook-signature checked
event.data  // sessionId, policyId, reference, result… never the claims

Pilot

Start with one concrete flow.

A pilot with us is small on purpose: one process, a few attributes and a clear way to decide what comes next.

1
Pick the flow
Where in your product a person would present a credential, which attributes you need and who the wallet holders are.
2
Integrate in a test environment
We set up a policy for that flow, you connect it through the API, OpenID Connect or the SDK, and we test it with test credentials first.
3
Decide together
We review what worked, what your customers would need and whether it makes sense to go further.

Propose a pilotOne flow, with test credentials first.

Contact

Have a use case? Let's map the integration together.

Tell us where in your product a credential would be presented. We reply to every message ourselves.

Or write to contact@proofingtrust.xyz

¿Prefieres hablar en español? Escríbenos en español por este formulario o por correo y te respondemos en español.

Bring EUDI Wallet verification into your product.

How it works

Asks for a credential

The person consents

Verifying…Verified

Gets the result

Add wallet verification to a product people already use.

Software vendors

Identity and IAM integrators

Digital operators