10 個身分協議把 KYC 變私密

以前 KYC 要你一再上傳文件，現在可以改成可重用的零知識證明。

我碰身分和合規這塊很久了，最煩的就是流程看起來很正常，實際上整個爛掉。傳護照、等審核、過關、下一個 app 再傳一次，像在重演同一齣鬧劇。每家都想留一份副本，每次換地區又要補一次文件，連自拍和地址證明都像在比誰比較會折騰使用者。更嘔的是，很多情況根本不需要把原始資料散得到處都是，卻因為整合最省事，就一路外流。

我後來開始看 zero-knowledge KYC，才真的覺得舊流程有多笨。使用者不用交出原始文件，只要證明一件事是真的：年滿 18、沒在制裁名單、是唯一真人、符合合格投資人資格、住在某個司法管轄區。這篇的起點來自 Tobi Opeyemi Amure 在 FinanceFeeds 的整理，我把它當成地圖，不當聖經。好用的地方是，它把同一個難題拆成不同團隊各自的解法。

零知識 KYC 到底省掉什麼

Web3 身分協議讓使用者在不分享原始個資的前提下，證明自己符合 KYC。

白話一點就是：app 拿到的是答案，不是你的文件。這才是重點。零知識證明讓錢包可以證明某個敘述為真，卻不透露底層資料。我要證明年滿 21，驗證端不需要知道我的生日；我要證明已做過 KYC，每個 dApp 都不必再存一次護照；我要證明自己不是機器人或羊毛黨，系統也不一定要知道我的法定姓名。

我自己在想 tokenized asset 的 onboarding 時，這個痛點特別明顯。合規團隊要確定性，產品團隊要低摩擦，使用者只想不要再傳第五次證件。舊模型逼大家選邊站，通常最後是使用者輸。ZK 身分至少給雙方一個能用的結果：驗證方拿到密碼學保證，使用者把原始資料留在比較近的地方。

還有一個常被低估的點是安全。集中式 KYC 資料庫超肥，等於把護照、駕照、地址證明堆成一個等著被打的靶子。ZK 不會讓風險消失，但它會改變風險形狀。你存得更少、暴露得更少、預設就少發很多東西出去。

實操上，我會先把 app 真正需要的 claim 拆開。不要把「KYC」當成一個東西。拆成年齡、居住地、唯一性、合格投資人、制裁狀態，還有其他政策要求。然後每一項都對應到 proof，而不是文件。你如果說不出為什麼非得拿原始檔，通常就是不需要。

• 用 proof 驗證資格，不要整包身分資料。
• 驗證問題要夠窄。
• 一開始就設計成可重用。

World ID 解的是唯一性，不是整套文件

FinanceFeeds 提到 World ID，由 Tools for Humanity 推動，靠零知識證明和 Semaphore 隱私層，讓使用者證明自己是唯一真人，卻不揭露身份。文章也提到新的 NFC 護照驗證和 World ID 4.0 的 per-app nullifier、SNARK 驗證等功能。

白話一點就是，World ID 不是想當你的完整 KYC 系統。它想回答一個很煩的問題：這是不是一個真的、唯一的人。這對空投、投票、速率限制、以及任何「同一個人只能算一次」的場景很有用。Orb 很搶眼，但更值得看的其實是隱私模型。app 應該知道「這個錢包代表一個真人」，就這樣，不要多拿。

我喜歡這種切法，因為它避開一個常見錯誤：硬把一個協議做成萬能工具。唯一性、法定身分、合規審查根本不是同一題。你把它們全塞一起，最後只會得到一坨難以信任、也難以跟法務解釋的東西。World ID 比較適合用在你需要抗 Sybil，但不一定需要正式 KYC 的地方。

實操上，如果你的產品容易被重複帳號或農場攻擊，就先上一層唯一性驗證。空投、DAO 投票、claim 系統都很典型。不要把唯一性硬說成合規。如果監管真的要看身份，你還是得另外做一條正式驗證路徑。

Privado ID 比較像能上線的堆疊

FinanceFeeds 指到 Privado ID，也就是以前的 Polygon ID，底層和 Iden3、Circom 綁在一起。文章也提到 reusable credentials、selective disclosure，還有 Verifier SDK、Issuer Node、Wallet SDK 這類開發工具。

白話一點就是，Privado ID 比較像給真的要整合的人用，不是只做 demo 給你看一眼。很多身分專案我都看過停在「看，有 proof 了」這一步，然後就沒了。這很可愛，但 production 要的是發證、錢包保存、驗證，以及怎麼塞進既有政策流程。這套的好處是夠有主見，你可以發 credential、讓使用者持有、之後只驗你要的 claim。

selective disclosure 這件事，實際上比行銷文案重要太多。使用者如果已經證明過年齡或居住地，驗證端就不該拿到整份文件。這不只是隱私表演，還直接降低責任和外洩半徑。你的 app 越能接受 yes/no，而不是檔案上傳，就越少背一堆不必要的包袱。

我在想受監管的 DeFi onboarding 時，這個模式特別有用。業務想要的是「KYC 完成」，但政策真正要的是「使用者不在封鎖地區，且符合最低帳戶條件」。這兩句差很多。可重用 credential 可以滿足政策，卻不用把一堆額外身分資料拖進系統。

實操上，如果你做的是會反覆驗證的 app，就直接以 reusable credential 為中心設計。issuer / verifier 分工要清楚，wallet 端 UX 要簡單到不會被客服罵。上線前，把哪些 claim 可以重用、哪些必須每次重驗，寫死在文件裡。

Human Passport 賣的是聲譽，不是政府文件

FinanceFeeds 把 Human Passport（前身 Gitcoin Passport）描述成把錢包歷史、社群帳號、開發者活動和已驗證 attestations 組成隱私保護型聲譽分數的協議。文章還寫到它有超過 3400 萬個零知識憑證、約 200 萬使用者，並協助保護超過 2 億美元的空投免於 Sybil 攻擊。

白話一點就是，不是每個身分問題都需要掃護照。有時候你要的是信任訊號，這是另一種東西。空投、補助、社群門禁，很多時候在意的不是你的法定身分，而是同一個人不要假裝成五十個人。Human Passport 有意思的地方在於，它把身分當成一組訊號，而不是單一政府文件。

我一直覺得這種做法很適合社群系統，因為它比較接近線上信任的真實樣子。沒人只靠一張文件認識你，大家看的是行為、歷史、背書，再加上一點點運氣。關鍵是怎麼做得不變成監控湯。你如果能在保留底層訊號隱私、或至少最小揭露的前提下算出聲譽，整體 tradeoff 會漂亮很多。

實操上，聲譽適合拿來做 anti-abuse，不適合拿來做法遵 onboarding。補助、投票、獎勵機制都很對味。規則要能接受身分不完美，因為聲譽本來就是機率式的。還有，分數就是分數，不是法律身分查核，這點要講白。

• 適合：anti-Sybil、社群門檻、獎勵。
• 不適合：需要正式身分的受監管 onboarding。
• 最好搭配：另外一條合規驗證流程。

zkPass 把 Web2 登入變成可攜 proof

FinanceFeeds 說 zkPass 用 TransGate extension 和 zkTLS，把登入中的 Web2 session、銀行帳戶、交易所或既有 KYC 供應商轉成可攜的零知識證明。文章也提到它有一套 Compliance Suite，主打 GDPR 和 CCPA 友善的 KYC 給 fintech 與交易所。

白話一點就是，zkPass 想把你已經拿得到的資料解鎖，而不是逼使用者把同一份東西重新上傳到新系統。這招很實際。如果某人已經在銀行、交易所或薪資平台做過 KYC，為什麼到了 Web3 app 還要重交一次？proof 可以跟著走，原始資料不用跟著跑。

我會喜歡 zkPass，是因為它比較像橋，不像要你整個重寫的潔癖方案。很多團隊根本不是從零開始，他們早就有 Web2 身分 rails、瀏覽器 session、老舊的合規供應商。這種情況下，zkPass 的價值是把既有系統接到鏈上驗證，而不是逼你一次改到底。

實操上，如果你的使用者本來就活在既有 identity provider 裡，就用 Web2-to-Web3 proof layer。不要讓他們把同一件事證兩次。最容易先落地的通常是帳號年齡、交易所狀態、銀行關係、KYC 完成狀態。如果你的流程本來就依賴 browser session，這是少數不太痛的抽證方式。

Civic 和 idOS 是我會真的想放進產品的老實貨

FinanceFeeds 把 Civic 列進來，說它是老牌身分供應商往 ZK 可重用 KYC 走；也提到 idOS，把它定位成 stablecoin 經濟的 reusable KYC layer。文章說 idOS 讓使用者只要跟有牌照的供應商驗證一次，就能把 credential 在 Aleph Zero、NEAR、Gnosis 這類鏈上重用。

白話一點就是，不是每個有用的身分產品都要長得很炫。Civic 的價值在於，舊系統還在，總有人得把它接到新世界。idOS 的價值在於 stablecoin 和 payments 這種場景，本來就最討厭重複驗證。我如果已經跟某個 licensed provider 完成一次驗證，就不想每碰一個新 app 就重做身分。

我把這兩個放一起，是因為它們處理的是比較無聊但真的會被採用的部分：延續性。一個幫你從傳統 KYC 過渡，一個幫你把結果跨 app、跨鏈重用。這種基礎設施通常不會最吸睛，但它最容易落地，因為同時幫到合規和使用者。

實操上，如果你本來就綁著舊 KYC vendor，不要因為想看起來很純就整個拔掉。先包一層 reusable credential。保留原供應商在它該在的位置，但不要讓使用者在每個產品頁面都重跑一次同樣的檢查。

Self、Humanity、zkMe、ONT ID 各走各的路

FinanceFeeds 另外列了 Self Protocol、Humanity Protocol、zkMe、ONT ID。Self 結合護照 NFC 驗證和零知識證明；Humanity 偏向掌紋生物辨識和更廣的 proof-of-trust；zkMe 把檢查留在使用者裝置上，再回傳可重用 proof；ONT ID 則建立在 W3C decentralized identifiers 和 verifiable credentials 上。

白話一點就是，這個市場根本沒有往單一路線收斂。有人要生物辨識，有人要護照驗證，有人要 standards-first 的 DID plumbing，有人想把事情盡量留在裝置端。這很正常，因為身分需求本來就很亂。代幣銷售、穩定幣 app、DAO 投票系統，本來就不該用同一種信任模型。

我會把這些協議看成是在決定「信任放哪裡」。在裝置端驗證可以降低後端暴露；護照式驗證適合正式身分；DID / VC 標準路線有利於可攜和互通；生物辨識可能幫助唯一性，但使用者接受度和資料敏感度也更高。這裡沒有白吃的午餐，只有不同代價。

實操上，先看 claim，再看 logo。你如果需要標準相容性，就找 DID 和 VC 支援；你如果需要唯一性，就看 proof-of-personhood；你如果需要金融場景的可重用合規，就看 credential portability 和 issuer 工具；你如果要跟既有 onboarding 接軌，就先選橋，不要先選夢。

可抄的模板

# Zero-Knowledge KYC 選型模板

## 1) 我到底要證明什麼？
- [ ] 唯一真人
- [ ] 年滿門檻
- [ ] 不在限制司法管轄區
- [ ] 合格 / 專業投資人
- [ ] 已由持牌供應商完成 KYC
- [ ] 其他：______________________

## 2) 哪種協議適合這個 claim？
- 唯一性 / 抗 Sybil：World ID, Human Passport
- 可重用合規憑證：Privado ID, idOS, zkMe
- Web2-to-Web3 proof 轉接：zkPass
- 舊 KYC 橋接：Civic
- 護照 / NFC 驗證：Self Protocol
- 標準優先 DID / VC：ONT ID

## 3) 哪些資料絕對不要離開使用者？
- 護照影像
- 駕照影像
- 法定姓名
- 地址
- 出生日期
- 帳號資訊

## 4) 驗證端到底需要什麼？
- 一個 yes/no
- 一個有期限的 claim
- 一個防重複的 nullifier
- 一個唯一性證明
- 一個司法管轄區證明
- 一個 KYC 完成證明

## 5) 整合檢查清單
- [ ] 用一句話定義政策規則
- [ ] 每條規則都對應到 proof，不是文件
- [ ] 決定 proof 在哪裡簽發
- [ ] 決定 proof 在哪裡保存
- [ ] 決定 proof 多久失效
- [ ] 決定 proof 是 app-scoped 還是可重用
- [ ] 決定怎麼撤銷或更新 credential
- [ ] 決定後端要記錄什麼

## 6) 我會用的產品規則
如果 app 可以用密碼學 claim 解決，就不要要原始檔。
如果 app 真的需要原始檔，就寫清楚原因和可見權限。

## 7) 範例 policy mapping
Policy：只有年滿 18 且位於允許國家/地區的使用者才能使用 app。

Required proof bundle：
- 年滿 18
- 國家 / 居住地 claim
- 來自核准 issuer 的有效 KYC credential
- 若是 one-account-per-user 流程，可加 nullifier

Verifier response：
- allow
- deny
- reverify
- manual review

## 8) 可直接貼進 PRD 的決策註記
我們會在可用密碼學 claim 表達的地方接受零知識憑證作為身分驗證。
只有在無法用其他方式驗證時，才要求原始身分文件。
我們會優先使用可重用憑證、選擇性揭露、app-scoped nullifier，而不是重複上傳文件。
我們會記錄驗證結果，不記錄敏感原始文件。

這段模板我真的會直接丟給 PM、法遵或工程，在 kickoff 前先對齊。它會逼大家把討論從「哪家 vendor 比較強」拉回來，變成「我們到底在證明什麼，哪些資料可以少收」。這才是正事。其他東西，說穿了都是實作細節。

FinanceFeeds 的原始整理在這裡：https://financefeeds.com/10-best-web3-identity-protocols-for-zero-knowledge-kyc-verification/。我這篇是根據那份整理，加上各專案官方文件做的拆解；框架、取捨分析和可抄模板是我自己整理出來的。