How a Wallet Decides What to Share, and Why Ours Is Not in That Conversation
The intended shape of this exchange is that a verifier states what it needs, your wallet works out which of your credentials satisfy it, shows you the choice, and sends the minimum.
Ours does none of that. A search across this wallet for the presentation-request vocabulary returns zero files. It never receives a request, never matches one against anything, and never asks you.
Where the deciding actually happens today
On the verifier's side, and we read that code rather than describing an intention.
The verifier builds a request that pins the credential type, enumerates the specific claims it needs, and sets the constraint that disclosure be limited to those claims. It also checks, when a response arrives, that the credential type matches and that every required claim is present.
The same vocabulary the wallet lacks is present in the verifier application, so the search finds this machinery where it lives. The seat that is empty is the holder's.
What "the wallet decides" would actually mean
Three jobs, none of which exist here.
Matching. Given a request, work out which held credentials could satisfy it. Requires holding credentials, and we hold a catalogue rather than the credentials.
Choosing. Where more than one could satisfy it, decide which, ideally by asking you. Requires matching first.
Minimising. Send only the claims the request named, using the format's selective disclosure. The capability exists one layer down and this wallet does not call it.
So the gap is not a missing screen. It is that all three jobs sit on top of custody the wallet does not have.
And the part of this that is genuinely hard, once custody exists
Matching is not a lookup. A request can name a claim by a path into a structure, ask for one of several acceptable credential types, or state a condition rather than a field. A wallet that gets this subtly wrong either fails to present a credential that would have worked or presents more than it needed.
Choosing is a user-interface problem with a privacy consequence. If two credentials satisfy a request, the one you pick tells the verifier something about you before any claim is disclosed.
Minimising depends on how the credential was built. If the issuer did not enumerate the parts of a nested object, you disclose the object whole, whatever the request asked for. The wallet cannot minimise past the granularity it was given.
That last one is the recurring shape again: a decision made at issuance, discovered at presentation, by the party who cannot change it.
What a holder should take from this today
Nothing in this wallet is choosing on your behalf, because nothing is being asked of it. If you see a share control, it produces a summary rather than a presentation and says so.
When custody and presentation arrive, the question to ask is whether you are shown the choice or it is made for you. A wallet that silently picks is a wallet making a privacy decision you did not see.
Keep reading
- Credential Data Model 1.1 and 2.0, and a Proof Block That Names the Wrong Thing
- How Signing In Works, and a Client That Does What the Server Leaves Optional
- Signing In With a Wallet Address, With an Identifier, or the Third Thing We Actually Do
- Does Your Identifier Work With Other Tools? Three Answers, One of Them No