TrustReceipt proporciona evidencia criptográficamente verificable, tamper-evident y exportable para auditoría de operaciones agentic-commerce, diseñada para soportar flujos eIDAS-aligned, ESIGN/UETA y UK retained trust services law.
Un TrustReceipt no es por sí solo una firma cualificada. Es evidencia estructurada que un regulador, auditor o tribunal puede examinar offline, en combinación con el marco legal aplicable a tu jurisdicción.
Qué es un TrustReceipt
Cada vez que un agente de IA lee catálogo, modifica un carrito o completa un checkout en una tienda conectada a Trusteed, la plataforma emite un JWS detached firmado con la clave Ed25519 del comercio. El recibo registra quién hizo qué, en qué bucket (discovery, customer o checkout), contra qué hashes de entrada y salida, y en qué momento. Se puede exportar, re-verificar offline y presentar como evidencia años después.
Marcos legales y estado actual
Trusteed mapea cada TrustReceipt a un enum `legal_posture` para que el consumidor sepa exactamente qué peso legal asignar. Las afirmaciones AdES-candidate solo se emiten cuando hay un timestamp cualificado RFC 3161.
Parámetros que aceptamos
Sin QTSP emitimos `ades_candidate_timestamped` (con TSA) o `ades_candidate_no_tsa` (sin). Integración QTSP (InfoCert) diferida a spec 050.
Parámetros que aceptamos
Dependencia EUDI del auto-registro WRP/RPRC sin validar cross-border. Piloto pendiente del despliegue por Estado miembro.
Parámetros que aceptamos
Requisitos ESIGN §101(c) de consumer disclosure implementados como signed evidence records. Aprobación legal pendiente para postura productiva; canary actual es observe-only.
Parámetros que aceptamos
Divergencia post-Brexit monitorizada. Integración con UK Trust List tras feature flag pendiente de guía ICO sobre evidencia AI cross-border.
Anatomía de un TrustReceipt
Un TrustReceipt es un JWS detached (forma compact) más un pequeño conjunto de campos envelope sin firmar. El payload firmado se canonicaliza con RFC 8785 antes de hashear. Los bodies crudos input/output nunca salen del vault cifrado del comercio.
{
"id": "trcpt_01HXY...",
"callId": "call_01HXY...",
"agentId": "agt_acme_browser",
"merchantId": "mch_paco_sandias",
"bucket": "checkout",
"tool": "complete_checkout",
"inputHash": "8f4a...c2",
"outputHash": "a1d9...77",
"signingKeyKid": "mch_paco_sandias-2026Q2",
"jws": "eyJhbGciOiJFZERTQSIsImtpZCI6...",
"jwksSnapshotUrl": "https://trusteed.xyz/.well-known/jwks/snapshot/2026-05.json",
"legal_posture": "ades_candidate_timestamped",
"createdAt": "2026-05-12T10:14:33Z"
}Cómo funciona la verificación
Hacer fetch del URL de snapshot embebido en el recibo. El snapshot está firmado a su vez y ligado a un historial de claves con ventanas de validez.
Usar el `kid` del header JWS para elegir la clave pública Ed25519. Verificar con cualquier librería JOSE estándar — no se necesita código de Trusteed.
Reconstruir inputHash y outputHash desde los bodies crudos (si están divulgados). Comparar con los valores firmados. Cualquier mismatch = manipulado.
Si hay un TimeStampResp adjunto, verificar la cadena completa (cert TSA, OCSP/CRL, EKU, ventana de tolerancia). Ancla el recibo en tiempo real.
Los agentes de IA que leen o escriben contra una tienda conectada a Trusteed pueden solicitar y verificar TrustReceipts como evidencia de primera clase. Esto habilita auditoría agente-a-agente, cadenas de atribución multi-hop y resolución de disputas sin escalación humana.
Flujo mínimo de verificación por parte del agente (Node.js, sin SDK de Trusteed):
import { compactVerify, createLocalJWKSet } from "jose";
// 1. Get a receipt from the merchant API
const r = await fetch(`https://trusteed.xyz/api/v1/trust/receipts/by-order/${orderId}`)
.then((r) => r.json());
// 2. Resolve the JWKS snapshot referenced in the receipt
const jwks = await fetch(r.jwksSnapshotUrl).then((r) => r.json());
// 3. Verify the JWS signature (Ed25519, EdDSA)
const { payload, protectedHeader } = await compactVerify(
r.jws,
createLocalJWKSet(jwks),
);
// 4. Decide on legal posture before claiming AdES
if (r.legal_posture !== "ades_candidate_timestamped") {
console.warn("Receipt valid but no qualified timestamp present");
}Metadatos del agente
{
"documentType": "trust-receipt",
"signatureAlgorithm": "Ed25519",
"canonicalForm": "RFC 8785 JCS",
"timestampStandard": "RFC 3161",
"transportFormat": "compact JWS (RFC 7515)",
"verifierLibrary": "@trusteed/receipt-verifier",
"discovery": "https://trusteed.xyz/.well-known/mcp.json",
"policy": "https://trusteed.xyz/.well-known/agent-policy.json"
}Bajo ESIGN/UETA (US), UK ECA 2000 y eIDAS Art. 25 (UE), la evidencia electrónica no puede ser denegada por el mero hecho de ser electrónica. Un TrustReceipt aporta las primitivas de tamper-evidence y no-repudio que un tribunal típicamente pide. La admisibilidad final depende siempre del foro y de la transacción subyacente.
No. Para postura AdES usamos una TSA estándar RFC 3161. La Firma Electrónica Cualificada (QES) requiere QTSP y está en roadmap (spec 050).
Los JWS firmados se persisten en el audit log del comercio con cadena hash (RFC 8785). Input/output crudos quedan en un vault cifrado (AES-256-GCM). El historial JWKS se publica en una URL estable para verificación offline.
Los recibos antiguos siguen siendo verificables contra el snapshot JWKS referenciado al emitirlos. La evidencia de revocación se publica como extensión JWS firmada; los verificadores DEBEN comprobarla antes de reclamar postura AdES.
Cada operación agentic-commerce queda con un recibo firmado. Empieza gratis o consulta la documentación para desarrolladores.