使用情境
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 服務商已通過該部署的治理流程（見信任與治理）。跨機構信任不必雙邊整合。