這是「有備而來：理想的數位皮夾開發報告」第五篇。本文依 2026 年 8 月 9 日至 9 月 4 日的原始碼、交接文件與 iPhone 14 真實 MyData 帳號的操作撰寫。文中截圖來自開發版 App，文件名稱與匯入時間為真，檔案內容、姓名、統一編號與地址一律未出現。MyData 平臺的制度描述引自平臺公開頁面與數位發展部新聞稿，查閱日期為 2026 年 9 月 5 日。
前四篇處理的是證件。自然人憑證、電信卡、政府卡片都有一個明確的簽發者，皮夾的工作是收下、保存、出示。本篇處理的對象沒有簽發者。MyData 平臺把戶籍、所得、投保、地籍這些資料從機關送到民眾手上，交付的是一份 PDF 或 CSV，平臺在交付後隨即刪除，八小時未領取也刪除。民眾拿到的是一份沒有簽章、沒有背書、沒有保存位置的文件。
有備而來從 8 月起把這些文件收進手機上的資料保險箱。本文記錄為什麼需要這個保險箱、儲存格式怎麼選、隱私與安全怎麼做、真實帳號用起來的結果，以及要讓這些文件在查驗端被承認還缺什麼。
MyData 的架構與它留下的缺口
MyData 平臺由數位發展部營運，2019 年上線。依 2024 年 1 月的新聞稿，平臺已介接 79 個機關、886 項資料與服務，累計使用超過 97 萬次。平臺自述的核心是「民眾自主同意、資料安全取得」，運作採三方架構。資料提供機關保有原始紀錄，平臺負責身分驗證與傳輸，服務提供者（政府機關或平臺信賴的企業）在民眾單次同意下收到資料。
這個架構有四個特徵，決定了後面所有的設計。
平臺只傳遞，不留存。 平臺隱私政策寫明「資料一旦取用後，系統將立即刪除該取得之個人資料」，未取用者「本平臺將於八小時後自動刪除」。這是正確的隱私設計，平臺不該成為第二個資料庫。代價是民眾沒有任何一個由自己控制的儲存位置。今天下載的納稅證明，下個月申請貸款時要重新驗證身分、重新申請、重新等待。
文件沒有簽章。 2026 年 8 月 9 日以真實帳號下載的戶政國民身分證資料，經逐位元組檢查，十四個 PDF 簽章標記全部為零，沒有簽章字典、沒有 ByteRange、沒有簽章表單欄位、沒有夾帶的獨立簽章。檢測工具以十一份由 pyhanko 與 pypdf 產出的真實 PDF 做過對照，含加密、物件流與「已建欄位但未簽」的邊界案例，確認這個零是文件的事實，並非工具的盲點。機關的簽章存在於 API 層，簽的是機關回覆平臺的訊息，這份簽章沒有跟著文件一起交到民眾手上。
背書只在線上流程裡成立。 MyData 的臨櫃核驗要民眾出示一組二十分鐘有效的條碼，加上簡訊或電子郵件收到的動態密碼，櫃檯人員掃碼後由平臺把文件交給櫃檯。整個流程沒有驗證民眾手上那份檔案，驗證的是平臺當下重新交付的那一份。線上服務同理，服務提供者收到的是平臺直送的資料。換句話說，MyData 的信任建立在「平臺當下傳送」這個動作上，離開這個動作，文件就只是一份 PDF。
下載是同步等待，資料是非同步產出。 個人所得資料的頁面寫明「預計下載時間約 120 分鐘」，完成後以通知告知，民眾要回到個人專區的「個人文件」下載。八小時期限從這裡開始計算。
這四個特徵合起來，就是保險箱的需求。民眾需要一個地方保存這些文件，保存時要能證明它沒有被改過，未來要能只揭露其中一個欄位，而且這個地方要比雲端硬碟或相簿更嚴格。數位皮夾已經具備每卡獨立金鑰、Secure Enclave、選擇性揭露與出示流程，是承接這個需求最自然的位置。
儲存格式的比較與決定
規劃初期評估過五種做法。比較的標準有四項。第一，能不能離線驗證。第二，能不能只揭露一個欄位。第三，能不能證明文件與下載當時一致。第四，與 App 既有的 SD-JWT-VC、OpenID4VP 堆疊是否相容。
| 做法 | 離線驗證 | 逐欄揭露 | 原檔一致性 | 與既有堆疊 | 評估 |
|---|---|---|---|---|---|
| 保存原始 PDF 或 CSV，附 SHA-256 指紋 | 可 | 不可 | 可 | 中立 | 採用，作為唯一事實來源 |
| 解析欄位後包成持有人簽署的 SD-JWT-VC | 可 | 可 | 以指紋綁定 | 完全相容 | 採用，作為衍生層，依需要產生 |
| JSON-LD VC 加 BBS+ 簽章 | 可 | 可，且不可關聯 | 需另做 | 第二套堆疊 | 保留，待不可關聯性成為硬需求 |
| ISO 18013-5 mdoc | 可 | 可 | 需另做 | 第二套堆疊 | 延後，實體 NFC 場景才需要 |
| Solid Pod（個人資料儲存協定） | 不可，驗證方要連線讀 Pod | 協定本身不提供 | 需另做 | 完全不同的層 | 不採用 |
拍板的設計有兩層。原始檔是唯一事實來源。 保險箱保存機關產出的檔案本身，連同 SHA-256 指紋與匯入時間。使用者可以隨時重新開啟、重新驗證指紋、重新下載取代、單項刪除。憑證是衍生物。 需要出示的時候，才從原始檔解析欄位，由持有人以自然人憑證或每卡金鑰簽署成 SD-JWT-VC，並在憑證裡記錄來源文件的指紋、文件類型與解析器版本。這張憑證的信任標籤固定為「持有人從 MyData 文件衍生」，畫面與查驗端都不會把它顯示成政府簽發。
早期版本走過相反的路。App 曾為了在首頁顯示保險箱文件，把每一份都自簽成一張憑證。這個做法在 8 月底被撤回，理由是自簽並沒有增加信任根。下載的檔案本來就沒有簽章，用手機金鑰重簽欄位，得到的信任不會比原檔更強，反而讓「證件」與「文件」在使用者眼中混成一種東西。撤回後的首頁把「自發國民身分證」、「政府皮夾卡片」與「MyData 資料保險箱」分成三個區塊，保險箱直接從原始檔清單，不再為顯示製造憑證。
為什麼沒有用 Solid
Solid Protocol 在規劃階段被認真評估過，因為它與「個人資料由個人控制」的目標在語言上非常接近。最後不採用，原因有三。
第一，層次不同。Solid 是儲存與存取控制的協定，規範資料放在哪個 Pod、誰可以讀。它不簽章、不做選擇性揭露、不定義憑證格式。就算採用 Solid，上面仍然要疊一層 SD-JWT-VC 或同等的憑證格式，才能回答「這個欄位是誰說的」。Solid 解決的問題與這裡要解決的問題不重疊。
第二，驗證方向相反。Solid 的模型是驗證方連線到持有人的 Pod 讀取資料，這需要一個永遠在線的伺服器與一套存取授權。數位皮夾的模型是持有人把一份自帶簽章的位元組交出去，查驗方離線也能驗。第二篇的超商取貨與第三篇的離線藍牙出示都依賴後者。引入 Solid 等於為每一次出示加上一個網路依賴與一個可用性風險。
第三，生態對齊。數位發展部的數位憑證皮夾、歐盟 EUDI 的架構參考框架，都往 SD-JWT-VC 與 mdoc 收斂。有備而來的政府卡片、驗證器與 OpenID4VP 出示已經全線走 SD-JWT-VC。保險箱沿用同一條路，不用維護第二套簽章、驗證與出示程式。
Solid 適合的場景是多方協作的動態資料，例如社群貼文、行事曆、共同編輯的紀錄。政府核發的靜態文件，需要的是不可否認的簽章與可離線的出示，這兩件事 Solid 都交給別人做。
隱私與安全的設計
保險箱處理的是 App 接觸過最敏感的資料，設計上分成兩套不同的紀律。
國民身分證資料維持銷毀原則。 戶政 PDF 含姓名、統一編號、地址、全戶成員，下載後放在暫存目錄的隔離區，解壓縮時檢查每一個項目的路徑防止 zip-slip，讀出位元組後立即清除，再進入需要使用者互動的步驟。到 App 要求輸入統一編號解密的時候，磁碟上已經沒有東西需要保護。這條路徑的產物只有一張經自然人憑證簽署的選擇性揭露憑證。
保險箱文件保存原始檔，但用同一級保護。 使用者選擇匯入的財力、投保、稅務、地籍、戶籍文件，原始檔寫入 Application Support，永遠不進 Documents，因為 Documents 會發佈到「檔案」App，任何拿到解鎖手機的人都能瀏覽、AirDrop、複製，也會進每一次 iCloud 備份。檔案保護等級設為 completeUnlessOpen，鎖定時不可讀，但允許自動鎖定後仍能完成一筆寫入。整個目錄標記為排除備份，原始紀錄不會離開這支手機。每份原始檔旁有一個中繼檔記錄寫入當下的 SHA-256，詳情頁每次開啟都重算比對，不符時明確顯示「檔案與匯入時保存的指紋不符」。
預覽不落地。 「查看原始文件」把 PDF 位元組直接交給渲染器，MyData 常見的 ZIP 包 PDF 在匯入時就解開只留 PDF，預覽過程不產生任何可被其他 App 讀到的檔案。分享是唯一讓資料離開保險箱的路徑，按下前會出現確認，寫明副本將不再受保護，請確認收件人與目的地。
常用資料只填給官方網站。 MyData 每次調閱都要輸入統一編號與出生日期。App 提供選填的「常用資料」，存在 iOS 鑰匙圈、限定本裝置、不進備份，只會自動填入 mydata.nat.gov.tw 的官方頁面，不會傳給有備而來的任何伺服器，也不會寫進任何憑證。
未完成的調閱只記錄中繼資料。 所得資料要等兩小時，這段時間不該綁著一個網頁視圖。App 記錄的待處理項目只有文件識別碼與發起時間，沒有統一編號、生日、檔名或任何欄位。八小時後自動忘記，因為平臺那邊的檔案也已經不存在，不該再對使用者說有東西在等。
取用需要解鎖。 進入保險箱要通過 Face ID 或裝置密碼，解鎖後有十分鐘寬限。刪除一份文件會同時移除原始檔與指紋中繼檔，不留孤兒。
這些設計都有對應的單元測試，其中解壓縮路徑防護、指紋比對與刪除的完整性用突變測試反向確認過，把檢查改壞時測試必須轉紅。
真實帳號的使用結果
保險箱在 9 月 1 日以真實 MyData 帳號在 iPhone 14 上完成匯入。畫面上有三份文件，地籍及實價資料、健保投保資料、財力與所得證明，全部標示「已保存原始檔」，格式為 PDF。
過程中確認了幾件只有真實帳號才量得到的事。
八個資料項目的路徑都是真的。 平臺每個項目的網址形狀一致，都是 personal/detail/API. 加一段代碼。所得、勞保投保、健保投保、健保保費、納稅證明、勞退提繳、地籍實價、現戶戶籍八個項目的代碼都從平臺本身查得，並寫進 App 的文件登錄表。學歷證明刻意排除，平臺 141 個文件項目裡沒有任何一個對應畢業或學位，教育部的學位驗證走另一套系統，屬於不同的整合。
慢文件需要可以離開的流程。 所得資料的兩小時等待證實了同步等待的設計走不通。App 改成在請求發出前就顯示預估時間，允許使用者離開，收到平臺通知後從「個人文件」入口回來繼續。同一個入口也支援連續下載多份已完成的文件，登入一次即可，平臺對每一次新的調閱仍可能要求重新驗證身分。
流程的深度是主要的可用性問題。 9 月 1 日的 UI 稽核把 MyData 匯入列為 App 最長的流程，八到十步，四層疊在一起的視窗，解密密碼輸入錯誤時提示會遞迴彈出。這些已排入修正，本文不把它們算作完成。
國民身分證那條路早已跑通。 8 月 9 日的真實下載除了量出沒有簽章，也完成了整條發證路徑，MyData 下載、行動自然人憑證簽署、離線驗證憑證鏈到 MOICA G3、存檔、首頁讀回。當時新量到的一個事實是自然人憑證裡沒有統一編號，主體名稱只有國別、姓名與一組十六位序號，離線綁定只能靠姓名。
誠實邊界
- App 不是註冊的資料需求方。 有備而來以內嵌網頁載入官方網站，由使用者本人登入與下載，所有資料都經過使用者的畫面。這條路的好處是不需要任何許可，任何人都能做；壞處是平臺任何改版都可能讓它失效，也拿不到平臺對服務提供者提供的機關簽章。
- 簽署路徑只在開發版打開。 自然人憑證的簽章需要一個服務提供者的識別與金鑰，正式版還沒有這個後端，發證與簽署整段在 Release build 關閉。
- 衍生憑證的出示尚未接上真實查驗方。 第三篇的驗證器已能驗 SD-JWT-VC，但保險箱文件衍生憑證的三個場景（所得門檻、投保狀態、居住或所有權條件）只完成規格與 App 內說明頁，沒有在兩支真機之間跑完。
- 樣本是一個帳號、一支手機。 八個項目中實際匯入三個，下載格式的逐項驗證、更新是否覆蓋同一項目、重新啟動後是否仍可見，都還要補。
- 保存明文個資本身是產品與法遵風險。 現在的保護等級是不備份、鎖定不可讀、可單項刪除，但這些是技術控制，保存必要性應定期重審，並在 App 裡讓使用者看得到自己存了什麼、存了多久。
下一步與政策建議
一、讓文件自己帶著簽章
保險箱能做到「證明檔案沒有被改過」，做不到「證明機關說過這些話」，差別在文件離開平臺時有沒有簽章。機關對平臺的簽章已經存在，缺的是把它延伸到交付物上。有兩種做法可以並行。
短期，平臺交付的 PDF 採用 PAdES 簽章，CSV 附上 CAdES 或 JWS 的獨立簽章，簽章者可以是資料提供機關，也可以是平臺以受託身分代簽並在簽章屬性中註明來源機關與調閱時間。這不改變三方架構，也不要求平臺留存資料，只是把已經在做的簽章多做一步。
中期，平臺以 OID4VCI 直接發出 SD-JWT-VC，讓數位憑證皮夾與第三方皮夾以同一套協定領取。第四篇已經指出政府卡片的欄位形狀決定了零知識證明能不能發生，MyData 若以憑證形式交付，所得區間、投保狀態這類述詞證明就有了政府簽章的基礎。
二、承認民眾需要一個保存位置
平臺八小時清除的政策應該維持，它保護的是平臺不成為第二個資料庫。但清除政策應該搭配一個明確的政策立場，民眾有權把自己的資料保存在自己控制的裝置裡，皮夾是這個位置的合理選項。這個立場可以體現在三件事。第一，平臺的「個人文件」頁面提供可被皮夾辨識的下載描述，包含文件類型代碼、產出時間、來源機關與檔案指紋。第二，數位憑證皮夾計畫把「資料保險箱」列為皮夾的功能之一，並訂出保存的最低要求，例如裝置綁定、預設不備份、單項刪除、匯出警告。第三，這些要求應對官方與第三方皮夾一體適用。
三、驗證者怎麼承認這些文件，避免它們成為孤兒
一份持有人衍生的憑證，若沒有查驗方願意收，就只是手機裡的一個檔案。這是最需要政策介入的一環。建議查驗方的設計遵守以下規則。
-
信任標籤分三級，畫面上不可混用。 「政府簽發」指憑證由機關金鑰簽署。「機關簽章文件衍生」指來源文件帶有可驗證的機關簽章，持有人的憑證綁定該簽章。「持有人衍生」指來源文件沒有簽章，憑證只證明同一位持有人簽了這項主張，且主張連到一份指紋固定的文件。查驗結果頁必須同時顯示四件事，持有人簽章是否有效、來源文件指紋、解析器版本與規則版本、信任標籤。
-
以風險分級決定接受哪一級。 低風險用途，例如租屋預審、活動報名、會員資格，可以接受持有人衍生憑證，因為它比今天普遍接受的截圖與影本強得多，多了指紋、簽章與可追溯的規則。中風險用途接受機關簽章文件衍生。高風險用途要求政府簽發，或在持有人同意下走 MyData 現有的線上重新交付。這個分級應由主管機關公布，讓查驗方有所依據，不必各自摸索。
-
憑證類型要有登錄。 每一種文件的衍生憑證應有版本化的類型識別與欄位定義，例如所得證明的稅務年度與區間述詞、投保資料的指定日期有效與否。登錄由主管機關或公協會維護，皮夾與查驗方對照同一份，述詞的邊界值、幣別與年度都要進入簽章涵蓋範圍，不能只寫在查驗方的畫面上。
-
述詞優先於原值。 查驗方應以「是否落在門檻內」、「指定日期是否有效投保」、「是否在某縣市設籍滿六個月」這類問題定義需求，皮夾只回答是非。這與第四篇的資料最少化階梯一致，也讓持有人衍生憑證在被接受的同時不必交出整份文件。
-
提供重新驗證的升級路徑。 查驗方收到持有人衍生憑證後，若需要更高保證，可以引導持有人以 MyData 現有的條碼與動態密碼流程做一次線上核驗，並把結果與剛才的憑證指紋綁在一起。這讓低保證的文件有路徑升級，不會因為第一次被拒就永遠無用。
四、相容性建議
- 對數位憑證皮夾。 公布 SD-JWT profile 與信任清單的擴充方式，讓 MyData 作為發行者能被納入。皮夾之間的出示格式已經收斂到 OpenID4VP，MyData 衍生憑證不需要新的協定，需要的是被列入信任清單的資格。
- 對 MyData 平臺。 為皮夾提供一個註冊路徑，讓皮夾以「資料需求方」身分透過正式介接領取資料，取代目前的內嵌網頁。註冊條件應公開，並允許開源的第三方皮夾申請。
- 對查驗方軟體。 第三篇的「請出示皮夾」驗證器將加入持有人衍生憑證的接受規則與結果頁的四項顯示，作為參考實作。任何查驗方都可以一鍵部署，用來測試自己的流程對這類憑證的反應。
- 對個資法遵。 保存明文文件的皮夾應公布資料保存的技術說明，包含保護等級、備份政策、刪除語意，並在 App 內提供匯出與刪除的完整紀錄。
五、治理邊界
本文的保險箱是一個開發版 App 上的實作，沒有取得任何官方介接資格。持有人衍生憑證的接受與否，最終取決於查驗方與主管機關的規則。本文提出的分級與登錄是建議，實際規則應由主管機關會同資料提供機關訂定。
接下來
- 以真實帳號補完八個項目的逐項驗證，含更新覆蓋、重新啟動後的可見性與每種格式的預覽相容性。
- 把所得門檻、投保狀態、居住條件三個衍生憑證場景在兩支真機之間跑完，並把接受規則與四項顯示寫進「請出示皮夾」驗證器。
- 壓平匯入流程，把四層視窗與遞迴的錯誤提示修掉。
- 向數位發展部提出兩個具體詢問。平臺是否有帶簽章的下載選項，以及第三方皮夾註冊為資料需求方的條件。
- 把本文的信任標籤與風險分級寫成可交給查驗方的一頁規格，附測試向量。
- 建立正式版的簽署後端，讓自然人憑證的簽章路徑離開開發版。
MyData 解決了「資料在哪個機關」的問題，沒有解決「資料在民眾手上之後怎麼辦」的問題。平臺八小時後清除是對的，文件沒有簽章是缺的，民眾需要一個保存位置是真的。數位皮夾能提供這個位置，也能把文件變成可以選擇性揭露的憑證。這些憑證會不會成為孤兒，取決於查驗方願不願意用一套公開的規則承認它們。這件事的成本很低，效果是把今天到處流傳的截圖與影本，換成有指紋、有簽章、有版本的東西。