EVP Token Validator

Run the full relying-party checklist on a token: claims, key binding and both signatures.

Validate a token

Paste a full email verification token (issuer JWT ~ key binding JWT). The validator runs the same checks a relying-party server should: structure, claims, expiry, audience and nonce, the SD-JWT hash binding, the key binding signature against the token cnf key, and the issuer signature against the provider published JWKS. Cryptography runs in your browser; only the public issuer metadata and keys are fetched (through the Cubbbix server, read-only).

What a relying party must check, in thirty seconds

Accepting an EVP token on faith would be worse than the OTP it replaces, so the specification gives the verifying server a checklist. Parse the SD-JWT. Confirm email_verified is true, the token has not expired, the audience is your origin and the nonce is the one your form carried. Verify the key binding: its hash must cover this exact issuer token, and its signature must check against the ephemeral key in the cnf claim. Then verify the issuer signature against the keys the issuer publishes, and confirm DNS actually appoints that issuer for the email domain.

Skip a step and the proof has a hole in it. This page runs the whole list in your browser so you can watch each check pass or fail on a real token.

Frequently Asked Questions

Structure of the SD-JWT; email_verified; expiry and issued-at sanity; audience and nonce against the values you supply; consistency between the issuer JWT and the key binding JWT; the sd_hash binding; the key binding signature against the cnf.jwk ephemeral key; the issuer signature against the JWKS the issuer publishes; and, when you give the email address, that DNS appoints that issuer for the domain.

A token is only meaningful relative to the form it was minted for. The audience claim must equal your site origin and the nonce must equal the random value your server stored with that form instance. Without those comparisons, a token captured anywhere could be replayed on your site. Leaving the fields empty runs every other check and marks these as warnings.

The validator reads the issuer metadata at /.well-known/email-verification, follows its jwks_uri to the published signing keys, picks the key whose kid matches the token header, and verifies the signature with WebCrypto in your browser. The metadata and keys are public documents; fetching them through the Cubbbix server only works around cross-origin restrictions.

Not necessarily: expiry is the most common innocent failure, and issuer APIs are still changing during the origin trial, so a warning can mean the check could not be completed. But the relying-party rule is strict: any failed check means reject the token and fall back to the normal verification email. The user experience degrades to today behavior, never to insecurity.

No. Parsing and all cryptography happen in your browser. The only server requests fetch the issuer public metadata and public keys, which contain nothing about your token.

EVP Developer Lab

EVP Support Checker

Test whether this browser and provider can run the Email Verification Protocol.

EVP Domain Checker

Look up the _email-verification DNS record and issuer metadata for any email domain.

EVP Token Decoder

Decode an SD-JWT email verification token and read every claim.

Was this tool helpful?

Comments

Loading comments...

Check Out Other Popular Tools

German Alphabet Quiz

Learn and test all 26 German letters plus 3 Umlauts (Ä, Ö, Ü) and Eszett (ß) with native pronunciation audio, quizzes, and flashcards.

Educational Tools169

CSV to Excel Converter

Convert CSV to formatted Excel (.xlsx) workbooks without losing leading zeros. Preserve ZIP codes, phone numbers, and barcodes with auto column width sizing.

Converters94

Token Generator

Generate secure, random tokens and strings with custom lengths and character types. Free online token generator for developers, robust passwords, and API keys.

Developer Tools250