EUDI Wallet data minimization for relying parties
An EUDI Wallet request should ask for evidence that serves a stated purpose, then process and retain only what the service needs. A wallet presentation can reduce data sharing, but privacy also depends on the verifier's request, credential format, downstream use, and retention choices.
This guide covers the relying-party side of the flow. It describes DLBR's supported request and result behavior; it is implementation guidance, not a legal assessment of a particular service.
Start with the decision, then choose the evidence
Write down the service decision the verification must support. Ask whether it needs an identity attribute, a threshold, or a combination of evidence. Then request only the credential and claims that can answer that question.
For example, an age-gated service may need to know whether a person is over a threshold. If the supported issuer and wallet profile can provide an age predicate, request that predicate rather than a date of birth or a full PID. The EUDI Proof of Age guide shows DLBR's supported mdoc flow using age_over_18.
const session = await id.sessions.create({
credentials: [{
id: "proof-of-age",
format: "mso_mdoc",
issuer_id: "https://issuer.example",
trust_domain: "pub_eaa",
doc_type: "eu.europa.ec.av.1",
namespace: "eu.europa.ec.av.1",
claims: ["age_over_18"],
}],
});The exact claim, credential type, namespace, and trust domain must match the issuer and verifier policy configured for the deployment. A narrower request does not make an unsupported credential profile interoperable.
Treat selective disclosure as format-specific
OID4VP carries requests and presentations; it does not make every credential format disclose data in the same way. SD-JWT and mdoc have different selective-disclosure mechanisms, and some credentials or profiles may not support a requested predicate. Confirm the issuer, wallet, format, and profile before relying on a minimal response.
With DLBR, claims names the claim paths requested for a credential. The verified session result contains only the claims requested by that session's presentation definition. The wallet and credential profile still determine whether the request can be satisfied and exactly what evidence is returned. For nested SD-JWT claims, paths can use numeric array indexes or [] to request the selected claim from every array element; mDOC claims remain flat namespace elements. See SD-JWT vs mdoc for format differences and OID4VP nonce and state validation for transaction binding.
Explain the request and handle user choice
Tell the user why the service needs the requested evidence before starting the wallet interaction. Use a purpose that matches the data request, and provide a clear path when the user declines, the wallet has no matching credential, or verification cannot complete. User approval is part of the wallet interaction; it does not replace the relying party's responsibility to define and communicate an appropriate request.
The EUDI Wallet framework and OID4VP privacy considerations describe purpose communication and least-information request design. Read the applicable profile and rules for the deployment; do not infer legal entitlement from a credential's technical availability.
Minimize data after verification too
Only fetch and use the verified result in the backend component that needs it. DLBR's quickstart documents that requested claims and verification details are deleted after the session's short result-retention window; an application can delete the session earlier after reading the result. Avoid copying claim values into application logs, analytics, support tickets, or webhook payloads unless the service has a documented need and appropriate controls.
const result = await id.sessions.get(session.session_id);
if (result.status === "VERIFIED") {
const ageResult = result.claims?.["proof-of-age"];
// Apply the service decision using the minimum result needed.
}
// Delete as soon as the required result has been consumed.
await id.sessions.delete(session.session_id);Do not treat a verified result as blanket permission to retain or reuse the underlying information. Choose retention based on the service's documented purpose and applicable requirements. The API quickstart describes session result retention and early deletion.
Relying-party review checklist
- Can the service make its decision with a threshold or predicate instead of a direct identifier or source value?
- Does the request name only the credential type and claims needed for that purpose?
- Do the issuer, wallet, credential format, and presentation profile support the requested evidence?
- Does the user receive a clear purpose before presenting data, with a usable decline and failure path?
- Which backend component needs the result, and when can the session be deleted?
- Are logs, analytics, support tooling, and webhooks free of unnecessary claim values and raw wallet payloads?
Continue with the EUDI Wallet overview, the integration checklist, and the EUDI Wallet glossary.