架構與安全性
TCS 由五個架構層組成，每個功能由專屬服務負責：
TCS 是一個由七個服務和一組共享函式庫組成的微服務平台。每個服務可獨立部署，透過 HTTP 相互通訊。共享函式庫提供通用功能，包括配置、驗證、錯誤處理和資料庫存取。
| 服務 | 用途 |
|---|---|
| Authorization Server | OAuth 2.0 token 發行、DPoP 驗證、PAR sessions、授權碼流程 |
| Credential Issuer | SD-JWT VC 發行、憑證 offer 管理、發行方元資料 |
| Holder Service | 保管錢包、DID 管理、OID4VCI/OID4VP 客戶端操作 |
| Verifier Service | OID4VP 驗證、JAR 請求物件、VP Token 驗證 |
| Trust Registry | 發行方/驗證方註冊、API 金鑰管理、DID 建立與匯入 |
| Schema Registry | VCT（Verifiable Credential Type）元資料定義與探索 |
| Scheduler | 排定維護任務的背景工作執行器 |
TCS 透過四個互補的安全層實現深度防禦，每個層級針對不同的威脅向量。
第一層：DPoP（Demonstrating Proof-of-Possession）— RFC 9449
Section titled “第一層：DPoP（Demonstrating Proof-of-Possession）— RFC 9449”DPoP 將 access token 綁定至請求的客戶端。每個 token 請求都可以包含以客戶端私鑰簽名的 DPoP proof JWT。伺服器驗證 proof 並記錄 JWK thumbprint（jkt）。之後使用該 token 的請求必須包含來自相同金鑰對的新 DPoP proof，防止 token 竊取和重播。
- 支援演算法：EdDSA、ES256
- JTI 重播保護，透過資料庫追蹤
- 伺服器發行的 DPoP nonce（HAIP v1 要求）
- Nonce、JTI 和 IAT 到期時間：各 300 秒
第二層：PKCE（Proof Key for Code Exchange）— RFC 7636
Section titled “第二層：PKCE（Proof Key for Code Exchange）— RFC 7636”授權碼流程要求使用 S256 challenge 方法的 PKCE。客戶端生成隨機的 code verifier，計算 SHA-256 challenge，並在 PAR 請求期間傳送 challenge。在 token 交換時，客戶端傳送原始 verifier，伺服器對照儲存的 challenge 驗證。這防止授權碼攔截攻擊。
第三層：簽名信任錨點
Section titled “第三層：簽名信任錨點”TCS 支援兩條憑證簽名路徑，根據發行時提供的金鑰素材自動選擇：
- EdDSA DID 路徑 — 帶有 DID 識別符的 Ed25519 金鑰；
kidheader 引用發行方的 DID 金鑰。當issuerDid和issuerPrivateKey都存在時使用。 - ES256 X.509 路徑 — 帶有憑證鏈的 P-256 金鑰；
x5cheader 攜帶完整的憑證鏈。當沒有 DID 金鑰素材時使用。HAIP v1 合規要求此路徑。
若兩個必填欄位只有其中之一，請求將被拒絕，視為不一致的簽名配置。透過 X.509 路徑發行的憑證可在無需 DID 解析的情況下進行驗證，提供以傳統 PKI 層次結構為根的信任錨點。
第四層：HMAC Nonce
Section titled “第四層：HMAC Nonce”Nonce 端點發行 HMAC 簽名的 nonce，在憑證請求時進行驗證，無需資料庫查詢。nonce 值編碼了到期時間戳，並以伺服器端密鑰簽名。這提供了無狀態的 nonce 驗證，同時維持 nonce 無法被偽造的安全保證。
TCS 使用基於路徑的路由來隔離租戶。每個已註冊的組織獲得一個唯一的租戶識別符（例如 turing、ntu），出現在發行方 URL 和元資料探索端點中。
租戶 URL 結構
Section titled “租戶 URL 結構”| 資源 | URL 模式 |
|---|---|
| Credential Issuer 識別符 | https://issuer.turingspace.co/{tenant} |
| Issuer Metadata | https://issuer.turingspace.co/.well-known/openid-credential-issuer/{tenant} |
| DID Configuration | https://trust-registry.turingspace.co/.well-known/did-configuration.json/{tenant} |
| 租戶登陸頁面 | https://issuer.turingspace.co/{tenant} |
- 資料隔離：
User模型上的tenant欄位是唯一的，作為憑證 offer 的外鍵。每個租戶的 offer、憑證配置和 DID 都限定在其使用者帳號範圍內。 - API 金鑰範圍：API 金鑰與個別使用者帳號綁定。操作時驗證 API 金鑰擁有者是否有權存取所請求的租戶資源。
- 元資料隔離：每個租戶的發行方元資料（憑證配置、顯示屬性、支援類型）根據其已登記的 Schema 獨立生成。
- 預授權碼和 API 金鑰僅以 SHA-256 雜湊值儲存；明文值永不持久化。
- 持有者密碼使用 bcrypt 雜湊。
- 憑證簽名用的發行方私鑰以加密方式儲存（Cloud SQL 加密）。
- 所有模型包含
createdAt和updatedAt稽核時間戳。
| 能力 | 狀態 |
|---|---|
| OIDF conformance testing（OID4VCI、OID4VP、HAIP） | OID4VCI passing；OID4VP processing |
| 多租戶架構 | 支援 — 每個租戶有獨立信任錨點與隔離 |
| Schema 治理 | 內建 Schema Registry，含 VCT 探索 |
| API 金鑰身份驗證 | 透過 Trust Registry 註冊取得 |
| DPoP token 綁定（RFC 9449） | 支援 |
| ISO 27001 / 27701 | 架構對齊；組織自述 |
| 保管錢包 | 透過 Holder Service 支援 |
| 憑證撤銷 | 內部支援 —— 發行端在憑證記錄上追蹤狀態。符合規格的 IETF Token Status List 在 roadmap 上；目前無對外公開的 revocation 端點。 |
| 雙簽章演算法（EdDSA + ES256） | 支援 |
| 預授權碼流程 | 支援（OID4VCI） |
| 選擇性揭露 | 支援（SD-JWT _sd 機制） |
合規與資料處理
Section titled “合規與資料處理”供採購與合規評估使用 —— 尤其在受監管產業（銀行、醫療、政府）。TCS 的資料處理立場明確列於下表。尚未實作的項目誠實標示，由 out-of-band 處理的項目則指出對應窗口。
| 項目 | 目前立場 |
|---|---|
| 基礎設施區域 | TCS 生產環境部署於 Google Cloud Platform asia-east1（台灣）。目前單一 region 部署。 |
| 資料留存區域 | TCS 託管的 Cloud SQL 中之憑證 / 租戶資料留在上述 region；未啟用跨 region 複寫。日誌與備份的處理請依此原則為基準向 TCS 確認個別流向。 |
| 個資法 / GDPR 角色 | 在典型保管模式部署下，TCS 為受託處理者（Processor），依採用機構（Controller）之指示處理資料。如需參考用 DPA 樣本，請聯絡我們。 |
| 當事人刪除權（被遺忘權） | 憑證刪除端點為軟刪除 —— 請見 Holder · 管理錢包與憑證 · 刪除憑證。實體清除（個資法 / GDPR 當事人請求）請聯繫 TCS 並提供 uuid / credential_id。 |
| 稽核日誌取得 | 應用層日誌涵蓋憑證發行（POST /v1/offers、POST /credential）、DID 生命週期（POST /v1/did、/v1/did/import）、API key 身份驗證、登入嘗試與驗證 session —— 每筆含時間戳記、租戶、request ID、結果。目前未對外提供自助式稽核日誌匯出 API，且日誌目前未做簽章 / WORM 儲存（採購團隊請於 SIEM 端規劃防竄改）。事件審查或採購證據需求請聯繫團隊取得日誌摘要。 |
| 自建部署 / 資料可攜性 | 目前不提供標準自建部署選項。終止服務時的資料可攜性（Postgres dump + 已發行 DID 之 IOTA 鏈上參照）採 out-of-band 處理 —— 請聯絡我們取得程序。 |
| 滲透測試立場 | TCS 目前未對外公布滲透測試報告。需要獨立資安審查證明的合作可在 NDA 下索取現況說明。 |
此表為採購問卷的事實依據。若你需要的項目未列於上方，請聯絡我們 —— 我們會誠實回覆，包括「尚未提供」。
維運性 —— 健康檢查、可觀測性、Runbook 立場
Section titled “維運性 —— 健康檢查、可觀測性、Runbook 立場”針對 SRE / on-call 視角的另一份誠實表格。同樣遵循「明說，包括尚未提供的項目」的原則。
| 項目 | 目前立場 |
|---|---|
| 健康檢查端點 | 每個服務開放 GET /health，回 200 OK 與 { status: "ok", service, version }。目前僅檢查 process 存活，不會探測 DB 或 IOTA 依賴。請視為 Kubernetes liveness 訊號而非 readiness gate；若需區分，請在你方加上獨立的依賴探測。 |
| 日誌 | 全服務採 Pino 結構化 JSON 日誌；每筆請求帶 request_id、tenant、service，啟用遙測時亦帶 OTel 之 trace_id / span_id。PrismaService 內建 >200ms 慢查詢日誌。 |
| Tracing / OTel | OTEL_ENABLED=true 時啟動 OpenTelemetry。預設 exporter 指向 Google Cloud Trace；HTTP、Pino、Postgres、Prisma instrumentations 已預先連接。函式庫為 @tcs/telemetry，副作用入口 @tcs/telemetry/register。對接自家後端的維運者請設定 OTEL_TRACES_EXPORTER / 端點環境變數，並驗證 trace 端到端傳遞。 |
| 速率限制 | Trust Registry 登入每 UUID 限制每 60 秒 5 次。其他端點目前無已記錄之 per-tenant 速率限制；conformance suite 或負載測試請在呼叫端自行控速。平台層級速率政策尚未公告 —— 持續性測試的預期 cadence 請事先告知 TCS 團隊。 |
| IOTA Tangle 依賴 | DID 建立（POST /v1/did）與鏈上 notarize（notarize_on_iota: true）需要 IOTA 連通。Tangle 故障期間此類呼叫會回 503；以 notarize_on_iota: false 簽出的憑證不受影響 —— 事件期間請以此為緩解。網路恢復後的重試與佇列語意目前尚未對外公告為 SLO；正式環境部署前，請與 TCS 團隊確認確切的 retry / queueing 行為。 |
| Schema 遷移 | Prisma migration 集中協調；所有服務共用同一 Cloud SQL 後端，每次 release 由 TCS 團隊執行遷移順序。自建部署者請採 migrate-first 部署模式（migration 完成後再 roll service）。原則上避免不向後相容之 migration；若不可避免會以 feature flag 包裝並附明確維運說明。 |
更深入的 on-call 協作（告警模板、儀表板匯出、容量規劃指引）請聯絡我們 —— 這些依部署量身打造，不以樣板形式公開。