跳到內容

信任與治理

可驗證憑證只有在驗證方能夠回答一個問題時才有意義:「我可以信任發行這張憑證的組織嗎?」

若缺乏信任框架,任何人都可以發行聲稱任何事情的憑證。詐騙實體可以發行假大學學歷或虛假雇用證明,這些憑證在密碼學上是有效的,但毫無意義。簽名只能證明憑證未遭竄改 — 但無法說明發行方是否值得信賴。

TCS 透過提供機器可讀的信任錨點與治理層解決了這個問題。其他平台提供憑證操作的 SDK 和函式庫,TCS 則採取根本不同的立場:它將信任和 Schema 治理作為核心基礎設施內建 — 而非選配功能。

兩個治理服務構成這個層級:Trust RegistrySchema Registry。它們共同回答了協定本身無法回答的問題:誰有資格發行? 以及 可以發行什麼?


Trust Registry 是 TCS 的信任根源。它維護一份已審核並完成註冊的認可組織名單 — 包含發行方和驗證方。

功能:

  • 為發行方和驗證方完成入駐、發行 API 金鑰,以及管理 DID 佈建
  • 為每個組織建立和管理 DID(去中心化識別符)
  • 發布每租戶的 DID Configuration 文件,讓外部各方可驗證網域與 DID 的連結
  • 強制要求只有已認可的組織才能透過 TCS 發行憑證

租戶範圍的端點:

  • 發行方元資料:/.well-known/openid-credential-issuer/:tenant
  • 網域連結:/.well-known/did-configuration.json/:tenant

治理模型:

  1. 申請(Apply) — 組織提交申請加入生態系統
  2. 審查(Review) — 申請接受審核與審查
  3. 核准(Approve) — 組織獲核准為受信任的參與者
  4. 佈建(Provision) — 向組織發行 API 金鑰和 DID
  5. 運作(Operate) — 組織可開始透過 TCS 發行和驗證憑證

組織申請加入生態系統、獲得核准,並取得 API 憑證和 DID。從此之後,它發行的每張憑證都與其在 Trust Registry 中的已驗證身份相連結。

當驗證方收到憑證時,可查詢 Trust Registry 確認發行方是一個已認可的受信任參與者 — 而非不明來源的實體。


Schema Registry 定義了憑證的外觀。它儲存標準化的憑證類型定義(稱為 VCT — Verifiable Credential Types),指定:

  • 憑證必須包含哪些欄位(必填聲明)
  • 哪些欄位是選填的
  • 每個欄位使用的資料類型
  • 哪些欄位支援選擇性揭露

為什麼重要: 若缺乏標準化 Schema,每個發行方都會以不同方式定義憑證。一所機構的大學學歷憑證可能與另一所機構的欄位名稱和結構完全不同,使自動化驗證變得不可靠。

TCS 提供橫跨 8 個類別的 28 個生產就緒憑證 Schema

類別範例
身份護照、身分證、駕照、真人驗證
教育大學學位、學術成績單、學生證、課程完成
專業員工憑證、專業認證、醫療執照
醫療疫苗接種證明、健康檢查
金融保險理賠、KYC 憑證
門禁門禁卡、會員資格、活動門票
人道主義難民身份、身心障礙狀態
平台TuringCerts 標準憑證

Schema Registry 發布並版本化這些憑證元資料合約。所有憑證類型在發行前必須完成註冊並可機器探索 — 在格式層而非僅傳輸層強制執行治理。

每個 Schema 都可透過 Schema Registry 的 API 探索,讓錢包和驗證方能自動理解任何憑證的結構。


Rendering diagram...

Trust Registry 回答「可以發行?」,Schema Registry 回答「可以發行什麼?」兩者共同構成治理層,讓可驗證憑證在規模化環境下值得信賴 — 而這個層級正是 TCS 有別於基於 SDK 的工具套件的關鍵。Trust Registry + Schema Registry 是基礎設施護城河所在。


TCS Overview -- Issuer and Verifier applications connected through TCS Governance Framework

發行方應用程式(例如 Turing Certs、票務平台、身份供應商)透過 Issuer API 連接至 TCS。驗證方應用程式透過 Verifier API 連接。雙方都與居中的 TCS 治理框架(Trust Registry + Schema Registry)互動 — 確保每張已發行的憑證都受到治理,每次展示的驗證都針對相同的信任與 Schema 規則進行校驗。持有者接收 VC 並展示 VP,完成生態系統循環。