Confidential — Pre-disclosure Internal prototype. No public discussion, demo, or embedding outside NDA until USPTO provisional is filed.
ARIA-AUT · Channel Provenance Protocol
Per-Counterparty Authenticationof Electronic Communications
Sender enrollment registry · per-message signing · recipient verification client · trust-mark protocol · trap-and-attribution layer
Filing · USPTO Provisional 2026-04-27
Inventor · Francois Flechter (sole)
Channels · Email · web · SMS · voice · IoT
Locale · Geneva · 2026-04-28
Enrolled Senders
REGISTRY

Each holds a sender_secret in HSM-equivalent storage. Pick one for the next compose.

Compose Communication
SENDER

Per-counterparty key derived: HMAC(sender_secret, recipient || content_hash || nonce). Signature attached as channel header.

Adversary Console
ATTACK

Pick the attack scenario. Each demonstrates a different verification-failure mode the recipient client catches.

Inbox · francois@example.com
Inbox is empty. Send a communication from the panel on the left.
Threat-Intelligence Feedall enrolled senders
REAL-TIME · LAST 30 DAYS
0
Verification failures
0
Decoy-recipient hits
0
Blocked at recipient
0
Authenticated delivered
Attack-type breakdown
0
Plain spoof
0
Display-name spoof
0
Lookalike domain
0
Compromised account
Event feed
No spoofing attempts captured yet.
Use the Adversary Console on the left to launch one of four attack scenarios. Each verification failure populates this feed with forensic context routed to the impersonated sender's threat-intelligence team.
Live message flowper-counterparty signing through cooperative verification
SENDER
Bank · enrolled
sender_secret in HSM. Per-counterparty signing.
signed message
REGISTRY
ARIA Service
Public verification material · cooperative verifier network · trap layer.
verification
RECIPIENT
Verification Client
Browser ext / OS service. Re-derives signature, renders trust-mark in trusted chrome.
○ Idle. Click Animate authenticated flow below to step through the protocol.
Per-counterparty key derivationlive values from your last send
per_counterparty_key = HMAC-SHA-256(sender_secret, recipient_id || content_hash || session_nonce)
sender_secret— send a message to populate — recipient_id— content_hash— session_nonce— → signing key—

The signing key is unique per (sender, recipient, content) tuple. A leaked key for one message-recipient pair does not compromise other messages or recipients. The recipient's verification client independently re-derives the same key from registry-published sender material plus the received recipient-id, content-hash, and nonce — confirming both origin and content integrity.

Cooperative verifier consensusBinôme architecture in action
Verifier · OpenAI
Org A · GPT-class
pending
Verifier · Anthropic
Org B · Claude-class
pending
Verifier · Mistral
Org C · Mistral-class
pending
Consensus mode: 3-of-3 unanimous. Click an animation button above to see verifiers respond.

Three verifiers from three independent operating organisations evaluate every authentication. Adversarial inputs optimised against any one verifier's training distribution still fail at the other two — the cooperative requirement is the protection. For the channel-provenance protocol, the verifiers cross-check signature validity, registry status of the claimed sender, and content-hash consistency.

Trust-mark at user-agent levelwhy the badge cannot be spoofed

The "Authenticated by ARIA — [sender name]" badge is rendered by the verification client in trusted browser/OS chrome, not in the message content area. An adversary who copies a visual badge into the message body cannot spoof the badge that appears outside the message body — recipients learn to trust the chrome-rendered badge and to ignore body-rendered images claiming the same.

This is the same protection model as TLS lock icons, OS-level OAuth consent screens, and platform-level biometric prompts. The trust UI lives in a place the page cannot draw to.

Multi-channel coveragesame primitives, every channel

Email (signature in custom header) · web (HTTP response header or meta element) · SMS / RCS (appended payload or out-of-band reference) · voice (audio-band watermark or parallel signaling) · video (frame watermark or parallel channel) · IoT telemetry (payload field) · push notifications (metadata field). The protocol is channel-agnostic. Cross-cutting modifiers — Sequence-as-Key for streaming, Binôme for high-stakes verification — apply without modification.