Four steps. The slowest one is a DNS record.

The shape of it

1. 01

   Set the organization up

   Its own verified name on the internet, a signing key it never has to handle, its brand on everything it hands out. Minutes, not quarters.

2. 02

   Hand out proof

   The person scans a code and it lands in their wallet, built so that later they can share one fact from it without revealing the rest.

3. 03

   Hold and control

   It lives on their phone, tied to that device. They decide what to show, and to whom, every single time.

4. 04

   Check it anywhere

   Anyone can check four things: the signature is real, the organization behind it is trusted, this is the right holder, and it has not been withdrawn.

01 · Set the organization up

Your organization gets a name on the internet that resolves to keys: a document at a well-known path under a domain you already control. Everything downstream reads that document, which is why the domain has to be yours and not a sub-account of ours.

You add one record so the name points at the right place, and we provision a signing key inside a cloud vault under managed identity. You never see the private half. There is no field in onboarding that accepts one, because a form that accepts a key is a form that has already lost it.

curl -s https://id.orbis.id/.well-known/did.json | jq .

Honest state of this step: the first two moves are a person on our side. Self-service sign-up is not built, and this page will say so until it is.

02 · Hand out proof

You publish what your organization is able to issue, and the wallet reads it before it asks the person for anything. Then you make an offer — a short-lived code, usually shown as a QR — and the person scans it. Their wallet fetches the credential, proving as it does so that the key it will be bound to is on that device.

{
  "credential_issuer": "https://id.orbis.id",
  "credential_endpoint": "https://id.orbis.id/credential",
  "authorization_servers": ["https://id.orbis.id"],
  "batch_credential_issuance": { "batch_size": 10 },
  "credential_configurations_supported": {
    "iVita.Membership": {
      "format": "dc+sd-jwt",
      "vct": "iVita.Membership",
      "proof_types_supported": {
        "jwt": { "proof_signing_alg_values_supported": ["ES256"] }
      }
    }
  }
}

03 · Hold and control

What lands on the phone is a signed statement with each field individually blinded, so the person can open some of them and leave the rest closed. The credential is bound to a key that was born inside that device's security chip and cannot be copied out of it.

From that moment the decisions are the person's, not yours and not ours. You cannot see where they use it. Neither can we — there is no endpoint that would answer the question, which is a stronger statement than a policy that says we would not look.

Honest state of this step: the wallet a person installs from an app store is not shipped. Slot 6 below prints its real state and what it costs the reader today.

04 · Check it anywhere

The person shows the proof to whoever asked. That party runs four checks, in this order: the signature is real, the organization behind it is one they trust, this is the right holder and not a replayed copy, and it has not been withdrawn.

Three of those four are answered by documents anyone can fetch — your key document and the status list. None of them is answered by asking you. That is the arrow that is missing, and it is the reason this design exists.

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

Run the whole sequence yourself

Everything a verifier does, except the cryptography, is three fetches. None of them takes a key. Paste these into a terminal and you have walked the same path.

1. What can this issuer issue?

   curl -s https://id.orbis.id/.well-known/openid-credential-issuer | jq .

2. Which keys is the signature checked against?

   curl -s https://id.orbis.id/.well-known/did.json | jq .

3. Has it been withdrawn?

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

All three answered on 2026-08-27. The step this list cannot show you is the offer, because an offer is short-lived by design and a printed one would be a dead one.

Which of these four steps actually works today.

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

Straight answers

How long does step one really take?

The technical part is minutes. The part that is not minutes is us, because sign-up is not self-service yet. We will not print a number for that until it is a number we would be held to.

Do I have to move my member data anywhere?

No. The facts stay in your systems. What we mint is a signed statement about a fact, and what we revoke is that statement. Your database does not move and we never get a copy of it.

What happens to credentials I already issued if I rotate my key?

Nothing, provided the old public key stays listed. That is why the document above carries two and lists both for assertion. Remove a key and everything it signed stops verifying, which is a real deletion and should be a deliberate one.

Can the person forge one?

Not without your private key, which lives in a vault neither they nor you can read. They can decline to show a credential, and they can show fewer fields than it holds — both of those are the design working, not an attack.

Where do I see the code?

The developer entry point is five commands, no account.