概覽
TCS 為你做了什麼
Section titled “TCS 為你做了什麼”1. 包裝整個協定堆疊。 TCS 負責憑證發行與驗證的協定，讓你呼叫 REST 端點而不是手刻規格。底層是 OID4VCI、OID4VP、SD-JWT VC、DPoP、JWK proof、nonce 管理 —— 名詞定義見標準與互通性。你不需要手刻 DPoP proof，也不需要自己解析 DID。
2. 提供信任錨點與治理層。 內建的 Trust Registry 回答「誰被允許發證」，內建的 Schema Registry 回答「一張合法憑證長什麼樣」。多數工具包把這兩件事丟給整合者，TCS 把它做成平台的一部分。
3. 出廠即符合標準。
發行與驗證流程都經過 OpenID Foundation 的 conformance 測試。憑證格式是 IETF SD-JWT VC（dc+sd-jwt），並透過 ES256 + X.509 支援 HAIP profile。
驗證方 — 金融機構、受監管產業、政府服務 — 透過單一 API 接收任何 TCS 信任清單上發行方所簽發的身分、KYC 或資格憑證，不必為每一家上游發行方各別接 API、各別做信任審查。Trust Registry 告訴你哪些發行方已被審核；你拿到的是已經驗章完成的結果。
發行方 — 憑證機關、雇主、學校、認證單位 — 簽發並交付你的 end user 可以在外部使用的憑證，不必自己寫 OID4VCI / SD-JWT 程式碼。
系統整合商與開發者 — 不用讀 600 頁的 OAuth 和 SD-JWT 規格，就能把發行或驗證流程接進現有產品。
兩種運作模式
Section titled “兩種運作模式”- 保管模式（推薦）— TCS 運行 Holder Service 當作以 REST API 暴露的通用雲端錢包管理服務。你的後端透過 TCS API 代表 end user 驅動 Issuer + Holder + Verifier 三個角色，不用自己寫任何 wallet-protocol 程式碼。多數 TCS 部署是這個模式。
- 非保管模式 — 持有者使用自己的標準錢包應用程式；TCS 只負責發行與驗證的介面。已經自己實作 OID4VCI / OID4VP 或要對接既有外部錢包生態系時才選。
模式只決定誰扮演 Holder 角色 — 其他都共用。完整對照請見保管模式 vs 非保管模式。
標準與符合性
Section titled “標準與符合性”| 範疇 | 標準 |
|---|---|
| 發行 | OID4VCI v1 |
| 出示 | OID4VP v1 |
| 憑證格式 | IETF SD-JWT VC（dc+sd-jwt） |
| Token 綁定 | DPoP（RFC 9449） |
| HAIP profile | 支援 ES256 + X.509 |
| 選擇性揭露 | SD-JWT _sd 機制 |
完整對照請見 標準與互通性。