Test environment

Testing deployment. The endpoints below (*.t.status.siros.org) are for testing only — not for production use, and not guaranteed to stay backwards-compatible. See production environment for what's coming.

Endpoints

Role	Base URL	Auth
Authorization Server	`https://auth.t.status.siros.org`	—
Issuer API (allocate, status, accounting)	`https://api.t.status.siros.org`	Bearer access token
Verifier (published lists)	`https://lists.t.status.siros.org`	none

Full path-by-path reference (request/response shapes, the client-assertion field spec): API reference.

On this deployment specifically, any certificate chain is accepted — no trust list is configured behind it, so it never checks whether your chain roots anywhere in particular, only that the signature is valid. A production deployment validates your chain against a real trust list (e.g. an eIDAS LOTL or ARF LoTE) instead.

Get a test identity

For testing — no certificate needed for a throwaway identity, a bare jwk header is enough. Generated right here, in your browser, with the Web Crypto API; the key never leaves this page:

Every click generates a brand-new key, i.e. a brand-new test identity — there's no registration step to redo. Not something to build a real issuer integration on top of: a real issuer keeps its key and presents it as x5c (see the API reference for the field-by-field assertion spec) rather than regenerating a bare jwk per request.

Generate a fresh assertion for every call — it's not a credential to save and reuse, it's a proof of possession for one /token request. A stale one (past its 5-minute window) and a wrong aud both fail the same way: {"error":"invalid_client","error_description":"client assertion did not verify"}. If you see that, don't debug the assertion — just make a new one.

Quickstart

Issuers

Exchange your assertion for an access token:

ACCESS_TOKEN=$(curl -X POST https://auth.t.status.siros.org/token \
  --data-urlencode grant_type=client_credentials \
  --data-urlencode client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer \
  --data-urlencode "client_assertion=$ASSERTION" \
  | jq -r .access_token)

Allocate an index for a new credential — omitting exp returns the maximum allowed expiration:

curl -X POST https://api.t.status.siros.org/allocate \
  -H "Authorization: Bearer $ACCESS_TOKEN"
# => {"list_url":"https://lists.t.status.siros.org/lists/<id>","index":<n>,"exp":"..."}

Or set exp explicitly to match the credential's own lifetime (rejected with 400 if it's past this deployment's configured maximum):

curl -X POST https://api.t.status.siros.org/allocate \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" -d '{"exp":"2026-12-31T00:00:00Z"}'

Revoke or suspend it later:

curl -X PATCH https://api.t.status.siros.org/status/<id>/<n> \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" -d '{"status":"INVALID"}'

Verifiers

No auth. Fetch the signed Status List Token and check the credential's index:

curl https://lists.t.status.siros.org/lists/<id>

Standard HTTP caching (ETag) applies — poll as often as you like.