Verify

Paste a VAID. Get a verdict.

No data leaves your browser. This page makes no network request when you verify — here is how to check that yourself.

Verifying a VAID from a self-hosted mint

This page ships the published kernel key for the Solara production substrate. A VAID minted by your own issuer is signed by a key this page has never seen, so it will be rejected — correctly. To check one, supply that issuer's public key here.

Adding a key is a statement that you trust it. Get it from a channel the sender does not control. If the key arrives in the same message as the credential, checking one against the other proves nothing: whoever could rewrite the credential could rewrite the key beside it.

Session only. It is held in memory, never stored and never sent anywhere; reload the page and it is gone.

What this verdict does and does not establish

A VAID answers several questions that fail independently, so this page reports them separately rather than collapsing them into one word. A single “valid” is how a verifier ends up asserting more than it checked.

It establishes

  • Authenticity. The Ed25519 signature is valid over the canonical document, under a kernel key published in the trust anchor — and that key's thumbprint is recomputed from the key itself, never taken on the document's word. Every signed field is exactly as it was issued. Change one byte and it fails.
  • Expiry. Whether the document is past its expires_at.
  • Attenuation, when the sender presents the ancestor documents: that the delegation chain assembles to a root and that authority is contained at every hop. Without them, attenuation is reported unverifiable — which is not the same as satisfied.

It does not establish revocation, and it cannot

Revocation is never checked here. Not as a limitation this page will grow out of: there is no published revocation list to consult. The open reference mint's revocation list lives in memory and does not survive its own process, and durable revocation is not part of the open standard. An offline verifier could not reach a list even if one existed.

So read a passing verdict as “genuinely issued and in date”, and never as “currently authorised”. A VAID that passes everything on this page may have been revoked by its issuer minutes ago and nothing here would show it. The defence that actually works offline is a short lifetime, which is why VAIDs are short-lived.

Issuer identity is a separate question from the signature

A document's trust_domain names the issuing deployment. The production substrate currently emits substrate.internal, an RFC 6761 special-use name. That is the deliberate default for a deployment whose issuer identity has not been configured, chosen so that being unconfigured is visible rather than quietly claiming a real identity — and a conforming verifier should not bind a trust bundle to such a name.

This page reports that as a caveat rather than folding it into a pass. The signature is established; who the issuer is, as a named party, is not.

Checking the “no data leaves your browser” claim

Do not take it on trust — the page exists to argue that you should not have to.

  1. Open your browser's developer tools and select the Network tab.
  2. Load this page, then disconnect from the network — or tick “Offline”.
  3. Paste a VAID and verify. The verdict appears. The Network tab stays empty.
  4. Tamper with the document — flip a character inside the vaid1: token — and verify again. It is rejected, still with the network off.

The trust anchor is compiled into the page at build time, so there is nothing to fetch at page load either. The same anchor is served at /.well-known/synthera-kernel-keys.json, and our build fails if the two ever differ or if any published key stops hashing to the thumbprint it is filed under.

Verify it somewhere that is not our website

This page is convenient, not authoritative. You should be able to reach the same verdict without us, and you can — the verification logic here is the published vaid-mint package, unmodified: 

npx vaid verify 'vaid1:…'

or against any of the three reference implementations — Rust, Python and TypeScript — which are locked byte-for-byte to the same conformance vectors. This page is the TypeScript one, so re-checking in Rust or Python is the stronger move: it exercises a different codebase rather than running the same one twice. If any implementation disagrees with another about the same bytes, that is a bug worth reporting loudly.

The key this page trusts

thumbprint
urn:ietf:params:oauth:jwk-thumbprint:sha-256:VwvbN9yIguAset99AdeZyud7ZBHV5CcQa7zZML5ZQds
key
INjJhHXQUsJyHMJn1uObwqoskkZjMy8WDWeRAM6xRmc
key_id
6cd3ef32-1712-4d87-84e0-ff88927c5556
status
current

Cross-check it against the trust anchor page and against the copy in the vaid repository. Agreement across channels is the point; a key you only ever saw in one place is a key you have not checked.