1.6k VIEWS
Pinterest LinkedIn LINE

1. RFC 9901 的誕生

2025 年 11 月 19 日，“JSON Web Tokens 的選擇性披露”，又名 SD-JWT 定義 (SDJOT) 的規範 RFC 9901 它以如下形式發布：

作者是以下三位。

JSON Web Token (JWT) [RFC 7519]學生 JSON Web 簽章 (JWS) [RFC 7515]它是ID令牌雅JWT 存取權令牌 [RFC 9068]它是一種被廣泛使用的網路標準。
SD-JWT 為我們提供了新的能力，可以提取並顯示我們以後需要的部分。

在 JOSE 家族（JWS / JWT / JWE）的系譜中，
這可以看作是正式 RFC 中新增了一個名為「選擇性揭露」的支柱。

2. SD-JWT 規範是做什麼用的？

2-1. 傳統 JWT 的問題：“按需發行”或“全包式”

傳統的 JWT 是基於這樣一種模型：將「簽署 JSON 區塊」直接傳遞給服務。

  • 頒發者（身份提供者或身份驗證伺服器）將使用者資訊編譯成 JWT。
  • 接收服務（信賴方）可以讀取全部內容

這意味著，如果您使用像 OpenID Connect 這樣的模型（憑證根據需要動態頒發），就可以實現選擇性揭露、資料最小化以及 RP 之間的不可關聯性（RP+RP'-U 不可關聯性）（通常使用 PPID，即成對匿名識別碼）。但是，如果您想“預先頒發一個不知道其用途的證書，然後在以後使用它”，那麼以上所有目標都無法實現。

例如，如果一個 JWT 包含“年齡”、“地址”、“姓名”和“電子郵件地址”，服務端可能只需要知道用戶是否超過 20 歲，但如果使用預先頒發並保存的 JWT，則可以看到所有信息，包括用戶的地址和姓名。

這種「一體化」結構易於實現，但如果您想保存和使用，

  • 選擇性揭露是不可能的 = 無法滿足資料收集最小化原則
  • RP+RP'-U不可連結性也不滿足

這些是局限性（儘管這是實現簡單性的權衡）。

2-2. 與皮夾型號的兼容性

另一方面，確實存在一些需要稍後使用已儲存資料的情況。典型的例子包括在沒有信號的地方使用，或在學校放學後出示畢業證書。你可能會想，“真的有那麼常見嗎？”，但這主要是因為日本的網路環境比較優越。在歐洲，訊號品質很差，尤其是在石頭建築內，即使只是離基地台稍遠一點，即使在曼海姆這樣的大城市，戶外也可能失去訊號。當然，幅員遼闊的美國也存在著同樣的問題。或許正因如此，在歐洲， EUDI錢包 近期推出的身份錢包包括：

  • 一個錢包（智慧型手機應用程式）可以處理多筆交易 可驗證憑證 (VC) 存錢
  • 使用者選擇“僅顯示此服務的此項目”，並將其顯示出來。

這個模型是前提。在這種情況下，錢包和發卡機構只需在發行時連網即可。

這裡需要的是

“一種允許您稍後選擇並安全地顯示已儲存的簽名資料檔案的一部分的格式。”

這是由…定義的 RFC 9901 這是 SD-JWT。

3. SD-JWT 簡述

簡單來說，SD-JWT 的工作原理如下：

  1. 底座和以前一樣。 簽名 JWT (JWS)
  2. 然而，有些說法是僅哈希值在 JWT 中
  3. 將原值和鹽放在一起 揭露聲明 請將其單獨存放，僅在必要時才交給驗證者。
  4. 驗證者是
    • 根據揭露資訊重新計算哈希值。
    • 通過驗證它是否與已簽署 JWT 中的雜湊值匹配
    • 您可以確認「這確實是發行方簽署資料的一部分」。

此外，為了防止未經授權的代幣轉移， 用於關聯使用者金鑰對的機制（金鑰綁定） 也可用。
組合結構 SD-JWT+KB 叫它

4. 三個字元和 SD-JWT 的流程

SD-JWT 中的基本角色與 VC 世界相同。

  • 發行人
    政府機關、銀行、大學等。對事實負責的組織。
  • 持有者
    用戶本人將憑證保存在其智慧型手機上的錢包應用程式中。
  • 驗證者
    服務提供者，例如銀行帳戶開立、年齡驗證和門禁控制。

典型流程如下：

  1. 發行
    • 發卡機構將使用者的屬性資訊（地址、出生日期等）編譯成 JSON 格式。
    • 關於“您希望稍後選擇性披露的項目”，
      根據該值加上一個隨機鹽值計算雜湊值，並將該雜湊值嵌入到 JWT 中。
    • 原值加鹽單獨作為披露資訊編制。
    • 簽署的 JWT 和多個披露文件捆綁在一起，作為“SD-JWT”傳遞給持有人。
  2. 推介會
    • 用戶嘗試使用一項服務
    • 錢包僅從 SD-JWT 中選擇它想要向驗證者顯示的披露資訊。
    • 將已簽署的 JWT + 選定的揭露資訊 +（如有必要，還包括金鑰綁定 JWT）傳送給驗證者
  3. 確認
    • 驗證者是
      • 使用發行者的公鑰驗證 JWT 簽名
      • 使用 Disclosure 重新計算每個項目的雜湊值，並驗證其是否與 JWT 中的雜湊值相符。
    • 這樣可以確保資料是發行人簽署的資料的一部分，同時保護未揭露的內容。

5. 一些技術性討論：Salt 和披露

5-1. 使用加鹽哈希進行選擇性揭露

每項申報資料（地址、出生日期等）

  • 鹽 + 價值 + （可能是索賠名稱）

計算 JWT 的雜湊值，並將雜湊值嵌入 JWT 中。

實際揭露時，應註明為「揭露」。

  • “鹽，索賠名稱，價值”

致驗證者。

驗證器使用相同的程序重新計算雜湊值，並檢查它是否與 JWT 中的雜湊值匹配，以查看它是否已被篡改。
鹽的存在使得難以估算未揭露索賠的價值。

5-2. 揭露

RFC 將揭露定義為 Base64url 編碼的 JSON 數組，例如：

  • 元素0：鹽
  • 元素 1：宣告名稱（陣列元素可以省略）
  • 要素 2：索賠價值

錢包裡，

“將一份大型憑證作為一系列小型披露信息的集合，並且只發送你需要的信息。”

如果你這樣想的話，我覺得比較容易理解。

5-3. 按鍵綁定和 SD-JWT+KB

僅使用 SD-JWT 仍然存在被攻擊（重播攻擊）的風險，即令牌被複製並由其他人提供。
因此，RFC 9901 規定了一種將 SD-JWT 與持有者的金鑰對綁定的機制。 鍵綁定 定義：

  • 在 SD-JWT 中包含持有者的公鑰（或其引用）。
  • 持鑰匙人出示鑰匙後即可簽名。 密鑰綁定 JWT (KB-JWT) 一起寄送
  • 驗證者是
    • SD-JWT 和 KB-JWT 綁定到同一個金鑰
    • 確認持有者確實擁有私鑰。

現在需要按鍵綁定。 SD-JWT+KB 這將提高對創投抄襲的抵抗力。

注意持有者綁定可以是密鑰綁定、聲明綁定或生物識別綁定。 +KB 實作了金鑰綁定。但是，使用金鑰綁定時，如果儲存金鑰的裝置或其他媒體被轉移，則可能有人會冒充您（這稱為 Alice-to-Bob 攻擊）。買賣銀行帳戶就是一個典型的例子。為了防止這種情況，通常需要使用生物辨識綁定。

5-4. 對 JSON 結構和陣列的支持

RFC 9901 超越了簡單的扁平 JSON。

  • 嵌套對象
  • 逐元素揭露數組
  • 使用“虛擬雜湊（誘餌摘要）”隱藏模式

它還規定瞭如何處理此類案件。

這個

  • 防止人們猜測「每個人都擁有相同的資格」。
  • 降低僅憑揭露物品數量而被追蹤的風險

這使得提出諸如此類的想法成為可能：

6. SD-JWT 和 VC 身份錢包

6-1. SD-JWT VC：定位為 VC 格式

IETF 在 RFC 9901 中使用 SD-JWT。 用於表達可驗證憑證的規範 として
“基於 SD-JWT 的可驗證憑證 (SD-JWT VC)” 草案正在擬定中。

這是

  • JSON 格式的 VC
  • SD-JWT允許選擇性披露
  • 確定驗證方法

這是一份具有以下作用的規範。目前，該工作小組正在進行最終定稿前的審查，我也是審查員之一。約 28 處編輯改進（部分建議可能涉及技術方面。）（這些建議包括：簡化美國人或德國人寫作時冗長難懂的句子；解決因過度使用被動語態而導致的義務執行人身份不明的問題；以及考慮安全性、隱私性和公平性。）此外，為了驗證規範草案中包含的示例，我們創建了一個靜態 HTML/JavaScript 頁面。sd-jwt-decoder「 也被創建了。它也已在 GitHub 上發布。（它只是一個 HTML 頁面，因此可以輕鬆地在本地運行——我需要在飛機上驗證草稿），所以如果您發現任何錯誤，請提交拉取請求。

6-2. 與 EUDI 皮夾一起使用

歐盟委員會 EUDI架構參考框架（ARF） 因此，歐洲數位身分錢包將採用的標準是：

  • 用於可驗證憑證的 OpenID (OpenID4VCI / OpenID4VP)
  • SD-JWT / SD-JWT VC
  • ISO/IEC 18013-5 行動駕駛執照 (mDL)

已經證明，可以使用以下幾種方法的組合。

在此背景下，RFC 9901 規定：

“儲存在身分錢包（例如 EUDI 錢包）中的 VC”
基於 JWT/JOSE 實現的核心格式

它的位置如下。

6-3. 從錢包使用者角度來看的好處

整體使用者體驗大致如下：

  • 年齡確認
    在便利商店，你只需要提供你已年滿 20 歲的信息，而不需要提供你的出生日期。
  • 地址驗證
    僅提供線上購物網站所需的收貨地址，並隱藏其他屬性
  • 了解你的客戶 (KYC)
    僅向銀行和證券公司提供必要的屬性，並將相同虛擬電腦用於其他服務。

這一切都歸功於 SD-JWT 的特性，它允許你將單一簽名資料分解成更小的部分，並只提取你需要的部分。

7. 生態系的擴展（概述）

一些開源軟體和商業解決方案已經將 SD-JWT/SD-JWT VC 整合到它們的實作中。

  • 各種錢包框架對 SD-JWT 的支援：西羅斯基金會 其中之一是 wwWallet，由…開發。
  • Authlete 和其他組織提供的 SD-JWT VC 頒發端點
  • EUDI錢包專案和SPRIND計劃的採用情況
  • OpenID 基金會開發了一種高安全性設定檔 (HAIP)，它結合了 OpenID4VC 和 SD-JWT VC。

RFC 9901 被定位為這項運動的「基礎部分」。

8.總結

  • RFC 9901 是一種網路標準，它賦予 JWT/JWS 「選擇性揭露」的能力。
  • SD-JWT 是
    • 簽署後的 JWT 只包含雜湊值。
    • 只有在必要時才會揭露原始價值和鹽度。
    • 但是，發行人的簽名仍然可以確保其真實性。
      它定義了格式。
  • 新增了按鍵綁定 SD-JWT+KB 這樣可以實現與錢包所有者綁定的安全展示。
  • 結合 SD-JWT VC 草案、EUDI ARF 和 OpenID4VC 規範，
    儲存在身分錢包中的虛擬貨幣核心格式之一 它將被用作。

這項新組件已添加到 JOSE/JWT 技術家族中，可以說，基於錢包的數位身分基礎設施的現實實現模式已經變得清晰。