SecureStamp Trust Protocol

SPF verifies that an IP is authorized to send on behalf of a domain. DKIM verifies message integrity and domain association. DMARC ties them together with a policy. But none of these standards prove that a payment instruction, credential request, vendor change or agent action matches a declared counterparty policy.

A domain can pass all three checks and still carry a manipulated request, a compromised workflow, a lookalike counterparty, or a message generated by AI that pressures a human or agent into acting too quickly.

Humans and agents need a reliable signal at the instant before action: click, reply, approve, pay, share credentials, update records or execute an automated workflow. Without a shared protocol, the burden falls on discipline, manual callbacks and visual judgment.

An organization registers domains, senders, official channels and counterparty policies at securestamp.online. Registration creates verifiable records anchored on the audit ledger and scoped to the tenant or public perimeter as appropriate.

DNS TXT record — the domain publishes a TXT record at _securestamp.example.com containing the stamp ID and verify URL. This is the most robust channel as it is controlled by the domain owner and queried independently of private message body.

HTTP header — mail servers add an X-SecureStamp SMTP header to outgoing messages. This requires mail server configuration but provides per-message verification with a signed JWT payload.

API registration — organizations register channels, counterparties and action policies with SecureStamp directly, enabling real-time verification lookups without DNS propagation delays.

When a plugin, verifier or agent encounters a message or requested action, it queries POST /api/trust/check or the Action Verdict API with the origin, domain, channel, abstract risk signals or source hash. The API returns a structured trust response, Safe Next Step or signed receipt without requiring raw message content.

Signals and the notarial layer resolve to a five-level scale. Levels L1–L4 are a function of technical signals, registered origin and policy context; L5 requires a notarial match plus an approved identity. Declared policy rules can force a decision toward caution regardless of score.

• L5 — Certified · Notarial match + KYBThe origin or message envelope matches a notarial record issued by a registered identity with approved business-identity (KYB). Certifies origin + envelope integrity.
• L4 — Probably legitimate · Technical floorDomain is technically sound (SPF/DKIM/DMARC, reputation) but carries no notarial seal. The most a commodity check can assert.
• L3 — Neutral · MixedSome signals degraded; no strong positive or negative.
• L2 — Suspicious · DegradedMultiple weak or failing signals. The user or agent is warned before acting.
• L1 — High risk · Failing / policy conflictCritical signals fail, or a declared policy conflict requires verification by another channel before action.

An issuer registers a notarial record at issue time. The record is an ES256-signed attestation over a canonical hash of the message envelope — sender, ordered recipients, and subject — never the body. The recipient's client recomputes the same canonical hash and asks POST /api/verify/email to compare it against the signed record, yielding one of certified_match, token_valid_hash_mismatch, token_invalid or not_registered.

Forgery resistance rests entirely on the signing key, not on secrecy of the scheme: without the issuer's private key an attacker cannot mint a valid record, and altering any covered field changes the hash and breaks the match. Signing keys are rotated and the corresponding public keys are published as a JWKS set (key-id pinned), so any party can verify a signature — current or recently rotated — without trusting SecureStamp at run time.

L5 certifies that a message or origin matches a registered issuer and that its covered envelope is intact. It makes no claim about whether the content is true or whether a requested action should execute without context. This boundary is a deliberate, non-negotiable property of the protocol.

A notarial match alone reaches the certified band only when the issuing organization has passed a business-identity (KYB) review. Until identity is approved, an otherwise-perfect notarial match is capped at L4. This binds the cryptographic claim (“this registered identity issued this record”) to a vetted real-world identity (“and we verified who that organization is”).

The SecureStamp audit ledger is append-only and records signed transparency entries for stamp issuance, revocation, score changes and abuse events. The production storage model is designed for deterministic reads, tamper-evident hashes and independent verification without exposing private message content.

Every stamp issuance, revocation, and score change is written to the ledger as an immutable transaction. Ledger entries contain only stamp IDs and cryptographic hashes — never personal data or message content.

Any party can independently verify a stamp's authenticity and history by querying the public ledger endpoint at GET /v1/ledger/tx/:txHash.

The default suite is SSCM-1: ECDH P-256 key agreement, HKDF-SHA256 derivation, and AES-256-GCM content encryption. A per-message key encrypts the body and is wrapped for each recipient via an ephemeral ECDH agreement, so recipient key identifiers stay opaque (Bcc is not leaked). All key generation and encryption happen on the client; private keys are non-extractable and never leave the device.

Senders publish only their public keys to a directory. Directory and preflight responses are themselves ES256-signed (verifiable via the same JWKS as the notarial layer), so a client can confirm it is encrypting to the genuine recipient key and not a substituted one. First-seen keys are pinned (TOFU).

Each message carries a sender signature (proof-of-possession) the recipient verifies against the directory, distinguishing a genuine sender from a replay. Users hold an individual recovery file, and organizations may hold a recovery key — both are client-side secrets SecureStamp cannot read. The mode is strict by design: if any recipient lacks an active key the client blocks the send rather than silently downgrading to plaintext. The suite is crypto-agile (SSCM-2 X25519, SSCM-3 post- quantum hybrid are reserved).

Each stamp contains an ES256-signed JWT payload anchored to the ledger. Copying a stamp image provides no benefit — the plugin verifies the signature at verification time, not the visual.

Plugins operate with minimal permissions. Chrome MV3 restricts background page access. Office.js sandboxes the plugin within the Outlook renderer. No plugin has access to the full email body in production mode.

All API keys are prefixed and hashed before storage. The system supports key rotation without service interruption. All mutation endpoints require valid JWT or API key authentication. Rate limiting is enforced at the Vercel WAF edge before reaching application code.