Take it back everywhere at once. Learn nothing about who asked.

What withdrawal actually is

Every credential you hand out carries the address of a list and its own position in that list. Withdrawing it means setting the bit at that position and re-signing the list. There is no revocation message, no callback, no queue, and nobody to chase.

That is why it works on a party you have never heard of. A bank in another country checking a proof you signed last year does not need your permission, your uptime or your goodwill — it needs one file, and the file is already public.

The list, decoded

This is the actual published list, fetched and taken apart. The outer object is a signed token; the interesting part is the payload, and inside it a single compressed bitstring holding one bit for every credential the list covers.

{ "alg": "ES256", "typ": "statuslist+jwt", "kid": "9ZwORnzeF2_sZhTRKYySO4jhJSjRfrEYk-UfIZCzPQ8" }

{
  "iss": "did:web:orbis.id",
  "sub": "https://id.orbis.id/status/1",
  "iat": 1787851326,
  "exp": 1787854926,
  "ttl": 300,
  "status_list": {
    "bits": 1,
    "lst": "eNrtwQENAAAAwqD3T20ON6AAAAAAAAAAgHcDIAAAAQ"
  }
}

• Whole token on the wire

  452 bytes — header, payload and signature together

• The bitstring, compressed

  31 bytes, carried as 42 characters of text

• The bitstring, inflated

  8,192 bytes — one bit each, so 65,536 positions

• Positions currently withdrawn

  None. Every inflated byte came back zero — so nothing in this list is revoked today.

• Freshness the issuer asks for

  ttl 300 seconds, and public, max-age=300 on the response

A whole revocation system, for a whole issuer, that fits in a text message. That is not a compression trick — it is what happens when the answer is one bit and the question is asked of a file instead of a server.

Why the whole list is read, and why that is the privacy story

The obvious design is an endpoint a verifier queries with one credential's identifier. That design tells you, the issuer, exactly which credential was being checked, by whom, and when. You would have built a surveillance log by accident and called it revocation.

So the list is read whole. A verifier that fetches the entire file has told you nothing about which row it cared about, because it asked for all of them. The privacy property is not a policy we promise to keep — it is a consequence of the shape of the request, and it holds even if we want it not to.

This is the same argument as the price of checking: there is nothing to meter on the verification path, and for exactly the same reason there is nothing to log. Why checking is free, structurally.

What it costs: up to five minutes of staleness

Reading a whole file has a price, and here it is, stated before you ask. The list asks to be treated as fresh for 300 seconds, and the response carries a matching cache directive. A verifier that honours either one can be holding a copy that is up to five minutes behind you.

So the withdrawal is published the moment you make it, and a particular verifier may act on it a few minutes later. If your control needs to be tighter than that, this mechanism is the wrong one and we would rather you knew now. We are not going to write "instantly" over a number the cell itself publishes.

curl -s -D- -o /dev/null https://id.orbis.id/status/1 | grep -i cache-control

One list per issuer, not one list for everybody

Your withdrawals are yours. The cell serves a list per issuer, at the issuer's own path, signed with the issuer's own subject — so nobody reading your list learns anything about anyone else's, and nobody reading theirs learns anything about yours.

curl -s -D- -o /dev/null https://id.orbis.id/t/root/status/1

Honest state of this section: the cell serves one issuer today, so the separation above is a property of the design that has not yet been put under load by a second tenant. Slot 6 prints what that means for you.

Count the withdrawals yourself

Nothing on this page needs a key, an account, or our cooperation. Three commands take you from the signed token to the number of withdrawn credentials in it.

1. Is it there, and what is it?

   curl -s -D- -o /dev/null https://id.orbis.id/status/1 | grep -i content-type

2. What does the payload say?

   curl -s https://id.orbis.id/status/1 \
     | cut -d. -f2 | base64 -d 2>/dev/null | jq .

3. How many are actually withdrawn?

   curl -s https://id.orbis.id/status/1 \
     | cut -d. -f2 | base64 -d 2>/dev/null \
     | jq -r .status_list.lst \
     | python3 -c "import sys,base64,zlib; s=sys.stdin.read().strip(); \
         b=zlib.decompress(base64.urlsafe_b64decode(s+'='*(-len(s)%4))); \
         print(sum(bin(x).count('1') for x in b), 'of', len(b)*8, 'bits set')"

The fourth command is the one that makes the other three mean anything: check the signature on the list against the issuer's published keys, at https://id.orbis.id/.well-known/did.json. A status list you have not verified is a file a stranger handed you.

What is real here.

curl -s https://id.orbis.id/api/site/register | jq -r '.entries[].slug'

Straight answers

Does the holder know I took it back?

Not from us. Nothing is pushed to their phone by this mechanism; the credential simply stops passing the fourth check the next time anyone runs it. If the person needs to be told, that is your job and your relationship — and we think it should stay yours.

Can I un-revoke one?

The bit can be cleared, so mechanically yes. Whether you should is a policy question we will not answer for you, and it is worth knowing that anybody who cached the list while the bit was set saw it set. A withdrawal is a public act and it does not un-happen.

What does someone learn from watching the list?

How many of your credentials are withdrawn, and which positions. Not who, not why, not when — the list holds bits and nothing else. What they cannot learn from it is which credential anyone was asking about, because asking downloads the whole thing.

What happens if the list stops answering?

A careful verifier fails the fourth check and refuses the proof, which is the correct behaviour and also means our outage becomes your outage. There is no SLA today and we will not blur alerting into one. The list is a static signed file, which is the cheapest possible thing to keep serving and the easiest to serve somewhere else.

Is this the same as a certificate revocation list?

It is the same idea with the sharp edges filed off: signed, fetched whole, and small enough that fetching it whole is not an imposition. The mechanism is the IETF Token Status List, and the row that carries its own state belongs on the standards page.