Badge Verification

Built-In Verification

Click Generate Badge to create the badge and request a verification check.

The application:

1. Reads the embedded attestation.
2. Recalculates the normalized artwork hash.
3. Fetches the issuer's JWKS.
4. Selects the public key matching kid.
5. Compares the published public key with the embedded key.
6. Verifies the attestation signature.

The interface reports Verified or Unverified.

Built-In Verification Scope

The built-in check does not fetch or enforce the separate assertion's active/revoked status.

Its Verified result confirms the implemented artwork, signature, and JWKS checks, not a complete online status validation.

Standalone Verification Page

Click:

Download verify.html

The application generates a self-contained HTML verification page with embedded verification JavaScript.

Using verify.html

1. Publish verify.html on a suitable website.
2. Open the page in a modern browser.
3. Enter the URL of a hosted badge SVG.
4. Optionally enter an issuer origin override.
5. Click Verify.
6. Review the result and diagnostic details.

Badge SVG URL

Example:

https://example.com/badges/A1B2C3D4E5F6.svg

The verifier fetches the SVG using the browser Fetch API.

Issuer Origin Override

Normally, the verifier derives the issuer origin from the attestation's assertion URL.

For example:

https://example.com/a/BADGE_ID.json

produces:

https://example.com

The verifier then requests:

https://example.com/.well-known/bar/jwks.json

The optional issuer field allows a different origin to be selected for the JWKS lookup.

Use this only when the alternative origin is trusted.

Verification Checks

Artwork Hash

The verifier normalizes the SVG and calculates SHA-256.

It compares the result with img_sha256.

Attestation Signature

The verifier reconstructs the BAR1 signature message and verifies it using ECDSA P-256/SHA-256.

Public Key Matching

The verifier checks that the embedded JWK's EC coordinates match those of the published key.

Online Assertion

The standalone verifier also attempts to fetch the assertion JSON.

It checks whether the assertion reports:

active

If the assertion contains a signature, the verifier checks that signature.

Verification Results

The standalone page displays one of:

✓ VERIFIED

✕ UNVERIFIED

✕ ERROR

The diagnostic output contains information such as:

• Artwork hash result
• Attestation signature result
• Online assertion result
• Badge identifier
• Key identifier
• Assertion URL
• JWKS information

Cross-Origin Requests

The verifier uses browser fetch requests with CORS enabled.

When resources are hosted on another origin, that origin must permit the required cross-origin access.

For example, a static host may need:

Access-Control-Allow-Origin: *

Only use a permissive CORS policy for resources intentionally published for public access.

Never expose private keys through these endpoints.

Verification Limitations

The current standalone implementation has several important limitations.

Expiration Is Not Enforced

The verifier does not compare exp with the current time.

Missing Assertion Signatures

The current code accepts an assertion without a sig field as passing its signature subcheck.

Incomplete Assertion Cross-Checks

The verifier does not fully require the assertion's ID, hash, key ID, and URL to match the SVG attestation.

Issuer Trust

A valid signature proves possession of the relevant private key.

It does not independently establish the legal identity, reputation, or authority of the organization controlling that key.

Custom Canonicalization

The verifier depends on BadgeMax Pro's specific artwork normalization algorithm.

Interpreting a Verified Result

A Verified result means the implemented checks passed.

It should not be interpreted as independent certification by QVLx Labs or any external authority.

For high-assurance deployments, the verification implementation should be reviewed and strengthened before relying on it as a security boundary.

Important: The standalone verifier is a useful foundation for badge verification, but the current assertion-validation gaps should be corrected before advertising it as tamper-proof or fully revocation-enforcing.