Skip to main content

Documentation

Evidence types

The upload form takes four inputs. Only the EAA payload is required; the other three add coverage to specific checks. This page describes each in detail, the format the engine expects, and the most common validation pitfalls.

EAA payload (required)

The Electronic Attestation of Attributes itself, in SD-JWT VC compact serialisation. The format is documented in draft-ietf-oauth-sd-jwt-vc. A compact form is a string of the shape:

<header>.<payload>.<signature>~<disclosure_1>~<disclosure_2>~...~[<kb_jwt>]

The first three dot-separated segments are a JWS (each a base64url- encoded byte string). After the signature, zero or more ~-delimited disclosures may appear, followed by an optional Key Binding JWT in presentation form. Issuance form ends with a trailing ~ and no KB-JWT.

The form's textarea colour-codes each segment so you can spot a malformed paste at a glance. A correctly-formed compact JWT lights up; random text does not.

Common pitfalls.

  • Whitespace inside the string. Some terminals wrap long lines and insert hard line breaks; ensure the compact form is a single contiguous string with no whitespace.
  • Missing trailing tilde. An issuance-form SD-JWT VC ends with ~; copy-paste truncation often loses it. The engine treats a compact form without any tildes as an unwrapped JWT and parses degraded.
  • Wrong typ value. The protected header should declare typ: dc+sd-jwt (per the latest IETF draft). The legacy vc+sd-jwt still parses but is flagged on a future check; align to dc+sd-jwt when you can.

If you do not have an EAA to hand, the reference samples library publishes seven cryptographically-valid samples mirroring the ETSI EAA Plugtests SJV-EAA test cases. Each one has a button that pre-fills the upload form with a one-click run.

Issuer X.509 certificate (optional)

PEM-encoded certificate of the entity that signed the EAA. Used by the trust-list and signature-verification controls (deferred today; the toolkit accepts the cert and surfaces it in the report but does not verify the signature against a trust list yet).

Expected shape:

-----BEGIN CERTIFICATE-----
MIIBkDCCATagAwIBAgI...
...
-----END CERTIFICATE-----

The textarea accepts a single PEM block. Drag a .pem or .crt file onto it and the contents are loaded automatically. If your issuer publishes a certificate chain, paste the leaf cert here; the full chain support arrives with the trust- list integration.

Some EAAs already carry the cert in the JWS protected header's x5c claim. In that case you do not need to paste it separately; the engine reads it from the header. The field is here for cases where the cert is delivered out of band.

Status list URL (optional)

The HTTPS URL that publishes the credential's revocation status, per draft-ietf-oauth-status-list. The runtime resolver check EAA-5.2.10.2-01 fetches this URL, parses the JWT or CWT payload, and looks up the credential's status index in the decompressed bitstring.

The engine first tries to read the URL from payload.status.uri on your EAA payload. The form input is an explicit override, useful when you want to test against a staging endpoint, or when your credential carries a relative URL that needs absolutising.

Common pitfalls.

  • CORS not configured. The browser blocks cross- origin fetches that do not declare Access-Control-Allow- Origin. The verdict's notes explicitly name CORS as the probable cause when fetch fails.
  • Wrong Content-Type. The endpoint must return application/statuslist+jwt or application/statuslist+cwt. A bare application/json is rejected.

Type metadata (optional)

JSON object describing the credential type, linked to from the vct claim. The format is the SD-JWT VC type metadata shape (claims, integrity, display info). The engine uses it to validate that the credential's claim names and value types match the type's declared schema.

Paste the JSON directly into the textarea. The form validates that it parses as valid JSON before submitting. Type metadata is required for the type-integrity check EAA-5.2.1.2-03 when the EAA payload carries a vct#integrity claim; without metadata the engine returns N/A for that check.

What is NOT collected

Nothing about your evidence leaves your browser unless you explicitly request the runtime resolver (status list URL fetch). The engine, the catalogue, and the report all run client-side. The downloaded PDF and JSON files are produced in your browser via URL.createObjectURL; no upload step.

Reports are stored in localStorage under a public-tenant identifier and kept for 30 days; the email captured at the gate is stored alongside the report id, also locally. Clear your browser's site data to remove both at any time.

Last reviewed 02/05/2026. All documentation · Back to the Hub ·