Skip to main content
Verification portal

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

The credential is processed locally by this page and is not posted to an Attestix verification backend. Page delivery and browser extensions have separate trust considerations. This page uses the published attestix 0.4.2 SDK and local input boundaries; it does not establish issuer trust or legal validity.

How this works

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

  1. Strips the mutable proof and credentialStatus fields, then serialises the remainder using the Attestix SDK canonical form (sorted keys and NFC normalization). This profile is not strict RFC 8785 JCS, which does not normalize Unicode.
  2. Resolves the issuer's public key from the did:key embedded in the proof's verificationMethod after requiring its controller to match the stated issuer. The key is self-certifying; no domain resolver or network lookup is used.
  3. Verifies the Ed25519 signature over those canonical bytes via @noble/curves, checks the supported proof profile and unambiguous JSON keys, and compares any valid expiration timestamp against your browser clock.

Cryptographic checks use published attestix 0.4.2 within the documented Attestix canonical profile. Language-specific validation boundaries differ. Shared fixtures do not establish arbitrary cross-language equivalence, identical trust or fresh revocation policy.

What this page checks, and what remains separate

Supported local checks

  • Signature authenticity. The credential was signed by the private key matching the issuer DID. Changes to signed fields break the signature; mutable credentialStatus and proof metadata are excluded.
  • Supported local checks. The stated did:key issuer matches the proof controller, supported proof fields pass local checks, and normalized JSON keys are unambiguous. This is not a complete W3C conformance assessment.
  • Expiration. If expirationDate is present, it must be a valid RFC 3339 calendar timestamp later than your browser clock. An absent expiration is allowed. This check does not enforce issuanceDate or establish that the credential is currently authorized for use.

Not proven offline

  • Live revocation. Offline mode reads only the credentialStatus embedded in the document. Fresh revocation status requires a separate trusted status check, which this page does not perform. 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. This offline verifier supports only did:key. did:web requires a trusted resolver and is rejected here. 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

A valid result supports the tested signature and local input checks. It does not establish issuer authority, claim truth, fresh revocation status, replay policy, legal conformity or certification.