How to Receive a Credential, and What Your Wallet Actually Keeps

Receiving one is short: an issuer gives you an offer, you paste or scan it, and the credential appears in your identity screen. The interesting part is what "appears" means.

The steps

Get an offer from an issuer. It arrives as a link, a code, or a block of text. It contains where to collect the credential and a one-time code authorising you to collect it.

Paste or scan it into the wallet. The interface accepts the link form, the raw text form, and the scanned form, so you do not have to know which one you were given.

It appears in your identity screen with its type, who issued it, when it was issued and when it expires.

Where the redemption actually happens

Not on your device. The wallet backend performs the exchange with the issuer, server to server, using the one-time code from the offer.

That is worth knowing because the rest of this wallet is emphatic about your keys never leaving the browser, and this step is the exception in shape if not in substance: the pre-authorised flow does not use your private key, so nothing secret leaves your device. But the exchange is made on your behalf by a server, and that server learns which issuer you collected from and when.

And what your wallet keeps is a catalogue, not the credential

We read the storage table. It is named a cache, and its columns are: an identifier for the credential, its type, the issuing party, the issue and expiry dates, a status, where it came from, and its format.

There is no column for the credential itself. No signed body, no claims, no disclosures.

Two controls, because the whole page turns on this absence. The same migration file stores real payloads for other things, so the schema keeps data when that is the intent. And the only client-side storage anywhere in the interface is your theme preference, so it is not hiding in the browser either.

So the honest statement is that your wallet knows that you hold a credential and what kind, and does not hold the thing itself.

What follows from that, and it is the useful part

You cannot present what is not there. The share feature produces an unsigned summary rather than a presentation, and the application says so in its own words. Those two facts are the same fact.

Your privacy position is better than it looks. A server holding a catalogue of credential types knows less about you than one holding the claims inside them. The metadata is real exposure and it is a smaller exposure.

And this is a state of build rather than a defect. Holding the credential means holding it somewhere the browser can reach on demand, which reopens every question this wallet answered by keeping keys in memory only. It is unbuilt, not refused.

What to do today