Verifier

Verify a Human Seal

Paste a Human Seal receipt below. The signature is checked in your browser, offline, against the key inside the receipt. That shows the receipt is consistent and unaltered; to confirm the key is the issuer's, compare it with the key published at did:web:humanseal.world. Nothing is sent anywhere. You rely on a published key, not on our word.

The first checker below is for the original receipt form. The second, further down, checks the newer credential forms (SD-JWT VC and W3C VC 2.0) against a key you paste. There is also a standalone verifier you can run yourself.

What do I paste here?

Your agent's governed action returned a reply. Inside it, result is the receipt. It is a block of text that starts with { and contains canonical, signature_ed25519 and public_key.
Copy the whole result block and paste it into the first box below. Leave the second box empty.
Press Verify. You will see whether the signature is genuine, who approved, and whether it is a real approval or a sandbox rehearsal.

No receipt yet? Press Generate a sample to see a valid one, or pick a test vector to watch a tampered one fail.

Human Seal receipt (JSON) Optional: the exact action, to check it was not swapped after approval (JSON)

How the check works (and you can do it yourself):

Remove the signature_ed25519 and public_key fields.
Canonicalize the rest: keys sorted, no whitespace, non-ASCII escaped, numbers exactly as written.
Verify the Ed25519 signature over those bytes against public_key.
Recompute sha256 of the canonical action and confirm it equals content_hash.

The same key is published at did:web:humanseal.world, so you can confirm the receipt was signed by the issuer it names. The exact rules, a standalone verifier and test vectors are on the conformance page.

Newer credential forms

Verify an SD-JWT VC or W3C VC 2.0 approval

Paste the credential, then the public key of whoever issued it. The check runs in your browser and nothing is sent anywhere. The issuer can be us or a company signing with its own key. Our key is at fo.flocore.tech/.well-known/jwks.json; open it and paste what you see.

Credential (one line of text; an SD-JWT contains ~ characters) The issuer's public key (a JWKS, a JWK, a DID document, or the raw base64url key) Optional: the exact action, to check it was not swapped after approval (JSON) Optional: the issuer you expect (for example did:web:company.example)

What this checks, and what it does not:

The signature (Ed25519 only; any other algorithm is refused), the credential type, and the dates.
That every disclosed claim matches a digest the issuer signed, and that the credential is an approval.
If you supply the action, that it is the one approved (its hash equals the signed content hash).
It does not fetch the key for you, does not check the revocation list, and refuses a credential that carries a key binding token. The same checks run in the standalone verifier, which gives the same verdict.