一、直覺與現實的落差
「政府資料庫介接數位憑證」看似理所當然；但事實上政府是由成百上千個分散系統構成， 權責、法源、欄位與更新週期皆不一致，介接挑戰的是整體資料治理，不是單一 API。
| 系統名稱 | 管轄單位 | 資料內容 | 更新週期 |
|---|---|---|---|
| 戶政系統 | 內政部 | 家庭、婚姻、身分資料 | 即時 |
| 財稅系統 | 財政部 | 所得、財產 | 年度 |
| 勞保系統 | 勞保局 | 投保與薪資紀錄 | 月度 |
| 社福系統 | 各縣市社會局 | 福利申請與核定資料 | 不定期（含人工） |
二、為什麼不能「直接介接」？
① 法制限制
跨系統取用必須有法源或契約；社福與個資屬高度敏感資料，無法以「預設開放」處理。
② 責任不明
簽發錯誤、不同步、資料爭議時，若權責未切分，風險無人承擔。
③ 資安風險
簽發端直連主資料庫＝每次簽發都是一次外洩風險點，違背去中心化信任精神。
三、安全介接的三層設計（Three-Tier Trust Gateway）
- 資料隔離層（Data Isolation）資料擁有機關輸出「資料視圖」，只提供必要欄位與狀態；從「資料共享」改為「結果共享」。
- 簽章授權層（Issuance Gateway）統一簽章與簽發紀錄；檢核資格、加上 Issuer DID、寫入撤銷鏈。
- 狀態查核層（Status & Revocation）提供不含個資的狀態查詢端點，驗證方僅確認「仍有效/已撤銷」。
關鍵觀念：讓資料可用、可控、可審計；而非開放直接讀取主資料庫。
四、防線一：簽章責任與金鑰管理
- 建立 Issuer Key Management Policy（分層金鑰、定期輪替）。
- 私鑰託管於 HSM；所有簽章保留不可抵賴審計軌跡。
- 金鑰失竊時：快速撤銷、重建信任鏈、廣播新公鑰。
五、防線二：最小揭露與授權紀錄
| 原則 | 落地作法 |
|---|---|
| 最小揭露 | 只回傳驗證所需欄位（例如：資格有效 / 等級 ≥ 中度）。 |
| 有痕透明 | 每次取用均有授權與資料請求紀錄，包含主體、事由、時間、欄位。 |
| 可稽核 | 發證端、查詢端、驗證端全鏈路審計，支援事件回放與追溯。 |
六、防線三：沙盒驗證與模擬測試
- 以匿名化/合成資料建立 Sandbox；模擬簽發、撤銷、狀態查核流程。
- 驗證 API 權限邏輯與錯誤處理（逾時、不同步、撤銷衝突）。
- 多機關聯測：在不接觸真實資料前提下完成串接驗證。
七、從誤區到建議模式
常見誤區
- 簽發端直連主資料庫查詢。
- 以批次匯出 CSV/Excel 作為準同步機制。
- 驗證端要求完整個資以自保。
建議模式
- 資料視圖 API + 權限控管（結果共享）。
- 簽章閘道統一簽發與撤銷登錄。
- 狀態查核端點供驗證（不見個資）。
八、小結：介接不是打通，而是劃界
核心不是「能不能讀」，而是「如何只讀必要部分且可審計」。真正的開放不是人人直連主庫， 而是每一次存取都能回答：誰、為什麼、看了什麼。
讓資料流動更有邊界，讓信任可以被驗證——這才是政府 × VC 的正確介接方式。