Can You Take Back a Credential You Already Shared?

The unlinkability implementation described here is unaudited.

No. You can mark the share revoked, and our interface will honour that.

The rest of this page is what "revoke" does do, stated precisely, because the gap between the word and the behaviour is where people get hurt.

The part that is genuinely impossible

A copy is a copy. Once a verifier has seen an attribute, they have seen it. They may have written it down, stored it, or built a decision on it. No button in any product, ours or anyone's, reaches into somebody else's system and removes what they already read.

Anyone who tells you otherwise is selling you something. The honest scope of revocation is future use, never past disclosure, and even that has limits below.

What revoking actually does here

DELETE /active/:shareId, signed in, returns 204. Underneath:

• A share that is not yours returns "not found": the lookup is scoped to your user, so the endpoint will not confirm that other people's shares exist.
• It sets revoked_at to the current time. That is the entire database operation.

The interface honours it. Your sharing page splits active shares from revoked ones and shows both, so revocation is visible and dated, not silently swallowed. That is real, and it is worth having: a durable, timestamped record of what you shared and when you withdrew it.

What it does not do, checked, not assumed

• It does not notify the verifier. No callback, no message, nothing.
• It does not touch a status list or the chain. A search across this product's modules for status-list or on-chain revocation returns nothing, with a control grep confirming the search itself works.
• We found no code path that rejects a presentation because its share was revoked. If one exists, we did not find it, and you should treat revocation as a record of your intent rather than an enforced block until that is demonstrable.

So the accurate summary is: revocation is honest bookkeeping. It is not an enforcement mechanism, and this page is not going to imply that it is.

Where enforcement actually lives, and why it is a different product

Credential status (the mechanism by which a verifier learns something has been withdrawn) is a different thing from a share record. It works by the verifier choosing to check a published list, and it is documented on why your credential shows active, suspended or revoked.

Sharing revocation and credential status are not the same feature, and conflating them would be the easiest overstatement on this page.

What to actually do if you shared something you regret

1. Revoke the share: it is the right first step and it records your decision.
2. Assume the data is out. Plan from there, not from hope.
3. If the credential itself should no longer be trusted anywhere, that is an issuer-side revocation, not a share-side one, and you would need the issuer to act.
4. For the future: share less. Selective disclosure exists so the question "can I take it back" comes up less often, though our unlinkability path is The BBS+ implementation referenced here is unaudited.

What you cannot check yourself

This surface is behind authentication, /sharing redirects to login, and a fake path returns 404, so the redirect means the page is real rather than that everything redirects. A stranger cannot verify any of the above without an account, so this page is code-read evidence, not the run-it-yourself kind.

Our content plan calls this page /revoke-a-share. That route does not exist: the surface is /sharing.