Why the next phase of digital identity depends on what businesses request, trust, and retain
A customer presents a digital credential. The application verifies it. A green check appears.
What, exactly, has the business learned?
That the credential is authentic? That the customer meets a particular requirement? That the information is still current? Or simply that the application successfully processed a supported format?
As digital identity wallets move toward wider use, these distinctions become operational decisions.
On October 29–30, the European Commission plans to host its EUDI Wallet Launchpad 2026 in Brussels, bringing together wallet teams, issuers, service providers, and other ecosystem participants for testing, demonstrations, and workshops. The event is an implementation milestone, not evidence that every wallet or service is already available. European Commission
For businesses preparing to accept digital credentials, the immediate challenge is more specific than adding another login option.
They must decide what they need to know—and design a verification request that answers that question without collecting an entire identity profile.
Start with the decision, not the document
Consider a hypothetical professional learning platform offering discounted courses to people with a current professional qualification.
Its existing process asks applicants to upload a certificate. Staff inspect the document, approve the discount, and retain the upload.
A wallet-based redesign could reproduce that process almost unchanged: request a digital certificate, extract every available field, and store the result.
The exchange would be more digital. The business logic would remain largely untouched.
A better starting point is the decision itself: does this applicant hold a qualifying professional credential that is valid for this offer?
That question helps the team separate necessary evidence from incidental information. The institution issuing the qualification may matter. Its current status may matter. An unrelated address or identifier may not.
The product team should also distinguish this eligibility decision from other tasks. Issuing an invoice, preventing duplicate discounts, and maintaining a customer account may require different information, collected for different reasons.
Combining those purposes into one broad identity request makes implementation convenient, but makes the request harder to explain.
The useful design exercise is to work backward from each decision: what evidence would change the outcome, and why?
A smaller request is a product choice
The European Commission describes selective disclosure as allowing a wallet user to share requested attributes without revealing additional information. Its example is straightforward: sharing a date of birth without also sharing a place of birth. European Commission’s selective disclosure guidance
That capability creates an opportunity. It does not make every request proportionate automatically.
If a service requests every available attribute, selective disclosure alone cannot repair the service’s underlying design.
Teams should therefore treat the requested data as part of the product specification, alongside the interface and acceptance criteria. Each field should have an owner, a purpose, and a reason it is needed at that stage.
For the learning platform, this could mean designing a qualification check separately from the billing form. A customer should not have to disclose everything needed for a later purchase merely to discover whether they qualify for a discount.
The EUDI service-provider guidance reinforces this connection between purpose and request: providers must describe their intended use and requested data during registration, and must not request additional data beyond that specification. European Commission’s service-provider guidance
The broader lesson is practical: decide the scope before connecting the wallet.
Authenticity is not the same as eligibility
An authentic credential is useful evidence. It is not, by itself, a complete business decision.
W3C’s Verifiable Credentials Data Model distinguishes cryptographic verification from the business rules used to decide whether to rely on a credential. It also makes clear that verifiability does not establish the truth of every claim inside it. W3C Verifiable Credentials Data Model
For our hypothetical platform, a correctly signed qualification from an unrelated training provider might not satisfy the discount policy. A genuine credential can be unsuitable for a particular purpose.
The verifier therefore needs an explicit acceptance policy: which issuers are trusted for this claim, which qualifications count, and how the presentation relates to the person requesting the benefit.
These decisions should not be hidden inside a generic “verified” label.
A support team needs to distinguish an unsupported issuer from an invalid credential. A customer needs to understand whether the problem is their eligibility, the evidence supplied, or the service’s ability to evaluate it.
That distinction makes the system easier to operate and its decisions easier to challenge.
Reusable does not mean permanently valid
A qualification may be suspended. A licence may expire. A credential may be revoked after an administrative correction.
A business accepting reusable credentials needs a way to account for these changes.
W3C’s Bitstring Status List specification provides a mechanism for publishing credential status, including suspension and revocation. It is one standards-based approach to this problem, not a claim that every wallet or credential ecosystem uses the same mechanism. W3C Bitstring Status List
The operational question is when the service needs a current answer.
For the learning platform, eligibility at enrolment might be sufficient for one course. A benefit that requires an active professional licence throughout a subscription could call for a different policy.
Teams should define those conditions before launch. They should also decide what happens when a status service cannot be reached: retry, defer the decision, or route the application for review.
An unavailable check should not silently become a successful check.
Reuse should reduce unnecessary repetition for the customer while preserving the checks that the particular decision requires.
Privacy extends beyond the visible attributes
Reducing the fields displayed in a request is only one part of privacy.
The European Data Protection Supervisor’s analysis of digital identity wallets identifies selective disclosure and unlinkability as properties requiring deliberate architectural choices. Sharing fewer attributes does not automatically prevent separate interactions from being correlated. EDPS TechDispatch on Digital Identity Wallets
For a business, this means examining the surrounding workflow as well as the credential.
What goes into application logs? What reaches analytics tools? Can a support export expose information the customer interface never displays?
A narrowly scoped request can still feed an unnecessarily broad internal record.
Retention deserves its own design decision. A team should identify the evidence needed to explain an outcome, satisfy applicable obligations, and handle disputes, then determine the appropriate access controls and retention period.
That is not an argument for deleting records indiscriminately. Some services must collect and retain specific identity information. A yes-or-no result cannot automatically replace those requirements.
The aim is a defensible record, not a default copy of every available field.
Build for the cases that do not pass
A successful demonstration usually shows a supported wallet presenting an accepted credential.
The operational workload often comes from everything else.
Return to the learning platform. One applicant has a valid qualification from an issuer the platform has not assessed. Another has an expired credential. A third cannot complete the wallet interaction.
Those cases should not all produce the same rejection message.
We recommend testing the customer journey around these distinctions before expanding acceptance. Explain which evidence is missing, provide an appropriate next step, and avoid asking customers to disclose more information simply because the normal path failed.
The same discipline should guide internal metrics. Completion rate matters, but it should sit beside measures such as unsupported-credential rates, manual-review volume, and the frequency of unnecessary data requests.
A faster interaction is not necessarily a better one if customers still cannot understand why they were accepted or declined.
The business case for wallet acceptance becomes stronger when it improves both the successful transaction and the handling of exceptions.
Where proof-based identity fits
zkMe’s design philosophy emphasizes privacy-preserving credentials, zero-knowledge processing, and selective disclosure. These ideas are relevant to a broader architectural goal: establishing the facts a service needs while limiting unnecessary exposure of the underlying information. zkMe’s design philosophy
But cryptography cannot choose the right business question.
A proof is useful only when the application understands what it establishes, which assumptions support it, and how the result informs a particular decision. Nor should selective disclosure be treated as a synonym for zero-knowledge proofs; different credential systems can support different disclosure mechanisms.
For builders, the opportunity is to make that relationship explicit.
Instead of designing around a document to collect, design around a claim to evaluate. Then specify the acceptable evidence, the relevant validity conditions, the treatment of exceptions, and the records needed afterward.
That approach makes privacy part of the service’s operating model rather than an assurance attached to the wallet interface.
As digital identity infrastructure develops, the most important question for businesses may be deceptively simple:
What do we need to establish before saying yes?
A well-designed wallet interaction should make that answer clearer—not make it easier to ask for everything.