Skip to main content
Attestixv0.4.0
Verification portal

Verify an Attestix credential —
in your browser, nothing uploaded.

Paste a W3C Verifiable Credential, or drop a .json file. The signature is checked entirely on this page using the published @vibetensor/attestix verifier. No installation, no account, no backend — your credential never leaves your machine. That is a stronger trust story than a server-side verifier: there is nothing to log, nothing to intercept, and nothing to trust beyond the open-source code running in your own browser tab.

01 / How this works

Attestix credentials carry an Ed25519Signature2020 proof. To verify one, the page:

  1. Strips the mutable proof and credentialStatus fields, then re-serialises the remainder to its JCS-canonical byte form (sorted keys, tightest separators, NFC-normalised).
  2. Resolves the issuer's public key from the did:key embedded in the proof's verificationMethod (the key is self-certifying — it is the public key, multibase-encoded).
  3. Verifies the Ed25519 signature over those canonical bytes via @noble/curves, checks the credential structure, and compares the validity window against your browser's clock.

Every step runs in a WebAssembly-free, pure-JavaScript crypto path inside your tab. The same verifier ships in the @vibetensor/attestix npm package and is byte-compatible with the Python attestix core. The canonicalisation rules are documented in the bundle wire-format spec.

02 / What offline verification proves — and what it doesn't

Proven offline
  • Signature authenticity. The credential was signed by the private key matching the issuer DID, and not modified since — any tampered field breaks the signature.
  • Structural validity. The document is a well-formed W3C VC with the required fields.
  • Validity window. Whether the credential is within its issuanceDate–expirationDate range, compared against your clock at view time.
NOT proven offline
  • Live revocation. Offline mode reads only the credentialStatus embedded in the document. Checking the issuer's status list in real time is a hosted lookup (an Attestix Cloud feature). A signature can be valid and the credential still revoked.
  • Issuer identity. A did:key is self-certifying — it proves control of a key, not who controls it. did:web binds a DID to a domain; did:key does not. Establish out-of-band that the DID belongs to the party you expect.
  • By-id lookup. Resolving a credential from just its id needs the hosted API; this static page has no store to resolve against.
See also
@vibetensor/attestix (npm verifier)Bundle wire format v1SecurityOffline verification docs

Attestix is evidence tooling, not a guarantor of compliance. A green result proves the credential's signature and structure — it does not by itself establish that the issuer was authorised to make the claims, nor that the subject is compliant. Maintained by VibeTensor.