Emilia trust verification

EMILIA Trust Verification

EMILIA Protocol makes a high-risk AI-agent action carry a device-key signoff plus a receipt anyone can verify offline. This skill guides you to verify those artifacts using the public EMILIA MCP connector. It requires the connector to be enabled (server URL https://www.emiliaprotocol.ai/api/mcp/mcp, read-only, no auth).

When to use this skill

Engage when the user:

• Pastes a JSON object with "@version": "EP-RECEIPT-v1" (a trust receipt), or asks "is this receipt real / altered / valid?"
• Pastes an object with a context + webauthn block (a device signoff), or asks whether the WebAuthn/passkey ceremony and exact-action binding verify.

If the user mentions a receipt or signoff but hasn't pasted it, ask them for the JSON (they can copy a real example from https://www.emiliaprotocol.ai/verify).

The two public tools

Tool	Use it to
ep_verify_receipt	Verify an EP-RECEIPT-v1 receipt — Ed25519 signature over canonical JSON + optional Merkle anchor.
ep_verify_signoff	Verify a Class-A device signoff — a WebAuthn (ECDSA P-256) assertion bound to the exact action.

Each verify tool accepts the JSON object directly; the public key can be passed explicitly or, for self-contained evidence packets, is read from an embedded issuer_public_key / approver_public_key field.

How to interpret results

Receipt — { valid, checks: { version, signature, anchor } }:

• valid: true → the receipt was signed by its issuer and has not been altered. State this plainly; the user can re-verify it themselves, offline, forever.
• valid: false with signature: false → the receipt does not match its signature — it was tampered with, or the wrong key was used. Do not treat a failed receipt as trustworthy. Call out which check failed.
• anchor: false → the Merkle inclusion proof does not reconstruct the claimed root (the anchor was altered).

Signoff — six checks. All must be true for valid: true:

• challenge_binding → the signature is bound to this exact action; if false, the action was changed after signing (e.g., the amount).
• user_present + user_verified → a real human was present and verified with a biometric / PIN (Face ID, Touch ID, passkey).
• signature → signed by the approver's enrolled device key.
• client_data_type / rp_id_hash → a genuine assertion scoped to the right relying party.

When a signoff verifies, the precise statement is: the supplied WebAuthn assertion verifies under the caller-supplied public key, RP ID, and allowed origins; it records user presence and user verification and binds the signed challenge to the supplied exact action. It does not by itself establish legal identity, authority, what the user perceived, or relying-party acceptance. When it fails, name the specific check and what it implies.

Demonstrate tamper-evidence

A compelling, honest demo: after verifying a valid receipt, offer to change one field (e.g. an amount from 82000 to 820000) and verify again — it will flip to valid: false, showing the receipt is cryptographically bound to the exact action. Only do this on example data the user provided.

Boundaries (state these if asked)

• Verification proves authenticity and integrity, not real-world currency: it does not prove a key wasn't revoked after signing, nor what the human literally saw on screen (the protocol treats presentation/WYSIWYS as a stated residual risk).
• These tools are read-only. Creating receipts, opening signoffs, or gating agent actions happens through EMILIA's authenticated APIs / the EMILIA Guard Claude Code plugin — not this connector.
• Rich trust profiles and policy evaluation are authenticated API surfaces and are deliberately not exposed by this no-auth public connector.
• The same verifier is open source (Apache-2.0): npm i @emilia-protocol/verify (Node + browser), with JavaScript, Python, and Go implementations proven interoperable. Nothing here requires trusting EMILIA's servers.