Independent verification
Check a response without trusting us.
Every answer this system returns is signed over canonical JSON and carries the address of the key that signed it. That is only worth something if you can check it yourself, with tools you already have — so here is exactly how, in four steps, using nothing of ours.
On this page
Everything below is a real, live endpoint. Substitute any publisher slug for {publisher} — the slug is the last path segment of that business's public page at /b/{publisher}.
What a signed response carries
Alongside the answer itself, every envelope carries the fields that make it checkable. Three of them are addresses you can fetch right now.
| coverage.status | resolved, partial, needs_context or not_covered — never a guess in between |
| attestation.kid | which key signed this, so you know which one to fetch |
| attestation.jwks_url | where that key is published |
| revocation_url | where withdrawals for this publisher are listed |
| expires_at | after which the signature is no longer a current claim |
| freshness | worst-case age of the data used, and whether it breaches the publisher's declared SLA |
Fetch the publisher's key set
Keys are per-publisher, not per-platform. Nothing about this request goes through an authenticated path, and the response is a standard JWKS document.
curl https://x-protocols.com/t/{publisher}/.well-known/x-protocol/jwks.json {"keys":[{"kty":"OKP","crv":"Ed25519", "x":"…base64url public key…", "kid":"kc_…","use":"sig","alg":"EdDSA"}]}
Match the kid from the envelope's attestation block to a key in this set. A rotated key stays published, so an old envelope remains verifiable after a rotation.
Recompute the digest
The signature is over a canonical serialisation of the payload, not over whatever bytes happened to arrive. Canonicalisation is deliberately boring, so that two implementations that have never seen each other agree:
- Object keys sorted, lexicographically, at every level.
- No insignificant whitespace: separators are , and : exactly.
- UTF-8, not escaped to ASCII.
- The digest is SHA-256 over those bytes, and the attestation block itself is excluded — a signature cannot cover itself.
Check the signature
Any Ed25519 implementation will do. This is the whole check, in a language most people already have, importing nothing from us:
import base64, hashlib, json, urllib.request from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey def b64u(s): return base64.urlsafe_b64decode(s + "=" * (-len(s) % 4)) env = json.load(urllib.request.urlopen("…your saved envelope…")) att = env.pop("attestation") # excluded from its own digest body = json.dumps(env, sort_keys=True, separators=(",", ":"), ensure_ascii=False).encode() jwks = json.load(urllib.request.urlopen(att["jwks_url"])) key = next(k for k in jwks["keys"] if k["kid"] == att["kid"]) # Raises if the signature does not match. No news is good news. Ed25519PublicKey.from_public_bytes(b64u(key["x"])).verify( b64u(att["signature"]), hashlib.sha256(body).digest()) print("signature valid")
Check it has not expired or been withdrawn
A valid signature says the publisher asserted this. It does not say the assertion is still current — that is what the other two fields are for, and skipping them is the most common way a correct-looking verification is still wrong.
curl https://x-protocols.com/t/{publisher}/.well-known/x-protocol/revocations.json
Compare expires_at against now, then check whether this envelope's kid, entity or digest appears in the feed within a window covering when it was signed. Revocation is a window, not an instant: withdrawing a wrong answer must not also withdraw the correction that fixed it.
A publisher that does not exist gets a 404, not an empty list
Asking for the revocation feed of an unknown publisher returns 404 {"error":"unknown_publisher"} — deliberately, because an empty entries array is a positive claim that nothing was withdrawn. If your verifier treats "no such publisher" as "nothing revoked", it will pass envelopes it should refuse.
What a valid signature does and does not prove
Four checks passing tells you three things, and it is worth being exact about which:
| Proved | The envelope has not been altered since it was signed, including its expiry and its revocation address, both of which are inside the signature for that reason. |
| Proved | It was signed by the key published at that publisher's jwks_url, and it is still current. |
| Proved | The publisher asserted these facts — so a wrong answer is attributable, which is the point. |
| Not proved | That the key belongs to the business it names. You fetched it from an address on this platform; a signature check cannot also establish whose key it is. |
That last question has its own page. Each publisher's /b/{publisher}/verify lists the evidence that was accepted for their authority, and prints beside each proof what it does not establish — control of a domain name is one accepted proof, a company register entry plus a code delivered to the registered address is another, and neither one of them is the only path.
If a check fails
Treat the answer as unverified and tell us — sign in and use the support link, or write to the address on your invoice. A signature that does not verify is either a bug on our side or something worse, and both are things we want to hear about immediately.