The Cheapest Data Protection Is Not Receiving the Data

What a business is actually buying here

Not privacy as a principle. A smaller set of obligations.

Today, verifying a customer usually means receiving their whole identity document. You wanted to know they are over eighteen and resident in a particular country. You now hold their document number, their full date of birth, their place of birth, their address, and their photograph.

Everything in that list is something you must now store correctly, retain for a defined period, produce on request, delete on request, and report if it leaks. You acquired an obligation in exchange for an answer you did not need it for.

Selective disclosure is the mechanism for taking the answer without the rest.

Why it is not just cropping the image

Redaction breaks a signature. That is the whole difficulty.

An identity document is trustworthy because an issuer signed the complete set of fields. Remove a field and the signature no longer verifies, so the ordinary way to prove a document is genuine is to hand over all of it.

Selective disclosure solves that specific problem: the holder reveals some fields, withholds others, and the verifier can still confirm the issuer signed the whole original set. You get the assurance of a signed document while receiving a fraction of one.

The mathematics behind this is nearly forty years old and it is not the interesting part. The interesting part is what it removes from your systems.

What disappears from your obligations

Data you never received cannot leak. It cannot appear in a breach notification, because it was never in the system that was breached.

It cannot be the subject of a deletion request, because there is nothing to delete.

It does not need a retention schedule, a lawful basis, an access-control review, or a line in a processing record.

Each of those is real operational cost, paid every year, on every field, for every customer. The controls you do not need are cheaper than the controls you implement well.

The distinction almost no vendor page makes

There are two mechanisms in common use and they have different privacy properties. We ship both, and telling them apart matters more than either name.

The token-based mechanism hides fields effectively, and its disclosures are linkable across presentations by design. Present the same credential to two verifiers and, if those verifiers compare notes, the presentations can be tied together. That is a property of the mechanism rather than a defect in anyone's implementation.

The signature-based mechanism is what provides unlinkability. Two presentations from the same credential cannot be tied to each other from the presentations alone.

So "we support selective disclosure" answers a narrower question than a buyer usually thinks they asked. If your requirement is that a user cannot be tracked across the businesses they present to, only one of the two delivers it, and that one is the one whose cryptography we have not yet had audited.

What is live, and how to check it without asking us

The token-based path is deployed, not aspirational. Its issuer metadata is public and states the credential format it issues:

curl -s https://capture-api.solidus.network/.well-known/openid-credential-issuer
curl -s -o /dev/null -w '%{http_code}\n' https://capture-api.solidus.network/v1/health

The response advertises the selective-disclosure token format. The second line shows the host is up: the health endpoint returns 200, so a reader can tell a real answer from an unreachable host.

The unlinkable path ships with a runnable demonstration in its published package, which prints both its result and the boundary of what it proves.

What selective disclosure does not do

It does not decide what a verifier asks for. A business can request every field it could previously demand, and many will out of habit. The mechanism enables minimisation; your data-request policy performs it.

It does not reduce what the issuer knows. The party that ran the original check saw the whole document. Selective disclosure limits onward flow rather than original collection.

It does not stop correlation outside the credential. IP addresses, timing, device characteristics, and the email address a customer gives you at signup are all untouched by any of this.

What to ask any vendor

"Which mechanism, and is it linkable across presentations?" The single question that separates the two. A vendor who has not made the distinction on their own page has not made it internally either.

"What is the smallest request your system can make?" Ask them to show you a request for one field. Some products cannot express it.

"Does the issuer still receive a signal when a credential is presented?" Field hiding and issuer blindness are different properties and are often conflated in the same paragraph.

"What has been audited?" For us, none of the cryptography, and the honest answer to that question is a date and a funding condition rather than a reassurance.

Where this leaves a decision

If you are trying to reduce what your systems hold, this is the mechanism that does it, and the saving is in obligations you stop carrying rather than in a feature you can demonstrate to a customer.

That is the trade in front of you, and it is the same trade with every vendor in this space whether or not their page says so.

The audit status of this implementation

The unlinkability implementation described here is unaudited.