您什么时候会使用不受保护的 JWS header？
When would you use an unprotected JWS header?
我不明白为什么 JWS 不受保护 header 存在。
对于某些上下文：未受保护的 JWS header 包含不受完整性保护的参数，只能用于 per-signature 与 JSON 序列化。
如果它们可以用作 top-level header，我可以理解为什么有人可能想要包含一个可变参数（不会更改签名）。然而，事实并非如此。
谁能想到 use-case 或知道为什么将它们包含在规范中？
谢谢！
The answer by Florent让我很不满意。
关于使用 JWT 签署文档散列的示例...断言算法和 keyID 将是需要“保护”的“敏感数据”。我想他的意思是“签名”。但是不需要对算法和keyID进行签名。
例子
假设 Bob 创建了一个签名的 JWT，其中包含一个未受保护的 header 断言 alg=HS256 和 keyid=XXXX1 。此 JWT 旨在传输给 Alice。
案例一
假设 Mallory 拦截了 Bob 发送的已签名的 JWT。 Mallory 然后创建一个新的不受保护的 header，断言 alg=None.
接收方 (Alice) 现在负责验证负载上的签名。 Alice一定不能满足于“没有签名”；事实上 Alice must not rely on a client (sender) assertion to determine which signing algorithm is acceptable for her。因此，Alice 拒绝了带有人为的“无签名”的 JWT header.
案例二
假设 Mallory 使用 alg=RS256 和 keyId=XXX1 设计了一个 header。现在 Alice 尝试验证签名并发现：
- 算法不合规
- 为该算法指定的密钥不存在
因此 Alice 拒绝了 JWT。
案例三
假设 Mallory 使用 alg=HS256 和 keyId=ZZ3 设计了一个 header。现在 Alice 尝试验证签名并发现密钥未知，并拒绝 JWT。
算法在任何情况下都不需要成为已签名 material 的一部分。没有任何情况下未受保护的 header 会导致漏洞或违反完整性。
回到最初的问题
最初的问题是：未受保护的 JWT 的目的是什么header？
简而言之，未受保护的 JWS header 的目的是允许传输一些元数据，这些元数据可用作接收方的提示。像 alg（算法）和 kid（密钥 ID）。 Florent 建议将数据填充到未受保护的 header 中可以提高效率。这不是一个很好的理由。这里是重点：未受保护的 header 中的声明是提示，不可依赖或信任。
一个更有趣的问题是：受保护的 JWS header 的目的是什么？为什么要有同时签署“header”和“有效负载”的规定？在 JWS Protected Header 的情况下，header 和有效负载被连接起来，结果被签名。假设 header 是 JSON 并且有效负载是 JSON，此时 header 和有效负载之间没有语义区别。那么为什么要签署 header 呢？
人们可以只依赖 JWS 和未受保护的 headers。如果需要 integrity-protected 声明，请将它们放入负载中。如果需要提示，请将它们放在未受保护的 header 中。签署负载而不是 header。简单。
这行得通，而且有效。但它假定有效载荷是 JSON。 JWT 是这样，但并非所有 JWS 都是这样。 RFC 7515, which defines JWS，不要求签名的有效载荷是JSON。假设有效载荷是医学扫描的数字图像。这不是 JSON。人们不能简单地“附加索赔”。因此 JWS 允许受保护的 header，这样（非 JSON）有效负载和任意声明可以被签名并检查完整性。
在有效负载为 non-JSON 且 header 受保护的情况下，无法将“额外的未签名 headers” 包含到 JWS 中。如果需要发送一些需要完整性检查的数据和一些只是“提示”的数据，那么实际上只有一个容器：protected header。提示与真实声明一起签署。
只需在 data-to-be-signed 周围包装一个 JSON 散列，就可以避免使用此 protected-header 技巧。例如：
{
"image" : "qw93u9839839...base64-encoded image data..."
}
这样做之后，可以向这个 JSON 包装器添加声明。
{
"image" : "qw93u9839839...base64-encoded image data..."
"author" : "Whatever"
}
然后将签署这些索赔并integrity-proected。
但在二进制数据的情况下，将其编码为字符串以允许封装到 JSON 中可能会显着膨胀数据。具有 non-JSON 有效负载的 JWS 避免了这种情况。
HTH
我不明白为什么 JWS 不受保护 header 存在。
对于某些上下文：未受保护的 JWS header 包含不受完整性保护的参数，只能用于 per-signature 与 JSON 序列化。
如果它们可以用作 top-level header，我可以理解为什么有人可能想要包含一个可变参数（不会更改签名）。然而，事实并非如此。
谁能想到 use-case 或知道为什么将它们包含在规范中？
谢谢！
The answer by Florent让我很不满意。
关于使用 JWT 签署文档散列的示例...断言算法和 keyID 将是需要“保护”的“敏感数据”。我想他的意思是“签名”。但是不需要对算法和keyID进行签名。
例子
假设 Bob 创建了一个签名的 JWT，其中包含一个未受保护的 header 断言 alg=HS256 和 keyid=XXXX1 。此 JWT 旨在传输给 Alice。
案例一
假设 Mallory 拦截了 Bob 发送的已签名的 JWT。 Mallory 然后创建一个新的不受保护的 header，断言 alg=None.
接收方 (Alice) 现在负责验证负载上的签名。 Alice一定不能满足于“没有签名”；事实上 Alice must not rely on a client (sender) assertion to determine which signing algorithm is acceptable for her。因此，Alice 拒绝了带有人为的“无签名”的 JWT header.
案例二
假设 Mallory 使用 alg=RS256 和 keyId=XXX1 设计了一个 header。现在 Alice 尝试验证签名并发现：
- 算法不合规
- 为该算法指定的密钥不存在
因此 Alice 拒绝了 JWT。
案例三
假设 Mallory 使用 alg=HS256 和 keyId=ZZ3 设计了一个 header。现在 Alice 尝试验证签名并发现密钥未知，并拒绝 JWT。
算法在任何情况下都不需要成为已签名 material 的一部分。没有任何情况下未受保护的 header 会导致漏洞或违反完整性。
回到最初的问题
最初的问题是：未受保护的 JWT 的目的是什么header？
简而言之，未受保护的 JWS header 的目的是允许传输一些元数据，这些元数据可用作接收方的提示。像 alg（算法）和 kid（密钥 ID）。 Florent 建议将数据填充到未受保护的 header 中可以提高效率。这不是一个很好的理由。这里是重点：未受保护的 header 中的声明是提示，不可依赖或信任。
一个更有趣的问题是：受保护的 JWS header 的目的是什么？为什么要有同时签署“header”和“有效负载”的规定？在 JWS Protected Header 的情况下，header 和有效负载被连接起来，结果被签名。假设 header 是 JSON 并且有效负载是 JSON，此时 header 和有效负载之间没有语义区别。那么为什么要签署 header 呢？
人们可以只依赖 JWS 和未受保护的 headers。如果需要 integrity-protected 声明，请将它们放入负载中。如果需要提示，请将它们放在未受保护的 header 中。签署负载而不是 header。简单。
这行得通，而且有效。但它假定有效载荷是 JSON。 JWT 是这样，但并非所有 JWS 都是这样。 RFC 7515, which defines JWS，不要求签名的有效载荷是JSON。假设有效载荷是医学扫描的数字图像。这不是 JSON。人们不能简单地“附加索赔”。因此 JWS 允许受保护的 header，这样（非 JSON）有效负载和任意声明可以被签名并检查完整性。
在有效负载为 non-JSON 且 header 受保护的情况下，无法将“额外的未签名 headers” 包含到 JWS 中。如果需要发送一些需要完整性检查的数据和一些只是“提示”的数据，那么实际上只有一个容器：protected header。提示与真实声明一起签署。
只需在 data-to-be-signed 周围包装一个 JSON 散列，就可以避免使用此 protected-header 技巧。例如：
{
"image" : "qw93u9839839...base64-encoded image data..."
}
这样做之后，可以向这个 JSON 包装器添加声明。
{
"image" : "qw93u9839839...base64-encoded image data..."
"author" : "Whatever"
}
然后将签署这些索赔并integrity-proected。
但在二进制数据的情况下，将其编码为字符串以允许封装到 JSON 中可能会显着膨胀数据。具有 non-JSON 有效负载的 JWS 避免了这种情况。
HTH