Signal — 渠道信任
诈骗者会在 WhatsApp 和 Telegram 上冒充银行、快递或商店。Signal 可在数秒内确认消息是否来自官方渠道。
技术现实：不对称的策略
WhatsApp Cloud API: 当一条消息被转发到企业号码时，webhook 只包含转发者的号码 context.forwarded和内容—— 绝不会有原始发送者. 对转发的 WhatsApp 消息，只能分析内容和链接；渠道归属来自发送方的声明。
Telegram Bot API: forward_origin 包含原始发送者（隐私设置除外 → MessageOriginHiddenUser）。第三方验证可以在接收端实现真正的归属，并附带一个原生徽标。
Brand Claim Boundary（基石）
每个品牌都会声明并签署自己的 官方边界: ：它所使用的域名、WhatsApp 号码、Telegram 频道和短链接，仅此而已。引擎会对照一份已签名的 allowlist，询问 该对象在边界之内还是之外 。所谓边界，就是发布在 Official Channel Log 里的那条记录。
黄金法则：注册表事实，而不是意图
SecureStamp 从不断言意图。verdict 是一个 封闭的 事实集合：
PERTENECE该渠道位于品牌已声明并签署的边界之内。NO_PERTENECE该渠道位于边界之外，可附带观察到的信号。COUNTERSTAMP品牌针对该渠道签发了一份已确认的 counter-stamp。DISPUTED该案存在争议，正在走正当程序。UNKNOWN该品牌尚未在 SecureStamp 声明边界。
这 5 个状态对应 L1–L5。强 L1 状态要求品牌签名的 counter-stamp 处于 confirmed状态；算法判定绝不会推断意图。
两个日志（TLP 模型）+ 透明度
Official Channel Log — TLP:CLEAR: 品牌对自身渠道的第一方声明。公开查询、历史与吊销。
Abuse Transparency Log — TLP:AMBER: 第三方声明。公开的只有密码学承诺和聚合计数；细节保持受限。具体个案通过对照公开树根的 Merkle 包含证明 来证实。
counter-stamp 的生命周期
这不是一份随意的黑名单：它有状态，也有正当程序。
只有 confirmed 才能启用 L1； disputed是渠道所有者的申诉路径。
Trust Receipt（ES256，共享 JWKS）
每一次验证都会产生一份 Trust Receipt: ：以 ES256 签名、带时间戳、id 为SSF-EV-…，任何人都能重新验证。它复用 SecureStamp 的公证密钥，因此第三方用与邮件邮票相同的/.well-known/jwks.json 来验证一份 receipt。请求头 typ: SSCT-receipt.
API
| POST | /api/signal/verify | 运行引擎，返回一条注册表事实 + 已签名的 Trust Receipt。 |
| GET | /api/signal/receipts/{id} | 对照公开 JWKS 重新验证一份 Trust Receipt。 |
| POST | /api/signal/brands | 声明／更新一个品牌边界。 |
| POST | /api/signal/counter-stamps | 发起一次 counter-stamp。 |
| PATCH | /api/signal/counter-stamps | 变更 counter-stamp 的状态。 |
Disclaimer: SecureStamp 认证的是某个渠道属于品牌已声明的官方边界，以及 receipt 的完整性。它不认证发送方的意图，也不认证消息内容是否属实。