Internet Engineering Task Force (IETF) M. Jones
Request for Comments: 7797 Microsoft
Updates: 7519 February 2016
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) M. Jones
Request for Comments: 7797 Microsoft
Updates: 7519 February 2016
Category: Standards Track
ISSN: 2070-1721
JSON Web Signature (JWS) Unencoded Payload Option
JSON Web签名（JWS）未编码有效负载选项
Abstract
摘要
JSON Web Signature (JWS) represents the payload of a JWS as a base64url-encoded value and uses this value in the JWS Signature computation. While this enables arbitrary payloads to be integrity protected, some have described use cases in which the base64url encoding is unnecessary and/or an impediment to adoption, especially when the payload is large and/or detached. This specification defines a means of accommodating these use cases by defining an option to change the JWS Signing Input computation to not base64url-encode the payload. This option is intended to broaden the set of use cases for which the use of JWS is a good fit.
JSON Web签名（JWS）将JWS的有效负载表示为base64url编码的值，并在JWS签名计算中使用该值。虽然这使得任意有效负载能够得到完整性保护，但一些人描述了base64url编码不必要和/或阻碍采用的用例，特别是当有效负载较大和/或分离时。本规范通过定义一个选项将JWS签名输入计算更改为非base64url编码有效负载，定义了适应这些用例的方法。此选项旨在扩大JWS的使用非常适合的用例集。
This specification updates RFC 7519 by stating that JSON Web Tokens (JWTs) MUST NOT use the unencoded payload option defined by this specification.
本规范通过声明JSON Web令牌（JWT）不得使用本规范定义的未编码有效负载选项来更新RFC 7519。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7797.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7797.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The "b64" Header Parameter . . . . . . . . . . . . . . . . . 4
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Example with Header Parameters {"alg":"HS256"} . . . . . 6
4.2. Example with Header Parameters
{"alg":"HS256","b64":false,"crit":["b64"]} . . . . . . . 7
5. Unencoded Payload Content Restrictions . . . . . . . . . . . 7
5.1. Unencoded Detached Payload . . . . . . . . . . . . . . . 8
5.2. Unencoded JWS Compact Serialization Payload . . . . . . . 8
5.3. Unencoded JWS JSON Serialization Payload . . . . . . . . 8
6. Using "crit" with "b64" . . . . . . . . . . . . . . . . . . . 9
7. Intended Use by Applications . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9.1. JSON Web Signature and Encryption Header Parameter
Registration . . . . . . . . . . . . . . . . . . . . . . 10
9.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The "b64" Header Parameter . . . . . . . . . . . . . . . . . 4
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Example with Header Parameters {"alg":"HS256"} . . . . . 6
4.2. Example with Header Parameters
{"alg":"HS256","b64":false,"crit":["b64"]} . . . . . . . 7
5. Unencoded Payload Content Restrictions . . . . . . . . . . . 7
5.1. Unencoded Detached Payload . . . . . . . . . . . . . . . 8
5.2. Unencoded JWS Compact Serialization Payload . . . . . . . 8
5.3. Unencoded JWS JSON Serialization Payload . . . . . . . . 8
6. Using "crit" with "b64" . . . . . . . . . . . . . . . . . . . 9
7. Intended Use by Applications . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9.1. JSON Web Signature and Encryption Header Parameter
Registration . . . . . . . . . . . . . . . . . . . . . . 10
9.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
The "JSON Web Signature (JWS)" [JWS] specification defines the JWS Signing Input as the input to the digital signature or Message Authentication Code (MAC) computation, with the value ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload)). While this works well in practice for many use cases, including those accommodating arbitrary payload values, other use cases have been described in which base64url-encoding the payload is unnecessary and/or an impediment to adoption, particularly when the payload is large and/or detached.
“JSON Web签名（JWS）”[JWS]规范将JWS签名输入定义为数字签名或消息验证码（MAC）计算的输入，其值为ASCII（BASE64URL（UTF8（JWS保护头））| |'。| | BASE64URL（JWS有效负载））。虽然这在实践中对许多用例都很有效，包括那些容纳任意有效负载值的用例，但是已经描述了其他用例，其中base64url编码有效负载是不必要的和/或采用的障碍，特别是当有效负载较大和/或分离时。
This specification introduces a new JWS Header Parameter value that generalizes the JWS Signing Input computation in a manner that makes base64url-encoding the payload selectable and optional. The primary set of use cases where this enhancement may be helpful are those in which the payload may be very large and where means are already in place to enable the payload to be communicated between the parties without modifications. Appendix F of [JWS] describes how to represent JWSs with detached content, which would typically be used for these use cases.
本规范引入了一个新的JWS头参数值，该参数值概括了JWS签名输入计算，使base64url编码有效负载成为可选的。这种增强可能有帮助的主要用例集是有效载荷可能非常大的用例集，并且其中已经存在使有效载荷能够在各方之间进行通信而无需修改的手段。[JWS]的附录F描述了如何用分离的内容表示JWS，这些内容通常用于这些用例。
The advantages of not having to base64url-encode a large payload are that allocation of the additional storage to hold the base64url-encoded form is avoided and the base64url-encoding computation never has to be performed. In summary, this option can help avoid unnecessary copying and transformations of the potentially large payload, resulting in sometimes significant space and time improvements for deployments.
不必对大负载进行base64url编码的优点是，可以避免分配用于保存base64url编码表单的附加存储器，并且不必执行base64url编码计算。总之，此选项有助于避免对可能较大的负载进行不必要的复制和转换，从而有时大大改善部署的空间和时间。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. The interpretation should only be applied when the terms appear in all capital letters.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照“RFC中用于表示要求水平的关键词”[RFC2119]中的描述进行解释。该解释仅适用于所有大写字母的术语。
BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per Section 2 of [JWS].
根据[JWS]第2节，BASE64URL（八位字节）表示八位字节的BASE64URL编码。
UTF8(STRING) denotes the octets of the UTF-8 [RFC3629] representation of STRING, where STRING is a sequence of zero or more Unicode [UNICODE] characters.
UTF8（字符串）表示字符串的UTF-8[RFC3629]表示形式的八位字节，其中字符串是零个或多个Unicode[Unicode]字符的序列。
ASCII(STRING) denotes the octets of the ASCII [RFC20] representation of STRING, where STRING is a sequence of zero or more ASCII characters.
ASCII（字符串）表示字符串的ASCII[RFC20]表示的八位字节，其中字符串是零个或多个ASCII字符的序列。
The concatenation of two values A and B is denoted as A || B.
两个值A和B的串联表示为A | | B。
This specification uses the same terminology as the "JSON Web Signature" [JWS] and "JSON Web Algorithms" [JWA] specifications.
本规范使用与“JSON Web签名”[JWS]和“JSON Web算法”[JWA]规范相同的术语。
This Header Parameter modifies the JWS Payload representation and the JWS Signing Input computation in the following way:
此标头参数以以下方式修改JWS有效负载表示和JWS签名输入计算：
b64 The "b64" (base64url-encode payload) Header Parameter determines whether the payload is represented in the JWS and the JWS Signing Input as ASCII(BASE64URL(JWS Payload)) or as the JWS Payload value itself with no encoding performed. When the "b64" value is "false", the payload is represented simply as the JWS Payload value; otherwise, it is represented as ASCII(BASE64URL(JWS Payload)). The "b64" value is a JSON boolean, with a default value of "true". When used, this Header Parameter MUST be integrity protected; therefore, it MUST occur only within the JWS Protected Header. Use of this Header Parameter is OPTIONAL. If the JWS has multiple signatures and/or MACs, the "b64" Header Parameter value MUST be the same for all of them. Note that unless the payload is detached, many payload values would cause errors parsing the resulting JWSs, as described in Section 5.
b64“b64”（base64url encode payload）头参数确定有效负载在JWS和JWS签名输入中是表示为ASCII（base64url（JWS payload））还是表示为JWS有效负载值本身，而不执行编码。当“b64”值为“false”时，有效载荷仅表示为JWS有效载荷值；否则，它将表示为ASCII（BASE64URL（JWS有效负载））。“b64”值是一个JSON布尔值，默认值为“true”。使用时，此标头参数必须受完整性保护；因此，它必须只出现在JWS保护的头中。此标头参数的使用是可选的。如果JWS有多个签名和/或MAC，则所有签名和/或MAC的“b64”头参数值必须相同。请注意，除非分离有效负载，否则许多有效负载值将导致解析结果JWSs时出错，如第5节所述。
The following table shows the JWS Signing Input computation, depending upon the value of this parameter:
下表显示了JWS签名输入计算，具体取决于此参数的值：
+-------+-----------------------------------------------------------+
| "b64" | JWS Signing Input Formula |
+-------+-----------------------------------------------------------+
| true | ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || |
| | BASE64URL(JWS Payload)) |
| | |
| false | ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.') || |
| | JWS Payload |
+-------+-----------------------------------------------------------+
+-------+-----------------------------------------------------------+
| "b64" | JWS Signing Input Formula |
+-------+-----------------------------------------------------------+
| true | ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || |
| | BASE64URL(JWS Payload)) |
| | |
| false | ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.') || |
| | JWS Payload |
+-------+-----------------------------------------------------------+
This section gives examples of JWSs showing the difference that using the "b64" Header Parameter makes. The examples all use the JWS Payload value [36, 46, 48, 50]. This octet sequence represents the ASCII characters "$.02"; its base64url-encoded representation is "JC4wMg".
本节给出了JWSs的示例，展示了使用“b64”头参数所产生的差异。这些示例都使用JWS有效负载值[36,46,48,50]。此八位字节序列表示ASCII字符“$.02”；它的base64url编码表示为“JC4wMg”。
The following table shows a set of Header Parameter values without using a false "b64" Header Parameter value and a set using it, with the resulting JWS Signing Input values represented as ASCII characters:
下表显示了一组未使用假“b64”标题参数值的标题参数值和一组使用它的标题参数值，结果JWS签名输入值表示为ASCII字符：
+-----------------------------+-------------------------------------+
| JWS Protected Header | JWS Signing Input Value |
+-----------------------------+-------------------------------------+
| {"alg":"HS256"} | eyJhbGciOiJIUzI1NiJ9.JC4wMg |
| | |
| {"alg":"HS256","b64":false, | eyJhbGciOiJIUzI1NiIsImI2NCI6ZmFsc2U |
| "crit":["b64"]} | sImNyaXQiOlsiYjY0Il19.$.02 |
+-----------------------------+-------------------------------------+
+-----------------------------+-------------------------------------+
| JWS Protected Header | JWS Signing Input Value |
+-----------------------------+-------------------------------------+
| {"alg":"HS256"} | eyJhbGciOiJIUzI1NiJ9.JC4wMg |
| | |
| {"alg":"HS256","b64":false, | eyJhbGciOiJIUzI1NiIsImI2NCI6ZmFsc2U |
| "crit":["b64"]} | sImNyaXQiOlsiYjY0Il19.$.02 |
+-----------------------------+-------------------------------------+
These examples use the Hash-based Message Authentication Code (HMAC) key from Appendix A.1 of [JWS], which is represented below as a JSON Web Key [JWK] (with line breaks within values for display purposes only):
这些示例使用[JWS]附录A.1中基于散列的消息验证码（HMAC）密钥，该密钥表示为JSON Web密钥[JWK]（值中的换行符仅用于显示）：
{
"kty":"oct",
"k":"AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75
aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow"
}
{
"kty":"oct",
"k":"AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75
aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow"
}
The rest of this section shows complete representations for the two JWSs above.
本节的其余部分显示了上述两个JW的完整表示。
The complete JWS representation for this example using the JWS Compact Serialization and a non-detached payload (with line breaks for display purposes only) is:
本例中使用JWS紧凑序列化和非分离负载（仅出于显示目的使用换行符）的完整JWS表示为：
eyJhbGciOiJIUzI1NiJ9
.
JC4wMg
.
5mvfOroL-g7HyqJoozehmsaqmvTYGEq5jTI1gVvoEoQ
eyJhbGciOiJIUzI1NiJ9
.
JC4wMg
.
5mvfOroL-g7HyqJoozehmsaqmvTYGEq5jTI1gVvoEoQ
Note that this JWS uses only features defined by [JWS] and does not use the new "b64" Header Parameter. It is the "control" so that differences when it is used can be easily seen.
请注意，此JWS仅使用由[JWS]定义的功能，而不使用新的“b64”头参数。它是“控件”，以便在使用时可以很容易地看到差异。
The equivalent representation for this example using the flattened JWS JSON Serialization is:
此示例使用扁平化JWS JSON序列化的等效表示形式为：
{
"protected":
"eyJhbGciOiJIUzI1NiJ9",
"payload":
"JC4wMg",
"signature":
"5mvfOroL-g7HyqJoozehmsaqmvTYGEq5jTI1gVvoEoQ"
}
{
"protected":
"eyJhbGciOiJIUzI1NiJ9",
"payload":
"JC4wMg",
"signature":
"5mvfOroL-g7HyqJoozehmsaqmvTYGEq5jTI1gVvoEoQ"
}
4.2. Example with Header Parameters
{"alg":"HS256","b64":false,"crit":["b64"]}
4.2. Example with Header Parameters
{"alg":"HS256","b64":false,"crit":["b64"]}
The complete JWS representation for this example using the JWS Compact Serialization and a detached payload (with line breaks for display purposes only) is:
使用JWS紧凑序列化和分离负载（仅出于显示目的使用换行符）的本例的完整JWS表示为：
eyJhbGciOiJIUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19 . . A5dxf2s96_n5FLueVuW1Z_vh161FwXZC4YLPff6dmDY
EYJHBGIUZI1NIISIMI2NCI6ZMFSC2USIMNYAXQIOLSIY1L19。A5dxf2s96_n5FLueVuW1Z_VH161FWXZC4YLPF6DMDY
Note that the payload "$.02" cannot be represented in this JWS in its unencoded form because it contains a period ('.') character, which would cause parsing problems. This JWS is therefore shown with a detached payload.
请注意，此JWS中无法以未编码的形式表示有效负载“$.02”，因为它包含句点（'.'）字符，这将导致解析问题。因此，此JWS显示为分离的有效负载。
The complete JWS representation for this example using the flattened JWS JSON Serialization and a non-detached payload is:
本例使用扁平化JWS JSON序列化和非分离负载的完整JWS表示为：
{
"protected":
"eyJhbGciOiJIUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19",
"payload":
"$.02",
"signature":
"A5dxf2s96_n5FLueVuW1Z_vh161FwXZC4YLPff6dmDY"
}
{
"protected":
"eyJhbGciOiJIUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19",
"payload":
"$.02",
"signature":
"A5dxf2s96_n5FLueVuW1Z_vh161FwXZC4YLPff6dmDY"
}
If using a detached payload with the JWS JSON Serialization, the "payload" element would be omitted.
如果将分离的负载与JWS JSON序列化一起使用，“payload”元素将被省略。
When the "b64" value is "false", different restrictions on the payload contents apply, depending upon the circumstances, as described in this section. The restrictions prevent the use of payload values that would cause errors parsing the resulting JWSs.
当“b64”值为“false”时，根据本节所述情况，对有效负载内容适用不同的限制。这些限制阻止使用可能导致解析结果JWSs时出错的有效负载值。
Note that because the character sets that can be used for unencoded non-detached payloads differ between the two serializations, some JWSs using a "b64" value of "false" cannot be syntactically converted between the JWS JSON Serialization and the JWS Compact Serialization. See Section 8 for security considerations on using unencoded payloads.
请注意，由于可用于未编码的非分离有效负载的字符集在两种序列化之间不同，因此某些使用“b64”值“false”的JWS无法在JWS JSON序列化和JWS紧凑序列化之间进行语法转换。有关使用未编码有效载荷的安全注意事项，请参见第8节。
Appendix F of [JWS] describes how to represent JWSs with detached content. A detached payload can contain any octet sequence representable by the application. The payload value will not cause problems parsing the JWS, since it is not represented as part of the JWS. If an application uses a content encoding when representing the payload, then it MUST specify whether the signature or MAC is performed over the content-encoded representation or over the unencoded content.
[JWS]的附录F描述了如何用分离的内容表示JWS。分离的有效负载可以包含可由应用程序表示的任何八位字节序列。有效负载值不会导致JWS解析问题，因为它不是JWS的一部分。如果应用程序在表示有效负载时使用内容编码，那么它必须指定签名或MAC是在内容编码表示上还是在未编码内容上执行。
When using the JWS Compact Serialization, unencoded non-detached payloads using period ('.') characters would cause parsing errors; such payloads MUST NOT be used with the JWS Compact Serialization. Similarly, if a JWS using the JWS Compact Serialization and a non-detached payload is to be transmitted in a context that requires URL-safe characters, then the application MUST ensure that the payload contains only the URL-safe characters 'a'-'z', 'A'-'Z', '0'-'9', dash ('-'), underscore ('_'), and tilde ('~'). The payload value is the ASCII representation of the characters in the payload string. The ASCII space character and all printable ASCII characters other than period ('.') (those characters in the ranges %x20-2D and %x2F-7E) MAY be included in a non-detached payload using the JWS Compact Serialization, provided that the application can transmit the resulting JWS without modification.
使用JWS紧凑序列化时，使用句点（'.'）字符的未编码非分离有效负载将导致解析错误；此类有效负载不得与JWS紧凑序列化一起使用。类似地，如果要在需要URL安全字符的上下文中传输使用JWS紧凑序列化和非分离负载的JWS，则应用程序必须确保负载仅包含URL安全字符“a'-'z”、“a'-'z”、“0'-'9”、破折号（'-'）、下划线（'''-u'）和波浪号（'~'）。有效负载值是有效负载字符串中字符的ASCII表示形式。ASCII空格字符和除句点（'.'）以外的所有可打印ASCII字符（范围为%x20-2D和%x2F-7E的字符）可以使用JWS紧凑序列化包含在非分离的有效负载中，前提是应用程序可以在不修改的情况下传输生成的JWS。
No meaning or special semantics are attached to any characters in the payload. For instance, the percent ('%') character represents itself and is not used by JWS objects for percent-encoding [RFC3986]. Applications, of course, are free to utilize content-encoding rules of their choosing, provided that the encoded representations utilize only allowed payload characters.
有效负载中的任何字符都没有附加任何意义或特殊语义。例如，百分比（“%”）字符表示自身，JWS对象不使用它进行百分比编码[RFC3986]。当然，应用程序可以自由地使用自己选择的内容编码规则，只要编码表示只使用允许的有效负载字符。
When using the JWS JSON Serialization, unencoded non-detached payloads must consist of the octets of the UTF-8 encoding of a sequence of Unicode code points that are representable in a JSON string. The payload value is determined after performing any JSON string escape processing, per Section 8.3 of RFC 7159 [RFC7159], and then UTF-8-encoding the resulting Unicode code points. This means, for instance, that these payloads represented as JSON strings are equivalent ("$.02", "\u0024.02"). Unassigned Unicode code point values MUST NOT be used to represent the payload.
当使用JWS JSON序列化时，未编码的非分离有效负载必须由可在JSON字符串中表示的Unicode代码点序列的UTF-8编码的八位字节组成。根据RFC 7159[RFC7159]第8.3节，在执行任何JSON字符串转义处理后，确定有效负载值，然后对生成的Unicode代码点进行UTF-8编码。这意味着，例如，这些以JSON字符串表示的有效负载是等效的（$.02），“\u0024.02”）。未分配的Unicode代码点值不得用于表示有效负载。
The "crit" Header Parameter MUST be included with "b64" in its set of values when using the "b64" Header Parameter to cause implementations not implementing "b64" to reject the JWS (instead of it being misinterpreted).
当使用“b64”头参数导致未实现“b64”的实现拒绝JWS（而不是被误解）时，“crit”头参数必须与“b64”一起包含在其值集中。
Application profiles should specify whether "b64" with a "false" value is to be used by the application in each application context or not, with it then being consistently applied in each application context. For instance, an application that uses detached payloads might specify that "b64" with a "false" value always be used. It is NOT RECOMMENDED that this parameter value be dynamically varied with different payloads in the same application context.
应用程序配置文件应指定应用程序是否在每个应用程序上下文中使用带有“false”值的“b64”，然后在每个应用程序上下文中一致地应用它。例如，使用分离有效载荷的应用程序可能会指定始终使用具有“false”值的“b64”。不建议此参数值随同一应用程序上下文中的不同有效载荷而动态变化。
While it is legal to use "b64" with a "true" value, it is RECOMMENDED that "b64" simply be omitted in this case, since it would be selecting the behavior already specified in [JWS].
虽然将“b64”与“true”值一起使用是合法的，但建议在这种情况下省略“b64”，因为它将选择[JWS]中已经指定的行为。
For interoperability reasons, JSON Web Tokens [JWT] MUST NOT use "b64" with a "false" value.
出于互操作性的原因，JSON Web令牌[JWT]不得使用带有“false”值的“b64”。
[JWS] base64url-encodes the JWS Payload to restrict the set of characters used to represent it so that the representation does not contain characters used for delimiters in JWS representations. Those delimiters are the period ('.') character for the JWS Compact Serialization and the double-quote ('"') character for the JWS JSON Serialization. When the "b64" (base64url-encode payload) value is "false", these properties are lost. It then becomes the responsibility of the application to ensure that payloads only contain characters that will not cause parsing problems for the serialization used, as described in Section 5. The application also incurs the responsibility to ensure that the payload will not be modified during transmission.
[JWS]base64url对JWS负载进行编码，以限制用于表示它的字符集，从而使表示不包含JWS表示中用于分隔符的字符。这些分隔符是JWS紧凑序列化的句点（'.'）字符和JWS JSON序列化的双引号（''''）字符“，这些属性将丢失。然后，应用程序负责确保有效负载只包含不会导致所用序列化出现解析问题的字符，如第5节所述。应用程序还负责确保有效载荷在传输过程中不会被修改。
Note that if a JWS were to be created with a "b64" value of "false" without including the "crit" Header Parameter with "b64" in its set of values and it were to be received by an implementation not supporting the "b64" Header Parameter, then the signature or MAC would still verify but the recipient would believe that the intended JWS Payload value is the base64url decoding of the payload value received, rather than the payload value received itself. For example, if the payload value received were "NDA1", an implementation not supporting this extension would interpret the intended payload as
请注意，如果要使用“b64”值“false”创建JWS，而不在其值集中包含带有“b64”的“crit”头参数，并且该JWS将由不支持“b64”头参数的实现接收，然后签名或MAC仍将进行验证，但接收者会认为预期的JWS有效负载值是接收到的有效负载值的base64url解码，而不是接收到的有效负载值本身。例如，如果接收到的有效负载值为“NDA1”，则不支持此扩展的实现会将预期有效负载解释为
being the base64url decoding of this value, which is "405". Requiring the use of the "crit" Header Parameter with "b64" in the set of values prevents this misinterpretation.
为该值的base64url解码，即“405”。要求在一组值中使用带有“b64”的“crit”头参数可以防止这种误解。
This specification registers the "b64" Header Parameter defined in Section 3 in the IANA "JSON Web Signature and Encryption Header Parameters" registry [IANA.JOSE] established by [JWS].
本规范在[JWS]建立的IANA“JSON Web签名和加密头参数”注册表[IANA.JOSE]中注册第3节中定义的“b64”头参数。
o Header Parameter Name: "b64" o Header Parameter Description: Base64url-Encode Payload o Header Parameter Usage Location(s): JWS o Change Controller: IESG o Specification Document(s): Section 3 of RFC 7797
o 标题参数名称：“b64”o标题参数说明：Base64url编码有效负载o标题参数使用位置：JWS o更改控制器：IESG o规范文档：RFC 7797第3节
[IANA.JOSE] IANA, "JSON Object Signing and Encryption (JOSE)", <http://www.iana.org/assignments/jose>.
[IANA.JOSE]IANA，“JSON对象签名和加密（JOSE）”<http://www.iana.org/assignments/jose>.
[JWA] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <http://www.rfc-editor.org/info/rfc7518>.
[JWA]Jones，M.，“JSON网络算法（JWA）”，RFC 7518，DOI 10.17487/RFC7518，2015年5月<http://www.rfc-editor.org/info/rfc7518>.
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <http://www.rfc-editor.org/info/rfc7515>.
[JWS]Jones，M.，Bradley，J.，和N.Sakimura，“JSON网络签名（JWS）”，RFC 7515，DOI 10.17487/RFC7515，2015年5月<http://www.rfc-editor.org/info/rfc7515>.
[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <http://www.rfc-editor.org/info/rfc7519>.
[JWT]Jones，M.，Bradley，J.，和N.Sakimura，“JSON网络令牌（JWT）”，RFC 7519，DOI 10.17487/RFC7519，2015年5月<http://www.rfc-editor.org/info/rfc7519>.
[RFC20] Cerf, V., "ASCII format for Network Interchange", STD 80, RFC 20, October 1969, <http://www.rfc-editor.org/info/rfc20>.
[RFC20]Cerf，V.，“网络交换的ASCII格式”，STD 80，RFC 20，1969年10月<http://www.rfc-editor.org/info/rfc20>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，DOI 10.17487/RFC3629，2003年11月<http://www.rfc-editor.org/info/rfc3629>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159]Bray，T.，Ed.“JavaScript对象表示法（JSON）数据交换格式”，RFC 7159，DOI 10.17487/RFC7159，2014年3月<http://www.rfc-editor.org/info/rfc7159>.
[UNICODE] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.
[UNICODE]UNICODE联盟，“UNICODE标准”<http://www.unicode.org/versions/latest/>.
[JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <http://www.rfc-editor.org/info/rfc7517>.
[JWK]Jones，M.，“JSON Web密钥（JWK）”，RFC 7517，DOI 10.17487/RFC75172015年5月<http://www.rfc-editor.org/info/rfc7517>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<http://www.rfc-editor.org/info/rfc3986>.
Acknowledgements
致谢
Anders Rundgren, Richard Barnes, Phillip Hallam-Baker, Jim Schaad, Matt Miller, Martin Thomson, and others have all made the case for being able to use a representation of the payload that is not base64url encoded in contexts in which it safe to do so.
Anders Rundgren、Richard Barnes、Phillip Hallam Baker、Jim Schaad、Matt Miller、Martin Thomson和其他人都提出了能够在安全的上下文中使用非base64url编码的有效负载表示的理由。
Thanks to Sergey Beryozkin, Stephen Farrell, Benjamin Kaduk, James Manger, Kathleen Moriarty, Axel Nennker, Anders Rundgren, Nat Sakimura, Jim Schaad, Robert Sparks, and Matias Woloski for their reviews of the specification, and thanks to Vladimir Dzhuvinov for verifying the examples.
感谢Sergey Beryozkin、Stephen Farrell、Benjamin Kaduk、James Manger、Kathleen Moriarty、Axel Nennker、Anders Rundgren、Nat Sakimura、Jim Schaad、Robert Sparks和Matias Woloski对规范的审查，并感谢Vladimir Dzhuvinov验证示例。
Author's Address
作者地址
Michael B. Jones Microsoft
迈克尔·琼斯微软公司
Email: mbj@microsoft.com
URI: http://self-issued.info/
Email: mbj@microsoft.com
URI: http://self-issued.info/