You upload your passport to one service. A few weeks later another service asks for the same photograph, and then another wants it with a selfie. Each organization may have a legitimate verification reason. Yet the combined result is an extraordinary number of copies of a document that was supposed to help establish one person's identity, not populate a succession of unrelated databases.
I do not think the solution is to stop verifying people. Regulated businesses and public institutions have obligations that cannot be wished away. But there is a difference between asking 'is this person eligible?' and asking to keep the person's entire identity document. We have made the second request so routine that the first question is often forgotten.
What may be needed
Is this person above an age threshold? Does this qualification remain valid? Is this professional license current?
What is often retained instead
A document number, photo, date of birth, address or birthplace, plus metadata about the upload and the device. Much of it may be irrelevant to the original check.
The problem is particularly visible during account recovery. An institution may already have verified someone once, yet a lost password or replacement phone triggers another request to upload the same document. Repetition can feel reassuring to the institution, but it may expose the person to the same retention risks while proving little about who controls the new account. A stronger recovery process combines appropriate authentication, fresh evidence and fraud controls rather than treating a familiar image file as a reusable key to identity. The right process will vary by account risk and the legal framework.
A retained copy creates responsibilities long after the initial form is submitted: secure storage, limited access, retention periods, breach response and eventual deletion. If the application does not need every field, collecting them has turned a small verification problem into a larger security obligation. That is where selective disclosure becomes interesting: let a service verify the particular claim it needs rather than receive every detail from which the claim could be inferred.
Proof of a claim is not the same as trust
There is an awkward asymmetry in today's upload process. The individual is expected to trust that every recipient will protect a sensitive file for as long as necessary, while the recipient often knows little about whether the file has already been copied, modified or leaked elsewhere. Repetition may feel like caution, but repeated collection also increases the number of places where a compromise can expose the same document. A better design measures assurance from the quality of the issuer, the validity of the claim and the verification process—not simply from how many high-resolution images an applicant can provide.
The W3C's Verifiable Credentials standard describes a way to represent claims issued by one party, held by another and checked by a verifier. Some cryptographic approaches allow information to be disclosed selectively. 1 A professional licensing authority could, in principle, issue a credential that proves someone's status without asking each relying service to collect a photograph of the original certificate. That is attractive, but the signature is only the beginning.
Who is allowed to issue the credential? What happens when the qualification is revoked? How recently must the status have been checked? Is a verifier legally allowed to accept that evidence for the decision it is making? A cryptographically intact claim from an untrusted issuer is still untrusted. A trusted claim that has expired may no longer be useful. Standards can describe the evidence; institutions still need a governance model.
What makes portability valuable is not that every institution must accept every claim. It is that the person can present a narrowly defined, authentic assertion without having to persuade each recipient to trust an arbitrary scan. The institution still decides what level of assurance it needs and which issuers are acceptable. That distinction matters because the worst version of a credential ecosystem would simply replace uploaded PDFs with a collection of opaque badges whose issuers no one understands. Trust is a policy decision informed by evidence, not something cryptography manufactures on its own.
Revocation is particularly awkward. A credential can have been valid when issued and still be unacceptable today. Checking an online registry every time may reveal where and when someone used the credential. Never checking makes the verification stale. Short-lived credentials, status mechanisms and privacy-preserving checks offer different compromises among availability, freshness and surveillance risk. The right answer will not be identical for a library card and a high-risk financial account.
Even a tiny disclosure can leave a long trail
Suppose a proof reveals only that someone is an adult. The transaction may still expose a stable identifier, the issuing institution, timestamp, device information or a signature value that several services can correlate. If those markers follow someone from one verifier to another, minimal document fields have not guaranteed minimal tracking. The W3C specification explicitly discusses correlation through identifiers, signatures and metadata. 1
Consider how quickly a well-meant identifier can become infrastructure for tracking. If every verifier records the same wallet address or credential identifier, unrelated interactions can be connected even when the attribute being proved is harmless. Privacy-preserving presentations attempt to reduce that risk, but their effectiveness depends on implementation choices, key handling and what surrounding services log. The data protection review must examine the entire exchange, including retries and support tickets. Otherwise selective disclosure becomes a narrow improvement surrounded by systems that still collect more information than they need.
Purpose limitation should be understandable to the person proving the claim. A well-designed consent screen would identify who is asking, what assertion they need, how long it remains valid and whether a result will be retained. A person should not have to decipher an entire technical credential package to know which information is being shared. Equally, the verifier should receive evidence that fits a well-defined purpose, rather than a vague 'identity verified' flag whose meaning changes from service to service. Usability and privacy are part of the protocol experience.
This is why privacy engineering cannot stop at the wallet screen. Logging, analytics, recovery, fraud detection, network requests and support workflows need the same scrutiny. Do two unrelated businesses get a reusable identifier? Can the issuer tell every time the credential is presented? Can a captured presentation be replayed? A system that passes the cryptographic validation test may still fail the human privacy test.
The most useful change may be asking for less
Recovery also needs meaningful due process. People will have legitimate claims rejected because of stale records, mismatched names or an unavailable issuer. They should be able to learn the reason for failure, correct mistakes with the responsible authority and complete essential transactions through an appropriate alternative where permitted. Designing only for the technically successful case is likely to shift the most vulnerable users back into slow manual queues. An identity architecture should not be called inclusive simply because the successful demonstration takes fewer seconds.
An institution considering portable credentials should start with a narrow class of claims that it can validate properly. Establish who issues them, which verifier trusts them, how mistakes are corrected and how status changes are handled. Then work outward. A universal identity solution that cannot recover from a lost device or a disputed claim is much less useful than a smaller solution that people can rely on.
There is also an incentive problem. Verifiers accustomed to keeping scanned files need a reason, an approved policy and a credible audit trail before changing their process. Legal clarity, liability and staff procedures can be harder to agree on than the underlying cryptography. Identity infrastructure succeeds when the receiving institutions actually accept the proof, not when a demo shows two phones exchanging tokens.
This requires careful thinking about failure recovery, not just successful presentations. What happens if an issuer corrects a record after a verifier has acted on it? Can an applicant contest a refusal, and can the institution explain which claim failed? If a credential wallet is inaccessible, who can re-establish control without exposing the person to account takeover? A service that handles only the happy path will push complex cases back into manual document collection, recreating the very duplication the new system promised to remove. The exception path determines whether the architecture is genuinely usable.
The question is not how quickly someone can upload the same document again. It is whether this service needed a copy in the first place.
Finally, organizations should measure the outcome that matters: how many unnecessary sensitive-document copies were avoided without weakening the required checks? Track retention, dispute resolution, fraud, failed verification and the time it takes to revoke a compromised credential. If a new system adds a wallet but every relying service still keeps passport photographs 'just in case,' the original problem has not been solved. Less collection is a deliberate institutional choice that technology can make possible, but policy and incentives must carry it the rest of the way.
That is the future of identity infrastructure I would find most useful: fewer unnecessary copies, clearer evidence, meaningful revocation and a genuine alternative for people who cannot use the ideal digital path. The best improvement may be one the user never sees: a form that does not ask for the document at all.
Sources and further reading
