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 的完整性。它不認證寄件方的意圖，也不認證訊息內容是否屬實。