憑證生命週期
TCS 不僅僅是憑證發行 API — 它是可驗證憑證的信任錨點與治理層。OID4VCI 等協定定義了如何發行憑證，但無法回答誰認證格式、誰定義 Schema，或誰維護信任清單。TCS 透過 Trust Registry 和 Schema Registry 回答了這三個問題，作為整個生命週期的治理關卡。
憑證在 TCS 中會經歷六個階段：註冊（Register）、定義（Define）、發行（Issue）、持有（Hold）、驗證（Verify）和治理（Govern）。這是一個持續循環，而非線性流程。治理決策 — 信任清單更新、Schema 修訂、發行方撤銷 — 會回饋到前期階段並觸發新的循環。
第一階段：註冊（Register）
Section titled “第一階段：註冊（Register）”在發行憑證之前，組織需向 Trust Registry 完成註冊。這確立了組織作為經過審核的參與者身份，並將所有後續操作限定在特定租戶範圍內。
註冊過程中：
- 組織提交申請並完成身份驗證
- 在 TCS 中為該組織建立具備獨立配置的租戶
- 為 TCS 服務驗證提供 API 金鑰
- 組織建立或匯入 DID 作為其數位身份
為什麼重要： 每張憑證都可追溯至已註冊的租戶，匿名發行是不可能的。
安全控制：API 金鑰防護、租戶隔離。
第二階段：定義（Define）
Section titled “第二階段：定義（Define）”在發行任何憑證之前，其類型必須先在 Schema Registry 中完成註冊。這建立了一份版本化、機器可讀的合約，描述憑證的結構與聲明內容。
定義過程中：
- 以 VCT（Verifiable Credential Type）元資料項目註冊憑證類型
- 聲明欄位、顯示屬性和版本歷史
- Schema 透過 API 可供發行方、驗證方和錢包探索
為什麼重要： 發行受到把關 — Credential Issuer 會拒絕任何引用未註冊或已棄用 Schema 的 offer。這在格式層而非僅傳輸層強制執行治理。
安全控制：Schema 治理關卡。
第三階段：發行（Issue）
Section titled “第三階段：發行（Issue）”在組織完成租戶註冊並定義好憑證類型後，便可建立一個包含待認證聲明的憑證 offer。TCS 使用 OID4VCI 協定完成簽名與交付。
流程如下（預授權碼，生產路徑）：
- 組織的後端透過 TCS API 建立憑證 offer
- offer 透過 QR Code、深層連結或推播通知交付給持有者
- 持有者的錢包用 offer 內嵌的預授權碼，向 Authorization Server 的
/v1/token端點換取 access token —— 不走 PAR、不需 PKCE、不需互動登入 - 錢包以 access token + proof JWT 向 Credential Issuer 的
/credential端點請求已簽名的 SD-JWT VC
最終結果是一張密碼學簽名、綁定至持有者 DID 的憑證。
互動式授權碼流程（PAR + PKCE + hosted login）在 roadmap 上；與上方生產路徑（預授權碼）無關。
安全控制：DPoP token 綁定（HAIP 路徑）、c_nonce 證明新鮮度、簽名信任錨點（EdDSA 或 X.509）。
第四階段：持有（Hold）
Section titled “第四階段：持有（Hold）”持有者將憑證儲存於其錢包。
- 在非保管模式下，憑證存放於持有者自己的錢包，TCS 不保留副本。
- 在保管模式（使用 Holder Service）下，TCS 代持有者儲存憑證，並提供錢包層級的存取控制。
持有者可以：
- 查看憑證中的所有聲明
- 在每次展示時選擇要揭露哪些聲明（選擇性揭露）
- 向任意數量的驗證方展示憑證
- 隨時刪除憑證
安全控制：持有者 DID 金鑰控制、每租戶錢包隔離。
第五階段：驗證（Verify）
Section titled “第五階段：驗證（Verify）”當驗證方需要確認某項聲明時，會建立一個 OID4VP 授權請求，指定所需的憑證類型和聲明。持有者的錢包以僅包含已揭露聲明的 presentation 回應。
驗證方檢查：
- 憑證簽名是否有效？（真實性）
- 憑證是否遭到竄改？（完整性）
- 發行方是否在 Trust Registry 中？（信任）
- 憑證是否已被撤銷？（狀態）
- 展示者是否為合法持有者？（綁定）
所有檢查均使用公鑰素材在本地進行 — 無需聯繫原始發行方。
安全控制：JAR 簽名請求物件、DPoP 用於 presentation、簽名與撤銷檢查。
第六階段：治理（Govern）
Section titled “第六階段：治理（Govern）”治理不是最終步驟 — 它持續在所有其他階段並行運作。Trust Registry 和 Schema Registry 是主動的治理介面，可以修改憑證發行和接受的規則。
治理操作包括：
- 更新信任清單（新增或撤銷發行方和驗證方）
- 發布新的 Schema 版本或棄用舊版本
- 透過撤銷清單撤銷個別憑證
- 維護網域連結，將 DID 身份與發行方網域綁定
當治理動作發生時，可能觸發新的循環：被撤銷的發行方必須重新註冊，Schema 更新可能需要重新發行，驗證方必須更新其政策以反映新的信任狀態。
安全控制：網域連結驗證、撤銷清單強制執行。