一、從「簽發」到「審計」：信任的第二層
傳統審計強調文件可追蹤；進入數位憑證（VC）時代，文件變成資料流，但核心原則不變—— 必須可稽核、可回溯、可驗證。不同的是：VC 由個人持有、跨機構互信，審計不能侵入內容，也不能複製副本。
問題不是「把資料交出來」，而是「讓流程能被驗證」。
二、審計的目的：不是監控，而是確保信任鏈沒有斷
審計的對象不是憑證內容，而是憑證生命週期：
- 誰簽發了憑證？（Issuer）
- 依據什麼政策？（Policy）
- 是否正確撤銷/更新？（Revocation / Status）
- 誰進行了驗證？（Verifier）
- 驗證結果為何？（Result）
三、VC 審計的三種記錄層級
① 系統層稽核（System Audit）
- 記錄 API 請求、簽章、撤銷、驗證等事件。
- 欄位：timestamp、actor（金鑰辨識）、action、result。
- 用途：資安監控與系統健康，不含個資。
② 政策層稽核（Policy Audit）
- 映射「此張 VC 依據哪一版政策簽發」。
- 範例：低收 VC 對應某條文/命令之版本。
- 用途：合規可驗證、避免主觀裁量。
③ 匿名化紀錄層（Anonymized Trace）
- 欄位建議：vc_hash、issuer_id、issue_time、revoke_time、verifier_id、verify_result。
- 以哈希/去識別方式呈現生命週期統計。
- 用途：分析信任指標，不揭露個資。
四、常見疑慮：會不會增加行政負擔？
正確導入後，稽核反而減少人工負擔：
| 傳統流程 | VC 架構下 |
|---|---|
| 人工簽章、歸檔、找文件 | 自動簽章、事件留軌、UUID/CID 直查 |
| 紙本/系統紀錄人工比對 | 稽核查驗簽章與事件鏈，不需收集文件 |
| 多系統對時困難 | DID/事件標準化，跨機關可共用稽核格式 |
| 錯誤回溯費時 | 事件索引可快速溯源（issue → verify → revoke） |
五、如何避免稽核變成「監控」？
事件匿名化
對可識別欄位進行 Hash/鹽化處理，避免還原個人身份。
權限分離
稽核單位僅可存取統計層級；個案資訊需法定程序。
去識別報表
以趨勢/比例呈現，不提供逐筆可識別紀錄。
原則：保留問責力，但不建立被動監控。
六、制度上的落地建議
- 制定 VC 稽核準則範圍、格式、留存期限、抽查機制。
- 統一事件結構採用通用事件 Schema（例：OpenAudit-like）。
- 建立稽核 API提供匿名化統計抓取，取代人工報表。
- 與資安年報整合以系統健康度呈現，而非逐筆審查。
七、小結：從「追蹤文件」到「追蹤信任」
在 VC 架構中，真正被審計的不是資料內容，而是信任如何被建立、維護與更新。 當簽發、使用與撤銷皆有跡可循，信任不再仰賴人，而由系統自證其正確。
讓稽核服務於信任，而不是侵犯隱私。
追蹤的是流程，不是個人。