跳到內容
Turing Space TCS

DID — did:iota vs did:key

去中心化識別符（DID） 是一組全域唯一的識別碼，能解析出一把公鑰，且不依賴任何單一註冊機構。在 TCS 裡，DID 回答一個簡單的問題：這個實體是誰？我要怎麼驗證他們簽出的東西？

TCS 支援兩種 DID 方法。選哪一種不是美學偏好 — 兩者的成本模型、信任模型與生命週期完全不同。

DID 究竟是什麼

Section titled “DID 究竟是什麼”

DID 長這樣：did:method:identifier：

did:iota:tst:0xabc...           ← 發佈在 IOTA Tangle 上
did:key:z6Mki...                ← 公鑰直接編碼在識別符裡

解析 DID 會得到一份 DID Document — 一個 JSON，內含這個 DID 對應的公鑰與相關 metadata。Verifier 解析 issuer 的 DID、取得公鑰、用它驗證憑證簽名。

method 這一段決定 解析怎麼發生。在兩種方法之間做選擇，本質上就只是這一件事。

did:iota — 上鏈、可變、公開

Section titled “did:iota — 上鏈、可變、公開”

did:iota 把 DID Document 發佈到 IOTA Tangle。識別符指向一筆 transaction；解析就是去網路上拉最新版的 DID Document。

特性：

  • 上鏈錨點。 一旦發佈，識別符全球唯一可解析。
  • 可輪替金鑰。 DID Document 可以被更新 — 新增、移除、輪替金鑰 — 而識別符本身不變。舊憑證仍然可驗證，只要簽章金鑰保留在文件歷史中（或持續有效）。
  • 公開可發現。 拿到 DID 的人都能解析。DID 層級沒有授權機制 — 信任是由 Trust Registry 在上層疊加。
  • 演算法。 TCS 對 did:iota 使用 EdDSA。簽名帶 kid 指向 DID Document 中的某把鑰匙。
  • 成本。 發佈或更新 DID Document 是一筆 Tangle 交易。

何時使用 did:iota：

  • 你是 Issuer，需要一個穩定、公開、能熬過金鑰輪替的身分。
  • 你會註冊到 Trust Registry — verifier 預期 issuer DID 是可解析的。
  • 你的憑證需要長期可驗證，且不依賴任何單一伺服器。

did:key — 自包含、不可變、短期

Section titled “did:key — 自包含、不可變、短期”

did:key 把公鑰直接編碼進識別符。沒有要發佈的文件 — DID 本身 就是 那把鑰匙。

特性：

  • 不需註冊。 產生 keypair、把公鑰編碼，就有 DID。零基礎設施。
  • 不可變。 鑰匙無法輪替（除非產出新的 DID）。沒有「update」這個動作。
  • 自包含解析。 能解析識別符的人就能還原出公鑰，不需要網路請求。
  • 演算法。 TCS 產生 did:key 用 ES256（P-256）。需要 ES256 的 HAIP 合規流程（例如在 X.509 / x5c 發行路徑下做 holder key binding）天然對齊這個選擇。
  • 成本。 零。

何時使用 did:key：

  • 你想要一個不需要 Tangle 交易、無需註冊的 holder 身分。
  • 你想要每張憑證或每次 session 用不同的 DID（例如為了 unlinkability，定期輪替 binding key）— 每次產生新的 did:key 很便宜，不可連結性也最強。
  • 你需要短暫的拋棄式身分（測試、demo、一次性互動）。

對照表

Section titled “對照表”
屬性did:iotadid:key
解析方式IOTA Tangle從識別符解碼
可變性可（金鑰可輪替）不可（不可變）
解析需要網路是否
註冊成本一筆 Tangle 交易零
TCS 用的簽章演算法EdDSAES256（P-256）
跨金鑰輪替仍穩定是否
隱私公開Pseudonymous（每實例一組）

DID 在 TCS 裡的位置

Section titled “DID 在 TCS 裡的位置”
角色支援方法演算法DID 出現在哪
Issuer（DID 路徑）did:iotaEdDSA憑證簽名的 kid；經 Trust Registry 解析
Issuer（X.509 路徑）(沒有 DID — 改用 X.509 憑證鏈)ES256x5c header；HAIP 合規路徑
Holder（保管模式 — Holder Service）did:iotaEdDSA出示時的 key-binding JWT
Holder（非保管模式 — 外部錢包）did:iota 或 did:keyEdDSA / ES256出示時的 key-binding JWT

Issuer 必須是穩定、公開的身分，所以用 did:iota（或 X.509）。X.509 路徑（ES256 + x5c 憑證鏈）是 HAIP profile 合規的必要選擇 — 何時用 X.509 而不用 did:iota，請見架構與安全性。

Holder 取決於運作模式：

  • 保管模式 — Holder Service 為每位 end user 配置 did:iota。Holder Service 不為 binding 用途配置 did:key；POST /v1/did 端點只接受 method: "IOTA"。
  • 非保管模式 — 錢包自行產生金鑰。實作 OID4VP key binding 的錢包可以用 did:iota 或 did:key（ES256） — TCS 在驗證方端不限制此選擇，超過標準簽章驗證的範疇。

金鑰輪替與外洩 —— 目前實際支援的範圍

Section titled “金鑰輪替與外洩 —— 目前實際支援的範圍”

給安全審查者直接答案，因為上方刻意不模糊處理：

  • did:iota 支援金鑰輪替。 Tangle 上的 DID Document 可以更新加入新金鑰、移除舊金鑰；DID 識別符本身不變，使用舊金鑰簽過的憑證仍可驗證 —— 條件是 DID Document 歷史中保留了舊金鑰。
  • 目前未對外提供憑證層級撤銷端點。 詳見 標準合規性 · 路線圖，IETF Token Status List 在 roadmap 上。在此之前，輪替發行方金鑰可防止未來的濫用；無法溯及失效已用外洩金鑰簽出的憑證。
  • 目前無對外公開的金鑰輪替手冊。 若懷疑發行方金鑰外洩，請聯繫 TCS 團隊 —— 輪替程序（DID Document 更新 + Tangle 確認 + 驗證方快取刷新窗口）目前 out-of-band 處理。

這是誠實的影響範圍說明：輪替能控制前向風險；尚未有 Status List 級別的撤銷；緊急情況走 TCS 支援。

接下來

Section titled “接下來”