Data Minimisation From the Holder's Side, Where Almost Every Lever Belongs to Somebody Else

Nothing on this page is legal advice and we make no compliance claim.

The principle is usually explained from the side of whoever collects data. This page takes the other side, because a holder reading about minimisation reasonably wants to know which parts of it they control. The answer is uncomfortable.

The three levers, and who holds each

What you hold. Accepting a credential or declining it.

What you present. Choosing which held credential answers a request.

How finely you can reveal. Whether you can disclose one field without its neighbours.

Those look like three decisions a holder makes. Only the first is really yours, and even that one is thinner than it looks.

Lever one: what you hold. Partly yours

You can decline an offer, and nobody can put a credential in your wallet without you accepting it.

But you cannot negotiate its contents. An issuer offers what it offers, and the choice is take it or leave it. If a credential carries more than the purpose you want it for, your only minimising move is to refuse the whole thing.

And in this wallet, holding is thin anyway: it keeps a catalogue rather than the credentials, so what is retained is the fact you hold something and its type. That is minimal by accident of an unbuilt feature, not by design, and it would be dishonest to bank it as a privacy property.

Lever two: what you present. Not yours here

This wallet cannot present at all. The share control produces an unsigned summary that says so in its own words, and the deciding happens on the verifier's side in a conversation the wallet is not part of.

So the lever most people picture when they hear minimisation, choosing what to show, does not exist here yet.

Lever three: how finely you can reveal. Never yours

This is the one worth understanding, because it is invisible and permanent.

The disclosure frame is built at issuance from the paths the issuer listed, and the code is explicit that nested objects are not automatically expanded: a caller wanting disclosure inside a nested object must pass explicit paths.

So if your address was issued as a nested object and nobody enumerated its parts, revealing your city means revealing your street. No wallet, no verifier and no later decision can undo that. The granularity was decided before you had an opinion.

A control makes this specific rather than a general property of signing: CONTROL that makes this specific rather than a general property of signing: the same issuing function writes three fields unconditionally and three conditionally, so the granularity decision belongs to those fields rather than to how the function happens to be written.

What is already built, because absences alone would misdescribe us

Selective disclosure and holder binding are implemented in the shared package, so the machinery a holder would use exists and is waiting on custody rather than on cryptography.

The verifier's request side is done properly: the credential type pinned, the needed claims enumerated, disclosure constrained, and the response re-checked server-side rather than trusted.

Identity keys and value keys are separate, so the part of the system handling credentials never touches balances.

What we already have is the harder half of the work, and what is missing is wiring and a deletion job.

What a holder can actually do

Choose the issuer and the credential type, which is the real lever and it sits upstream of the wallet entirely. A narrowly-scoped credential from a careful issuer minimises more than any wallet feature can.

Ask before accepting: is this bound to my key, can it be revoked, and which fields can I disclose separately? Three questions nobody is ever asked, and all three answerable only before the signature exists.

Decline when the answers are bad. It is a blunt instrument and it is the one you have.

And the verifier side, since a holder cannot see it

Our own verifier asks for exactly what it needs and re-checks it, and accepts more than it asked for and does not delete the surplus. Scored in full on the regulatory page.

A holder has no way to know that from the outside, which is the deeper point: minimisation is mostly a property of systems you are not shown, and reading a privacy policy is not a substitute for somebody reading the code.