煩人的帳號密碼與要交出一堆隱私的帳號復原

在開發跟使用 App 這幾年，有幾點我到現在還是覺得很煩躁。

第一個是，大部分的 App 設計上還是需要帳號密碼登入。這個時代，誰還記得自己的帳號密碼是什麼？雖然有 Keychain 和 AutoFill 可以幫忙，但還是有很多例外。例如，有些 App 把登入流程放在內嵌網頁；有些頁面除了帳號、密碼，還有社群登入和其他登入方式。沙盒機制與缺乏正確的網域關聯，自動填寫在這種地方就幫不上忙。每次看到這類頁面，我都一頭霧水：誰會記得幾個月前用了什麼方式登入？

或像是台灣的金融機構，常常要求三種資料的組合必須正確：身分證字號、使用者名稱和密碼。有些金融機構的使用者名稱在實作上也需要遮蔽，意思其實就是使用者名稱是第一個密碼，原本的密碼是第二個密碼。在我遇過的流程裡，iPhone 當下把遮蔽的使用者名稱當成密碼來解讀和儲存，真正的密碼卻沒有存下來。最後，我還是得在某個地方寫下真正的密碼。這真的很笨。

第二個是，App 常會要一些額外資訊，例如用 email 或電話收確認碼。最主要的理由是確認你是個真人，以及在你忘記帳號密碼時協助復原。這種情況常出現在工具類的 App。

第三個是，有些 App 會要更敏感、更細節的資料，像是身分證字號、名字或地址。其中一個目的是確認你在他們的系統裡只註冊一次。但我常常在想，為什麼我要為了一個超市的 App，給出我的名字跟身分證字號，只為了讓你確認我沒有註冊兩次？對，我在說你，全聯。我只是買個東西而已。

Passkey 能幫忙，但帳號復原還是必要的

第一個問題，技術上的解決方案就是 Passkey。Passkey 本身不需要和個人資料綁在一起，使用者也不用記任何東西。它把原本得放在腦袋裡的秘密，交給身邊的裝置管理，因此不需要像密碼那樣的「忘記 Passkey」流程。但是，既然憑證存在裝置或軟體裡，就可能遇到完全無法取回的情況，所以帳號復原的設計還是必要的。

第二個問題帳號復原與確認真人，以及第三個問題確認一個人在系統內只有一個帳號。這些常見做法都是依賴個人資訊。我常常在想，大家是不在意給出資料，還是在意，但是使用服務的誘因很強，所以願意交換？還是每個 App 都這樣，啊不然怎麼辦？

一個構想：應用程式專屬的 Signature VC

在利用 可驗證憑證（Verifiable Credentials，VC） 開發了幾個服務後，我開始覺得，以官方身分文件驗證為基礎的 VC，或許是個更好的解決方向：保護隱私，同時協助處理帳號復原、真人驗證和系統內的唯一性。以下是我想探索的構想。

我的人格憑證系統已經可以驗證護照，並簽發 Anchor Credential。接下來，我想嘗試在這個基礎上簽發另一份憑證，暫時稱為 Signature VC。

這個想法是，將使用者的資料，例如名字、生日和出生地，雜湊成一個只限單一應用程式使用的識別碼。利用使用者端 App 本身的 private key 和應用程式 ID 作為隱藏項，就可以產生高熵的雜湊值。應用程式可以儲存這個識別碼，在帳號復原時比對，也可以在註冊時用來確認是否已有帳號。

另外Signature VC 是否可以直接從使用者的手機端簽發？畢竟，大部分的註冊與登入流程，本來就沒有第三方的身分驗證。很多應用程式也沒有必要知道使用它的人到底是誰，也許只需要知道：「這是同一個人，而且這個人已經通過驗證。」如果是這樣，應用程式是否就不需要 Anchor Credential 的鏈結，或直接驗證它？也許應用程式真正想確認的是，這份 Signature VC 確實是給該應用程式的。那麼，利用 session 綁定，再把應用程式 ID 包含在憑證內部，是否就足夠了？

這些是我想實驗的問題，還不是一套已經完成的協定。如果超市有像這樣注意隱私，我大概就會用了。我上面的推論合理嗎？會不會想得太粗糙？我正在考慮在目前的憑證交換平台上做出原型。如果我漏掉了什麼、你做過類似的系統，或有相關的技術想法，歡迎留言交流。