KYA verification certificate
Not verified yet
Paste evidence or choose an example.
- Agent
- –
- Principal
- –
- Mandate
- –
- Action
- –
- Decision
- –
- Receipt
- –
- Timestamp
- –
- Format
- –
Ten checks, one verdict, one level on the assurance scale. Nothing leaves your browser.
Paste or drop a file here. Binary RFC 3161 files go through “Choose file”.
Examples. Real signatures from the public test vectors and the IETF standard RFC 9421.
Keys you trust as the verifying party, for example from the issuer's published JWKS.
Status list tokens per IETF Token Status List. Separate several with spaces or line breaks.
Certificate of the timestamp authority or its root that you trust.
Verification runs entirely in your browser. Nothing is transmitted or stored.
KYA verification certificate
Not verified yet
Paste evidence or choose an example.
| Input | Recognized by | What is checked |
|---|---|---|
| Mandate or agent passport (SD-JWT VC) | Issuer JWS followed by disclosures separated by ~ | Signature, disclosures, key binding, validity, scope, revocation, delegation |
| Decision token (JWS) | Claim decision with allow, deny or escalate | Signature, issuer, agent, action |
| Receipt chain | kya-chain/1 or a list with entry_hash | Hash of every entry, linking, reference to decision and mandate |
| Evidence pack | kya-pack/1 | Manifest and all parts together, including cross-references |
| Timestamp | RFC 3161 token or TimeStampResp, binary, Base64 or PEM | CMS signature, purpose binding, binding to content, path to anchor |
| Signed HTTP request (RFC 9421, Web Bot Auth) | Raw request with request line and headers Signature-Input, Signature, optionally Signature-Agent; keys as the verifier's JWKS | Signature base per RFC 9421, Ed25519, ECDSA and RSA-PSS, key via kid or JWK thumbprint, operator binding |
| Mastercard Verifiable Intent | JSON with l1, l2 and optionally l3, or per role l2_payment/l3_payment, l2_checkout/l3_checkout | Signatures of all layers, sd_hash bindings, delegation to the agent key, amount range and payees, payment and checkout cross-reference |
Recognized but not checked in this version: classic AP2 JSON mandates and plain key material. The AP2 chain converged with Verifiable Intent runs through the VI adapter. The result says so explicitly instead of failing silently.
A valid signature only proves that the content matches the key. Who issued it is proven by where the key comes from. That is why every report states the key source.
| Source | Meaning | Proves the issuer |
|---|---|---|
did | from the issuer DID | yes |
trusted | from the verifying party | yes |
embedded | in the token itself (self-asserted) | no |
bundled | bundled with the pack (self-asserted) | no |
Keys via did:web or from a JWKS are not fetched automatically, because verification makes no network requests. Copy the issuer's published key into “Trust of the verifying party”.
Nothing. The engine is a JavaScript module that computes in your browser. The page forbids itself network connections through the Content Security Policy connect-src 'none', and the source contains no network or storage calls. Both are checked automatically on every release.
The report contains the SHA-256 of the input, a digest of the options, the engine version and the policy version. The command line produces the same report:
node cli/kya-verify.mjs evidence.json --now 2026-10-12T10:00:00Z --anchors tsa.pem
If the reportDigest matches, both sides verified the same thing and got the same result.
Mandates and agent passports as SD-JWT VC, decisions as JWS, evidence packs, receipt chains, timestamps following RFC 3161, Verifiable Intent and signed HTTP requests.
From their published JWKS or another trusted source. You provide them under “Trust of the verifying party”.
Because nothing is disproven, but not everything essential is proven. The certificate names what is missing, such as a status list or a timestamp anchor.
Yes, as a JSON certificate. It contains a reportDigest and can be recomputed at any time with the same data.