以 IHV 模型思考
開始讀任何整合指南之前，先把心智模型搞清楚。TCS 裡每一條憑證流程都至少包含三個角色裡的兩個，加上兩個治理服務，以及每個角色少數幾個 API 呼叫。 發行流程是 Issuer ↔ Holder；出示流程是 Holder ↔ Verifier；只有完整生命週期才會碰到三個角色。一旦你能說出自己正在扮演哪個角色，要叫哪支端點就變得很直覺。
一張可驗證憑證活在三個角色組成的三角中：
- Issuer（發證方）簽出憑證並交給持有者。
- Holder（持有者）把憑證收進錢包，自己決定何時、揭露哪些資料。
- Verifier（驗證方）收到出示後確認兩件事：這張憑證是不是被信任的發證方所簽？ 以及 出示的人是不是真正的持有者？
從 Verifier 回到 Issuer 的箭頭是虛線，因為驗證時並不會即時呼叫 Issuer。信任是透過 Trust Registry 離線建立的 — 這是這個模型能規模化的關鍵。
兩個治理服務
Section titled “兩個治理服務”支撐三個角色的，是兩個讓信任結構成立的服務：
| 服務 | 回答什麼問題 | 誰會用到 |
|---|---|---|
| Trust Registry | 「這個 Issuer / Verifier 有資格運作嗎？」 | 三個角色都會用 |
| Schema Registry | 「這種類型的憑證長什麼樣是合法的？」 | Issuer（寫入）、Verifier（讀取） |
少了這兩個服務，Issuer 只是在簽 JSON、Verifier 沒辦法判斷一個簽名值不值得信。有了它們，整個系統就有了「誰」與「什麼」兩件事的共同事實來源。
TCS 服務如何對應到角色
Section titled “TCS 服務如何對應到角色”對應關係取決於你跑的是哪個運作模式。TCS 預設的保管模式下，你的後端透過呼叫 TCS service 來驅動 IHV 三個角色 — 包括 Holder Service，一個以 REST API 暴露的託管錢包。非保管模式下，Holder 是 user 裝置上的外部錢包 App，你不會呼叫它。
| 角色 | 保管模式（預設） | 非保管模式 |
|---|---|---|
| Issuer | Trust Registry → Schema Registry → Credential Issuer | 同左 |
| Holder | Holder Service — 你的後端呼叫 /v1/user/*、/v1/did/*、/v1/oid4vci/*、/v1/oid4vp/*、/v1/vc/*，代替 end user 操作 | User 自己的錢包 App — 你不會呼叫，只透過 QR / deep link 把 offer 或 request 給他 |
| Verifier | Trust Registry → Verifier Service | 同左 |
不確定哪個適合你，就選保管模式 — Holder Service 是通用的雲端錢包管理 API，幾乎都能省工。完整對照（包括 holder 金鑰如何處理：放你的 secret manager、不放 TCS — 這是設計上的選擇）請見保管模式 vs 非保管模式。
選好模式後，第一個值得問的問題是：你的產品扮演哪些角色？ 一個 KYC 平台通常同時扮演 Issuer + Verifier；一家銀行對自己客戶發證會扮演 Issuer + Holder（保管）；一個政府入口可能只扮演 Verifier。
流程一 — 取得憑證
Section titled “流程一 — 取得憑證”發證流程：一個組織把憑證發給一位最終使用者。
步驟說明：
- 註冊 — Issuer 在 Trust Registry 註冊一次並取得 API key。(離線 onboarding。) 詳見 信任與 Schema。
- 定義 / 選定 Schema — Issuer 從 Schema Registry 中選一種憑證類型，或註冊新的。Schema 的識別符即為 VCT（Verifiable Credential Type） —— 例如
TuringCerts_Standard_Credential_v2_sd_jwt—— 並出現在簽出憑證的vct欄位中。詳見 Schema 參考。 - 建立 offer — Issuer 的後端把持有者的資料 POST 到 Credential Issuer 服務，TCS 回傳一組 offer URI。
- 以 code 換 token — 持有者錢包用 offer 中的 pre-authorized code 向 Authorization Server 兌換 access token。
- 取回憑證 — 錢包附上 JWT proof，向 Credential Issuer 取回簽妥的 SD-JWT 憑證，放入錢包。
流程二 — 出示與驗證
Section titled “流程二 — 出示與驗證”驗證流程：服務方要求持有者證明某件事，持有者出示後得到結果。
步驟說明：
- 註冊 — Verifier 在 Trust Registry 註冊一次。
- 定義驗證條件 — Verifier 後端建立 presentation request：要哪些 claim、接受哪些憑證類型、信任哪些 issuer。Verifier Service 回傳 deep link / QR。
- 持有者出示 — 錢包把 request 顯示給使用者，使用者選擇要揭露的 claim，錢包簽出 key-binding JWT 並送出。Verifier Service 把驗證結果回給 Verifier 後端。
Verifier 只需要處理兩支 API。所有密碼學檢查（issuer 簽名、key binding、過期、撤銷）都在 Verifier Service 內部完成。
完整整合：驗證憑證。
接下來怎麼讀文件
Section titled “接下來怎麼讀文件”確定角色與模式之後，剩下的每一頁文件不是 屬於你這個角色的 API 序列，就是 你還沒用到時可以先擱著的概念。