選擇性 SSI——不是泛用 DIDComm 錢包

主張：標準服務保管箱，而不是取代保管箱

分散式識別符（Decentralized Identifiers）讓軟體擁有一個公開名稱，可解析成持有者能證明控制權的驗證材料。這個模式對結構化保管箱很有用：每個保管箱可以有穩定的加密外貌，用於可選的雲端驗證、聯絡人定址，以及已簽署的共用封包——而不必把 email 當成所有權的根。

NT² 選擇性地採用這個模式。

我們用保管箱金鑰 DID（did:key）作為保管箱的公開身份。我們用 peer DID 承載保管箱對保管箱的加密關係。我們從產品已持有的材料在本機解析 DID Document。我們以平台密碼學驗證簽章，並加密到協議金鑰。這些零件讓身份與共用（Share）保持誠實：保管箱能證明自己；收件人能核對誰簽署；中間人能搬運密封位元組而不讀取欄位。

我們不把 NT² Vault 做成泛用自主身份錢包。保管箱 app 不是 Verifiable Credential 發行者主控台，不是能講遍生態系訊息類型的 DIDComm 代理，也不是區塊鏈錨定的身份目錄。產品詞彙可以在釐清共用與呈現 UX 時借用 Holder／Verifier／選擇性揭露的想法。線上格式與用戶端函式庫仍保持保管箱原生。

主張濃縮成一句：選擇性 SSI 代表採用服務零知識保管箱的 DID 模式——並拒絕滑向泛用 DIDComm／VC 錢包的引力井。

這個主張與本站已有的身份與共用文章並列：多控保管箱與保管箱金鑰 DID、挑戰－回應驗證、共用密碼 ≠ 主密碼，以及盲共用中繼／本機收件匣。本文是它們底下的標準邊界。

限制：SSI 生態會把產品往「什麼都支援」拉

SSI 標準之所以強大，是因為它們瞄準錢包、發行者、驗證者與中介之間的互通。那份野心會產生產品引力。

若你把 Verifiable Credential JSON-LD 當成儲存或共用線上格式，就繼承了發行者－持有者－驗證者的世界。 狀態清單、證明套件、呈現交換，以及「匯出成 VC」會變成理所當然的需求。把登入範本與身份文件存成 W3C 憑證的保管箱，開始與專用 SSI 錢包競爭——也開始背負與本機優先密文儲存不相稱的函式庫、綱要與威脅模型。

若你在保管箱 UI 嵌入 DIDComm v2 用戶端，就繼承了路由、封裝與代理語意。 DIDComm 是給代理用的訊息堆疊。會「接受」密封封包的保管箱收件匣（Inbox）不是代理聊天產品。引入泛用 DIDComm 函式庫，等於邀請相依套件暴露的每一項協定功能——即使那些功能與盲視、本機暫存，或「接受是裝置上的門」相衝突。

若解析等於信任，釣魚就贏了。 成功把 DID URL 解析成 DID Document，只證明金鑰材料的形狀。它不證明聯絡人背後的人是誰。之所以需要帶外指紋核對與明確信任狀態，正是因為單靠密碼學不能取代人類確認。

若產品裡的「credential」意指 W3C VC，語言就塌了。 NT² 結構化的 credential 類別是登入形狀的資產範本（使用者名稱、密碼、URL）——不是 Verifiable Credential 文件。在 UI 或 API 混用兩種意思，會訓練使用者與整合者期待錯誤的匯出與錯誤的威脅模型。

若標準合規變成產品目標，保管箱就不再是保管箱。 完整 SSI 覆蓋是無限表面：更多 DID 方法、更多證明系統、更多中介、更多發行者角色。零知識個人保管箱需要有限表面：本機解鎖、儲存結構化密文、在明確邊界下共用、可選地盲同步與盲中繼。

因此限制是架構性的，不是美學性的。我們在標準能降低保管箱身份與共用歧義的地方取用它們。我們拒絕那些會把瀏覽器保管箱 UI 拉成泛用身份代理的標準負載與用戶端堆疊。

設計：三層——身份、訊息、傳遞

NT² 把標準接觸點分成三層，讓每一層都能保持誠實。

flowchart TB
  subgraph identity [身份]
    KeyDid[保管箱金鑰 DID]
    PeerDid[每個連線的 Peer DID]
    Doc[本機 DID Document]
  end
  subgraph messaging [訊息]
    Env[NT² 共用／收件匣信封]
    Thread[執行緒關聯]
  end
  subgraph delivery [傳遞]
    Relay[盲中繼]
    File[檔案／QR／貼上]
  end
  identity --> messaging
  messaging --> delivery

身份層。 保管箱金鑰 DID 是保管箱簽署金鑰的公開外貌。可選雲端 API 以該 DID 做挑戰－回應驗證——不是可重設的 email 登入。安全聯絡人以保管箱金鑰 DID 定址其他保管箱。共用封包可被簽署，讓收件人驗證來源。Peer DID 把加密材料綁定到特定的保管箱對保管箱連結，使 Mode A 傳遞加密給該關係，而不是重用主機密。我們支援的方法在本機解析：DID URL 與連線材料已足夠；開啟保管箱不依賴全域 DID 目錄。

訊息層。 收件匣列與共用封包使用 NT² 信封。穩定的訊息類型 URI 與 thread 識別碼，協助整合者與未來閘道關聯請求、回應與確認。這些欄位呼應 DIDComm 的想法——執行緒、ack、帶外邀請——卻不引入 DIDComm 用戶端。產品語意上的選擇性揭露，是 Mode D 呈現與欄位遮罩：只顯示或證明當下需要的，而不是倒出整項資產。那是 Holder／Verifier 語意，卻不把資產存成 Verifiable Credentials。

傳遞層。 位元組可經盲中繼（索引密文）、.nt2share 檔案，或 QR／帶內貼上傳遞。暫存「接受」的保管箱收件匣留在裝置上。Mediator 類比有助解釋中繼；它並不授權把 DIDComm 封裝與路由函式庫送進瀏覽器保管箱 UI。

密碼學設定檔（v1）。 簽署與驗證使用 ECDSA P-256。保管箱對保管箱加密使用 ECDH P-256，再以 HKDF 進入 AES-GCM。金鑰位於本機解鎖之後。邊緣驗證簽章並搬運不透明 blob；它不會變成你人生憑證的發行者。

解析不是信任。 DID Document 解析正確的聯絡人，在使用者確認指紋或明確信任動作之前，仍是未信任。被封鎖的聯絡人不能成為共用收件人。標準給你金鑰；人仍選擇關係。

取捨：較少普遍互通，較清楚的產品

選擇性採用會犧牲一些生態系想像。

期待即插即用 DIDComm 代理的整合者，不會在保管箱 app 裡找到它。希望每項資產都匯出成 JSON-LD Verifiable Credentials 的夥伴，需要不同產品——或未來在邊界上明確決定的轉接器，而不是核心 UI 裡靜默出現的相依。假設區塊鏈錨定 DID 方法的錢包生態，在 v1 刻意排除在外。

我們也接受雙語詞彙。熟悉 SSI 的工程師會在文件與協定中認出角色與 mediator 類比。終端使用者遇見的是共用、收件匣、接受與聯絡人——不是一趟 W3C 縮寫導覽。雙語是維護成本。它仍比教每位保管箱使用者「你的密碼項目不知為何是 Verifiable Credential」便宜。

收穫是聚焦。相依重量更靠近 Web Crypto 與保管箱原生密碼學。威脅模型圍繞解鎖、信封、共用機密與盲中繼——而不是每一套 VC 證明套件與 DIDComm 路由細節。產品文案可以說「credential」指登入範本，而不承諾全域發行者。會把 VC JSON-LD 或 DIDComm 用戶端拉進保管箱 app 的架構變更，需要明確的產品與架構決策——不是順手的 npm 安裝。

互通並未放棄；它是分階段的。公開的 DID Core 概念仍是身份基底。訊息類型 URI 與本機解析，為未來在邊緣翻譯、同時讓保管箱 UI 保持為保管箱的轉接器留門。在那扇門被刻意打開之前，app 拒絕自己變成轉接器。

我們拒絕

我們拒絕把泛用 Verifiable Credential JSON-LD（或 JWT-VC）堆疊當成保管箱的儲存或共用格式交付。 資產維持為每物件信封下的結構化保管箱項目。呈現是產品模式，不是 VC 文件管線。

我們拒絕在沒有新的、明確架構決策時，於保管箱 app 嵌入 DIDComm v2 用戶端函式庫。 v1 的傳遞有盲中繼與收件匣信封已足夠。代理聊天堆疊不是免費升級。

我們拒絕把 DID 解析當成自動信任。 指紋與信任狀態仍是人類閘門。

我們拒絕把資產類別「credential」與 W3C Verifiable Credential 混為一談。 用字重要；塌陷會引來錯誤函式庫。

我們拒絕在 v1 把區塊鏈錨定的 DID 方法與全域 DID 目錄當成保管箱身份的根。 本機 did:key／peer 模式適合裝置持有的保管箱。解鎖、同步或共用都不需要錨定。

我們拒絕讓 NT² 成為人們憑證的全域發行者。 當保管箱簽署證明時，通常是使用者保管箱金鑰 DID 下的自我證明——不是 NT² 以網路權威為身份文件背書。

我們拒絕用「完整 SSI 合規」取代保管箱安全規則。 主密碼留在裝置上。金鑰在產品承諾之處保持不可匯出。中繼保持盲視。共用機密保持共用形狀。標準不能覆寫這些拒絕。

這些拒絕會讓尋找通用身份代理的人失望。它們保護尋找零知識保管箱、恰好在有幫助處使用 DID 模式的人。

結語：標準是工具，不是產品本身

選擇性 SSI 是 Null Trust² 在身份工程上的展現：取用能讓提供者保持盲視的加密證明；留下會讓提供者（或相依套件）再度居中的代理錢包表面。

務實的身份故事仍是多控保管箱與保管箱金鑰 DID。雲端證明仍是圍繞保管箱金鑰 DID 的挑戰－回應。共用密碼學仍是共用形狀的機密，而非主密碼。傳遞仍是中繼索引密文；收件匣留在本機。信任層故事——聯絡人、接受、限時揭示——仍是同一組邊界的產品語言。

我們採用服務保管箱的 DID 模式。我們拒絕泛用 DIDComm／VC 錢包。這就是寫給必須在威脅模型下——而不是口號下——選擇相依的工程師看的標準對齊。

若你想要使用身份標準、卻不變身成身份產品的保管箱，探索 NT² Vault。