從實體卡片到行動駕照，改變的不只是介面
行動駕照（mobile driver's license，mDL）是以 ISO/IEC 18013-5 為基礎的數位身分憑證。它的出現不只是把塑膠卡片換成手機畫面，而是同時改變了四件事：身分資料儲存在哪裡、身分聲明如何被證明為真、裝置憑什麼被信任，以及在沒有網路的情況下驗證要如何完成。InfoQ 刊出的這篇架構分析由 Praveen Kumar Gopalakrishnan 撰寫，把 mDL 當成企業架構與信任邊界問題處理，而不是單純的 SDK 整合問題。
對企業來說，整合 mDL 的第一印象通常很輕鬆：供應商提供少數幾個 API，例如 verifyCredential()、requestPresentation()、issueCredential()，應用程式呼叫後就取得結果。但這層抽象底下其實是一整條信任鏈，牽涉發照機關（issuer，例如監理單位）、使用者手機上的錢包（wallet）、裝置內的安全硬體、驗證方（relying party）、憑證授權單位與信任清單（trust list）。抽象本身不是缺點，多數企業也應該採用專業供應商的實作；真正的風險在於把「委外實作」誤當成「委外架構責任」。供應商可以讓一個示範交易順利完成，但憑證存在哪裡、裝置金鑰如何保護、信任錨由誰控制、揭露了哪些屬性、斷線時會發生什麼事，這些問題不會因為 API 可用就自動有答案。
身分驗證與憑證簽發是兩個必須分開的階段
mDL 的生命週期可以切成兩段，兩段的參與者、信任決策與安全責任都不同。第一段是身分驗證（identity proofing），用來確認使用者確實擁有他所宣稱的身分。流程包含四步：使用者在應用程式內拍攝實體駕照的正反面並錄製活體檢測影片；影像、中介資料與影片送往驗證系統；由監理機關等權威系統以自動人臉比對官方紀錄，必要時進入人工複核；最後回傳明確的核准或拒絕結果。
第二段是憑證簽發（provisioning），負責建立硬體層級的信任。錢包用戶端在取得核准後，要求安全隔離區或硬體安全元件產生非對稱裝置金鑰；用戶端取出裝置公鑰與硬體證明用的 X.509 憑證，組成證明包；接著把裝置公鑰、公開憑證、驗證參考編號與裝置中介資料送往發照後端；發照機關將駕照屬性雜湊後綁定裝置公鑰，簽入行動安全物件（Mobile Security Object，mSO），加密憑證包再回傳；錢包以工作階段金鑰解密，把簽章後的 mSO 與金鑰寫入硬體儲存，並讓憑證可顯示給使用者。這幾個步驟合計九步，企業未必需要自己實作，但必須清楚每一步由誰執行、最終的信任決策掌握在誰手上。實務上，文件簽章、裝置證明、錢包儲存常落在供應商或裝置端，而驗證政策、稽核與資料最小化規則通常仍應由企業自行控制。把這些責任畫成一張對照表，是評估供應商時最實際的第一步。
憑證結構、密碼學與不可迴避的信任邊界
mDL 憑證不是一段單純的「身分資料」，而是結構化的密碼學聲明。ISO/IEC 18013-5 以精簡的資料表示法攜帶發照者簽章的命名空間、元素識別碼、雜湊摘要、發照者簽章、裝置金鑰資訊與有效期間。以典型文件型別 org.iso.18013.5.mDL 為例，姓名、出生日期、發照機關、證件號碼、人像與 age_over_21 等元素各自帶有 digestID 與亂數，並以 SHA-256 摘要收錄於 mSO 的 valueDigests；mSO 內同時記載 deviceKey 以及 validFrom、validUntil。這代表整合不能只檢查「能不能解析這段資料」，而要確認實作是否正確驗證發照者簽章、mSO、裝置認證與憑證鏈，是否支援選擇性揭露，是否保護敏感憑證材料，以及是否把足夠的驗證結果交還給應用程式。
線上傳輸方面，RFC 9180 定義的混合公鑰加密（Hybrid Public Key Encryption，HPKE）用於驗證方與錢包伺服器之間的直接 API 交換。它把非對稱金鑰封裝機制與對稱式認證加密結合，換取較低的延遲；文中給出的參數組合是 KEM 採用 DHKEM(P-256, HKDF-SHA256)，KDF 採用 HKDF-SHA256，AEAD 採用 AES-128-GCM。關鍵在於加密必須放進完整的信任模型來看：供應商能否說清楚加密從哪裡開始、到哪裡結束，哪些金鑰由裝置產生、哪些由後端產生，金鑰如何保護與輪替，以及哪些元件位於供應商的信任邊界之內。只宣稱「通訊已加密」卻說不清信任邊界，容易形成安全上的錯覺。
系統之間的溝通另外依賴雙向 TLS（mTLS）與完整的公鑰基礎建設。這套信任拓撲由不同壽命與用途的憑證組成：壽命十到二十年的根信任錨用於建立身分階層，通常存放於離線硬體安全模組；三到五年的發照 CA 憑證簽署各州發照金鑰；三十到九十天的文件簽章憑證簽署短生命週期的身分結構；一年的 mTLS 用戶端與伺服器憑證用於系統間 API 認證；一年的驗證終端憑證認證驗證方設備；一到三年的裝置證明憑證則驗證裝置金鑰的真實性。企業要問的通常不是供應商是否自己維運這整套基礎設施，而是哪些憑證由誰操作、哪些信任關係仍受發照機關控制，以及憑證輪替、撤銷與遭入侵時的處理責任如何劃分。
同步、非同步與離線運作
企業架構不會對所有操作使用同一種互動模式。有些動作必須在使用者面前的驗證交易中即時完成，例如近場通訊（NFC）感應驗證，或是在單一 HTTP 請求回應週期內完成的線上 API 驗證；有些則可以在背景進行，例如身分驗證的人工複核與紀錄查詢、簽發完成後的通知推送、金鑰輪替與信任清單同步。真正該做的是把每項操作對應到它的可用性需求，找出哪些功能會在供應商斷線時停擺。
既有的離線憑證出示與離線驗證，理想上不應因供應商中斷而失效；憑證簽發、線上驗證與新憑證佈建則可能必須依賴後端。信任清單同步與撤銷狀態更新通常可以延後。這個分類的用意是辨識執行期的供應商依賴與失敗邊界：一個供應商即使可用性很高，只要每筆驗證都必須連回它的線上基礎設施，它仍然是一個架構上的單點故障。
離線情境還牽涉狀態同步與隱私的平衡。離線驗證終端會快取文件簽章憑證與撤銷清單，感應時完全透過本地 NFC 完成，等到網路恢復再回傳中央日誌。mSO 內的 validFrom 與 validUntil 則是硬性界線：若離線手機的安全時鐘已超過 validUntil，讀取端必須拒絕該憑證。因此離線能力應該是評估供應商時最重要的項目之一。只在高速網路下做的展示，證明不了離線就緒程度；務實的評估應該要求供應商示範無網路下的憑證出示與驗證、快取信任材料的行為、憑證過期的處理、撤銷資訊過舊時的判斷、網路恢復後的同步、裝置時鐘異常，以及供應商本身中斷時系統如何反應。要測的是失敗架構，而不只是順利路徑。
不同場域需要不同程度的揭露
即使共用同一套基礎，不同驗證方對保證等級、屬性需求、營運限制與隱私期待都不同。機場安檢需要對照旅客名單的完整身分驗證，會要求姓名、人像、出生日期、證件號碼、發照機關與 real ID 合規標記，並以聯邦信任清單驗證文件簽章憑證、執行生物特徵人臉比對。酒類販售的年齡查核則相反，只需要 age_over_21 這個布林值與人像，姓名、地址、證件號碼與出生日期都不進入資料酬載，終端只需驗證密碼學簽章、顯示人像並產生合格狀態。這兩個例子說明為何不該用單一場景的展示來評估供應商：為機場最佳化的實作可能揭露遠超零售所需的資料，而為簡單年齡查核最佳化的供應商，可能缺乏高保證身分驗證所需的控制能力。
治理、法規與避免被單一供應商綁定
治理、隱私、安全與互通性要求，會直接決定系統如何請求屬性、保留資訊與管理金鑰材料。常見的控制項包括：資料最小化，驗證軟體只能請求交易必要的元素，商業驗證方原則上不得儲存個人可識別資訊；零追蹤保證，發照機關不得建立能追蹤使用者於何時何地出示憑證的系統；密碼學衛生，文件簽章金鑰每三十到九十天輪替，並使用 SHA-256 或 SHA-384；硬體金鑰綁定，應用程式須在安全硬體中配置生物辨識或 PIN 驗證；以及互通性合規，錢包與驗證方都須符合 ISO/IEC 18013-5。
另一個風險是過度抽象造成的長期依賴。如果應用程式的業務邏輯裡散落著供應商專屬的憑證結構與回應格式，日後要換供應商就等同重寫。比較穩健的做法是在企業與供應商之間放一層以標準為導向的抽象邊界：應用程式碼表達的是 RequestAgeOver21() 這類業務意圖，驗證結果也被正規化為企業的政策判斷，而不是直接暴露供應商的專有回應。抽象可以合理地隱藏 CBOR 序列化、APDU 建構、密碼學函式庫呼叫、NFC 工作階段處理與平台專屬的安全儲存 API；但信任錨、發照者身分、驗證結果、被揭露的屬性、憑證狀態、有效期間、撤銷狀態、供應商依賴、遙測行為、離線能力、安全邊界與失敗條件，都應該保持可見。
在導入策略上，這篇分析提出建置、採購與治理三分的決策模型。屬於企業策略與信任決策的能力應該自建，例如交易層級的揭露政策、企業授權規則、應用層身分政策、稽核需求與整合編排；具備明顯實作優勢的部分適合採購，例如錢包 SDK、協定實作、NFC 堆疊、密碼學函式庫與憑證驗證服務；而金鑰管理、憑證基礎建設、裝置證明、撤銷、遙測、隱私、可用性與互通性，即使由供應商營運，也必須留在企業監督之下。這個模型同時避開兩種極端：全部自己打造，或把整套身分系統當成不透明的第三方服務。
影響與限制
在正式上線前，企業需要驗證的是信任邊界、隱私、安全、韌性與互通性，而不只是「驗證成功」這個結果。可以用五個問題檢查：我們信任誰（發照者、錢包、裝置、供應商、驗證方、憑證授權單位、信任清單與後端服務）；我們揭露了什麼（每筆交易對應到最小必要屬性）；離線時什麼還能運作；失敗時會怎樣（過期憑證、無效簽章、無效裝置認證、已撤銷憑證、過舊信任清單、供應商中斷、網路中斷、裝置遭入侵、同步失敗）；以及能否在不重寫業務邏輯與身分政策模型的前提下更換供應商。
必須注意的是，密碼學上的正確並不自動等於隱私上的安全。一套技術上完全合規的身分系統，仍可能因為遙測、集中式狀態查詢、過度保留資料或設計不良的供應商整合而產生追蹤風險。這也是為什麼值得進一步追問：當行動身分驗證走向密碼學綁定、隱私保護與離線可用的模式時，發照機關與商業驗證方要如何同時滿足嚴格的監理稽核要求，與不鼓勵過度保留敏感個資的現代隱私法規？又該如何在維持隱私保護的撤銷與狀態查詢機制時，不創造出新的、可追蹤使用者於何時何地出示身分的管道？這些問題目前沒有標準答案，也構成 mDL 企業架構在技術之外真正的限制。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。