OneNym代理 ID 與權杖
引用訂單與會員。
減少直接儲存個人資料。
ONENYM PLATFORM / 技術設計
完成必要操作，
減少個人資料共享。
不再在企業之間複製個人資料，
而是在受限存取下執行獲准操作。
OneNym Platform 結合代理 ID、權杖、授權與獨立保險庫，將個人資料與業務系統分離，並將使用限制在必要用途內。
01 / 架構
分離身份、許可權與資料。
業務系統處理代理 ID 和權杖。讀取與處理須經過獨立授權。個人資料儲存在獨立保險庫中，減少跨系統副本。
請求操作
↓
↓
僅允許獲准操作
驗證請求方、用途、記錄與有效期。
拒絕超出授權範圍的請求。
限制為必要資訊
↓
↓
資料保險庫
管理個人資料及對映關係。
回傳結果或有限欄位。
此圖為概念示意。代理 ID 與個人資料的對映同樣屬於需要保護的敏感資訊。
02 / 四個組成部分
透過設計減少暴露。
01 / PROXY IDENTITY
代理 ID
使用各服務專屬識別符號引用個人，而非傳遞個人資料。不同服務使用獨立 ID，可減少關聯分析與追蹤的機會。
考量：租戶及服務隔離、不可預測的 ID、輪換、刪除與對映存取限制。
02 / TOKENIZATION
權杖化
以用途限定的引用權杖替代地址或電子郵件，管理獲准操作、有效期及使用次數。
考量：被盜權杖的濫用、重複使用限制、撤銷及誰可解析權杖。簡單雜湊並不能使資料匿名化。
03 / PERMISSIONS
存取許可權
逐操作檢查條件，例如允許 A 公司為配送使用該訂單地址一次。不僅檢查登入狀態，還要確認誰可處理哪些資料、用於何種目的。
考量：租戶隔離、用途、範圍、有效期、撤銷、管理與審計。技術許可權不同於使用者同意或合同依據。
04 / DATA VAULT
資料保險庫
將個人資料與業務記錄分離，僅經受限路徑提供。共同設計加密、金鑰管理、管理許可權、備份與刪除，並根據部署環境使用 Azure Key Vault、AWS KMS 等雲端金鑰服務。
考量：金鑰與資料分離、租戶邊界、恢復、可用性、審計及留存。集中式保險庫本身可能成為高價值攻擊目標。
03 / 整合示例
無需儲存地址，即可請求配送。
這是零售商與配送服務商的設計示例。服務商整合、資料保管及使用依據需另行設計與約定。
在保險庫登記必要資料
登記收貨地址，向零售商回傳與訂單關聯的代理 ID。設計繞過零售商伺服器和日誌的輸入路徑。
簽發用途限定權杖
按訂單、承運商與有效期限制權杖。零售商傳遞權杖，而非地址。
授權配送服務商
驗證服務商身份及權杖範圍，僅回傳獲准的配送資料。
執行到期與撤銷
授權到期或被撤銷後停止後續存取。已讀取地址的刪除取決於服務商的操作及約定。
零售商留存記錄示例
訂單 ID、代理 ID、配送權杖與配送狀態。
減少直接留存的資料示例姓名、郵編及地址。賬單與客服所需留存內容應另行確定。
TECHNICAL DEEP DIVE
瞭解具體實施設計。
閱讀識別符號對映、授權、加密金鑰與刪除的具體示例。
04 / 侷限與考量
減少留存只是解決方案的一部分。
代理 ID 也需要保護
可識別或關聯個人的 ID 和權杖不會自動匿名化。需妥善管理儲存與存取。
已讀取的資料可能留存
撤銷存取不會刪除已經生成的副本或日誌。合作方需要留存與刪除政策。
可用性與職責
部署時約定故障影響、恢復、職責、資料位置及留存期限。
實施前的設計決策
明確身份驗證、授權、金鑰、審計日誌、留存、刪除、故障行為及遷移。API 與整合範圍取決於系統和業務流程。
FROM EXPOSURE TO ARCHITECTURE
從瞭解資料流開始。
Exposure Test 可評估當前存取個人資料的路徑。
聯絡我們，討論如何減少個人資料留存。