使用情境
TCS 處理跨產業的完整憑證生命週期。以下場景說明組織如何整合 TCS，使用 OID4VCI 預授權碼流程來發行、持有和驗證憑證。
企業員工憑證
Section titled “企業員工憑證”HR 部門透過 TCS 發行可驗證的員工憑證。員工將這些憑證儲存在錢包中，並向第三方展示 — 門禁系統、合作公司或政府機關 — 無需 HR 介入每次驗證請求。
透過選擇性揭露，員工可以向合作公司證明其職位和部門，而不必揭露員工編號或到職日期。
相關 Schema： EmployeeCredential、AccessCardCredential
核心優勢： 一旦發行，憑證就存放在員工的錢包中。驗證立即完成，無需聯繫發行組織。員工透過選擇性揭露精確控制哪些聲明被分享。
大學透過 TCS 向畢業生發行學位和成績單憑證。當畢業生求職時，雇主的驗證系統可以立即驗證憑證 — 無需致電教務處，無需等待密封成績單。
同樣的流程支援校園服務的學生證，以及獎學金申請的獎狀。
相關 Schema： UniversityDegreeCredential、AcademicTranscriptCredential、StudentIDCredential
核心優勢： 即時驗證取代了可能需要數天或數週的人工成績單申請流程。大學發行一次；畢業生可向任意數量的雇主或機構展示，無需再次聯繫大學。
KYC/AML 合規
Section titled “KYC/AML 合規”KYC 服務商驗證客戶身份後，透過 TCS 發行可驗證憑證。客戶之後可以將這張憑證展示給多家金融機構 — 銀行、交易所、保險公司 — 而無需每次重複完整的身份驗證流程。
透過選擇性揭露，客戶可以向服務供應商證明其身份驗證狀態，同時只分享最低必要欄位（例如僅提供國籍和出生日期，而不揭露完整文件號碼）。
相關 Schema： TuringCerts_Standard_KYCCredential、PassportCredential、IdentityCardCredential
核心優勢： 減少跨機構的重複 KYC 審查。客戶驗證一次，複用憑證；每家機構都能信任這份驗證，因為 TCS 提供了密碼學證明，將其連結至 Trust Registry 中原始 KYC 服務商的身份。
驗證方視角 —— 銀行客戶開戶（KYC 複用）
Section titled “驗證方視角 —— 銀行客戶開戶（KYC 複用）”此情境以驗證方為主角：銀行要為新客戶開戶，並接受由信任清單上 KYC 服務商簽發的 KYC 憑證，不必自建 OID4VP / SD-JWT 驗證堆疊。（法人開戶（KYB）流程相同 —— 目前憑證 schema 覆蓋客戶盡職調查所需欄位；純法人實體 schema 尚未提供。）
涉及服務： Verifier Service、Trust Registry、Schema Registry。
相關 Schema： TuringCerts_Standard_KYCCredential、PassportCredential。
銀行端做的事： 就兩個 API 呼叫 —— 一個建立 request、一個 poll 結果。不需要 SD-JWT 解析、不需要實作 DCQL、不需要 DID 解析、不需要簽章驗證、不需要 Trust Registry 查找。Verifier Service 把這些全做完並回傳結構化結果。
核心優勢： 把驗證方端的整合壓縮到 CRUD 形狀。銀行的風險與合規團隊審閱已驗章的展示結果，不需要稽核 SD-JWT parser。Trust Registry 保證 KYC 服務商已通過該部署的治理流程（見信任與治理）。跨機構信任不必雙邊整合。
AI 代理身份驗證
Section titled “AI 代理身份驗證”當組織開始把實際業務交給 AI agent 執行 —— 採購、排程、客戶營運、交易 —— 交易對手的第一個問題就從「這個使用者是誰？」變成「這個 agent 代表誰的授權行事？」System prompt 或自我描述回答不了這個問題，可驗證憑證可以。
在 IHV 模型中，agent 可以擔任發行方以外的任一角色：
- Agent 作為 Holder —— 組織發憑證給自己的 agent，就像發給員工一樣：在 Schema Registry 註冊 schema，claims 描述委任組織與授權範圍。Agent 以程式化方式出示憑證 —— 流程中沒有人類錢包 UI。
- Agent 作為 Verifier —— 需要審查交易對手的 agent，做的事和上方銀行開戶流程一樣：就兩個 API 呼叫 —— 建立 request、poll 結果。省略
redirect_uri即為完全 headless 流程（見驗證方 · 驗證憑證）。
整個交換就是標準 OID4VP —— 線路上不需要任何 agent 專屬協定：
Agent 端做的事： 和任何後端驗證方一樣的兩個 API 呼叫。它的決策輸入是結構化的判定結果 —— 已證明的 claims、發行方身份、發行方的 Trust Registry 狀態 —— 而不是無法驗證的自我描述。
核心優勢： 自主系統需要可以直接據以行動、事後又能被人類稽核的信任決策。密碼學驗證結果兩者兼得：agent 拿到確定性的「執行 / 不執行」依據，稽核者拿到誰簽發了憑證、發行方是否在登錄名單上、哪些 claims 被證明的可驗證紀錄。反過來也成立：agent 持有的憑證讓交易對手能驗證「這個 agent 代表誰行事？」
目前沒有 agent 專屬的 schema —— 委任授權憑證走和其他憑證類型相同的自訂 schema 註冊路徑（見信任與 Schema 治理）。