Internet Engineering Task Force (IETF) M. Jones
Request for Comments: 7515 Microsoft
Category: Standards Track J. Bradley
ISSN: 2070-1721 Ping Identity
N. Sakimura
NRI
May 2015
Internet Engineering Task Force (IETF) M. Jones
Request for Comments: 7515 Microsoft
Category: Standards Track J. Bradley
ISSN: 2070-1721 Ping Identity
N. Sakimura
NRI
May 2015
JSON Web Signature (JWS)
JSON Web签名（JWS）
Abstract
摘要
JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.
JSON Web签名（JWS）表示使用基于JSON的数据结构的数字签名或消息身份验证码（MAC）保护的内容。与本规范一起使用的加密算法和标识符在单独的JSON Web算法（JWA）规范和该规范定义的IANA注册表中进行了描述。相关的加密功能在单独的JSON Web加密（JWE）规范中描述。
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/rfc7515.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7515.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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 ....................................................4
1.1. Notational Conventions .....................................4
2. Terminology .....................................................5
3. JSON Web Signature (JWS) Overview ...............................7
3.1. JWS Compact Serialization Overview .........................7
3.2. JWS JSON Serialization Overview ............................8
3.3. Example JWS ................................................8
4. JOSE Header .....................................................9
4.1. Registered Header Parameter Names .........................10
4.1.1. "alg" (Algorithm) Header Parameter .................10
4.1.2. "jku" (JWK Set URL) Header Parameter ...............10
4.1.3. "jwk" (JSON Web Key) Header Parameter ..............11
4.1.4. "kid" (Key ID) Header Parameter ....................11
4.1.5. "x5u" (X.509 URL) Header Parameter .................11
4.1.6. "x5c" (X.509 Certificate Chain) Header Parameter ...11
4.1.7. "x5t" (X.509 Certificate SHA-1 Thumbprint)
Header Parameter ...................................12
4.1.8. "x5t#S256" (X.509 Certificate SHA-256
Thumbprint) Header Parameter .......................12
4.1.9. "typ" (Type) Header Parameter ......................12
4.1.10. "cty" (Content Type) Header Parameter .............13
4.1.11. "crit" (Critical) Header Parameter ................14
4.2. Public Header Parameter Names .............................14
4.3. Private Header Parameter Names ............................14
5. Producing and Consuming JWSs ...................................15
5.1. Message Signature or MAC Computation ......................15
5.2. Message Signature or MAC Validation .......................16
5.3. String Comparison Rules ...................................17
6. Key Identification .............................................18
1. Introduction ....................................................4
1.1. Notational Conventions .....................................4
2. Terminology .....................................................5
3. JSON Web Signature (JWS) Overview ...............................7
3.1. JWS Compact Serialization Overview .........................7
3.2. JWS JSON Serialization Overview ............................8
3.3. Example JWS ................................................8
4. JOSE Header .....................................................9
4.1. Registered Header Parameter Names .........................10
4.1.1. "alg" (Algorithm) Header Parameter .................10
4.1.2. "jku" (JWK Set URL) Header Parameter ...............10
4.1.3. "jwk" (JSON Web Key) Header Parameter ..............11
4.1.4. "kid" (Key ID) Header Parameter ....................11
4.1.5. "x5u" (X.509 URL) Header Parameter .................11
4.1.6. "x5c" (X.509 Certificate Chain) Header Parameter ...11
4.1.7. "x5t" (X.509 Certificate SHA-1 Thumbprint)
Header Parameter ...................................12
4.1.8. "x5t#S256" (X.509 Certificate SHA-256
Thumbprint) Header Parameter .......................12
4.1.9. "typ" (Type) Header Parameter ......................12
4.1.10. "cty" (Content Type) Header Parameter .............13
4.1.11. "crit" (Critical) Header Parameter ................14
4.2. Public Header Parameter Names .............................14
4.3. Private Header Parameter Names ............................14
5. Producing and Consuming JWSs ...................................15
5.1. Message Signature or MAC Computation ......................15
5.2. Message Signature or MAC Validation .......................16
5.3. String Comparison Rules ...................................17
6. Key Identification .............................................18
7. Serializations .................................................19
7.1. JWS Compact Serialization .................................19
7.2. JWS JSON Serialization ....................................19
7.2.1. General JWS JSON Serialization Syntax ..............20
7.2.2. Flattened JWS JSON Serialization Syntax ............21
8. TLS Requirements ...............................................22
9. IANA Considerations ............................................22
9.1. JSON Web Signature and Encryption Header
Parameters Registry .......................................23
9.1.1. Registration Template ..............................23
9.1.2. Initial Registry Contents ..........................24
9.2. Media Type Registration ...................................26
9.2.1. Registry Contents ..................................26
10. Security Considerations .......................................27
10.1. Key Entropy and Random Values ............................27
10.2. Key Protection ...........................................28
10.3. Key Origin Authentication ................................28
10.4. Cryptographic Agility ....................................28
10.5. Differences between Digital Signatures and MACs ..........28
10.6. Algorithm Validation .....................................29
10.7. Algorithm Protection .....................................29
10.8. Chosen Plaintext Attacks .................................30
10.9. Timing Attacks ...........................................30
10.10. Replay Protection .......................................30
10.11. SHA-1 Certificate Thumbprints ...........................30
10.12. JSON Security Considerations ............................31
10.13. Unicode Comparison Security Considerations ..............31
11. References ....................................................32
11.1. Normative References .....................................32
11.2. Informative References ...................................34
Appendix A. JWS Examples .........................................36
A.1. Example JWS Using HMAC SHA-256 ............................36
A.1.1. Encoding ..............................................36
A.1.2. Validating ............................................38
A.2. Example JWS Using RSASSA-PKCS1-v1_5 SHA-256 ...............38
A.2.1. Encoding ..............................................38
A.2.2. Validating ............................................42
A.3. Example JWS Using ECDSA P-256 SHA-256 .....................42
A.3.1. Encoding ..............................................42
A.3.2. Validating ............................................44
A.4. Example JWS Using ECDSA P-521 SHA-512 .....................45
A.4.1. Encoding ..............................................45
A.4.2. Validating ............................................47
A.5. Example Unsecured JWS .....................................47
A.6. Example JWS Using General JWS JSON Serialization ..........48
A.6.1. JWS Per-Signature Protected Headers ...................48
A.6.2. JWS Per-Signature Unprotected Headers .................49
A.6.3. Complete JOSE Header Values ...........................49
7. Serializations .................................................19
7.1. JWS Compact Serialization .................................19
7.2. JWS JSON Serialization ....................................19
7.2.1. General JWS JSON Serialization Syntax ..............20
7.2.2. Flattened JWS JSON Serialization Syntax ............21
8. TLS Requirements ...............................................22
9. IANA Considerations ............................................22
9.1. JSON Web Signature and Encryption Header
Parameters Registry .......................................23
9.1.1. Registration Template ..............................23
9.1.2. Initial Registry Contents ..........................24
9.2. Media Type Registration ...................................26
9.2.1. Registry Contents ..................................26
10. Security Considerations .......................................27
10.1. Key Entropy and Random Values ............................27
10.2. Key Protection ...........................................28
10.3. Key Origin Authentication ................................28
10.4. Cryptographic Agility ....................................28
10.5. Differences between Digital Signatures and MACs ..........28
10.6. Algorithm Validation .....................................29
10.7. Algorithm Protection .....................................29
10.8. Chosen Plaintext Attacks .................................30
10.9. Timing Attacks ...........................................30
10.10. Replay Protection .......................................30
10.11. SHA-1 Certificate Thumbprints ...........................30
10.12. JSON Security Considerations ............................31
10.13. Unicode Comparison Security Considerations ..............31
11. References ....................................................32
11.1. Normative References .....................................32
11.2. Informative References ...................................34
Appendix A. JWS Examples .........................................36
A.1. Example JWS Using HMAC SHA-256 ............................36
A.1.1. Encoding ..............................................36
A.1.2. Validating ............................................38
A.2. Example JWS Using RSASSA-PKCS1-v1_5 SHA-256 ...............38
A.2.1. Encoding ..............................................38
A.2.2. Validating ............................................42
A.3. Example JWS Using ECDSA P-256 SHA-256 .....................42
A.3.1. Encoding ..............................................42
A.3.2. Validating ............................................44
A.4. Example JWS Using ECDSA P-521 SHA-512 .....................45
A.4.1. Encoding ..............................................45
A.4.2. Validating ............................................47
A.5. Example Unsecured JWS .....................................47
A.6. Example JWS Using General JWS JSON Serialization ..........48
A.6.1. JWS Per-Signature Protected Headers ...................48
A.6.2. JWS Per-Signature Unprotected Headers .................49
A.6.3. Complete JOSE Header Values ...........................49
A.6.4. Complete JWS JSON Serialization Representation ........50
A.7. Example JWS Using Flattened JWS JSON Serialization ........51
Appendix B. "x5c" (X.509 Certificate Chain) Example ..............52
Appendix C. Notes on Implementing base64url Encoding without
Padding ..............................................54
Appendix D. Notes on Key Selection ...............................55
Appendix E. Negative Test Case for "crit" Header Parameter .......57
Appendix F. Detached Content .....................................57
Acknowledgements ..................................................58
Authors' Addresses ................................................58
A.6.4. Complete JWS JSON Serialization Representation ........50
A.7. Example JWS Using Flattened JWS JSON Serialization ........51
Appendix B. "x5c" (X.509 Certificate Chain) Example ..............52
Appendix C. Notes on Implementing base64url Encoding without
Padding ..............................................54
Appendix D. Notes on Key Selection ...............................55
Appendix E. Negative Test Case for "crit" Header Parameter .......57
Appendix F. Detached Content .....................................57
Acknowledgements ..................................................58
Authors' Addresses ................................................58
JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based [RFC7159] data structures. The JWS cryptographic mechanisms provide integrity protection for an arbitrary sequence of octets. See Section 10.5 for a discussion on the differences between digital signatures and MACs.
JSON Web签名（JWS）表示使用基于JSON的[RFC7159]数据结构的数字签名或消息身份验证码（MAC）保护的内容。JWS加密机制为任意八位字节序列提供完整性保护。有关数字签名和MAC之间差异的讨论，请参见第10.5节。
Two closely related serializations for JWSs are defined. The JWS Compact Serialization is a compact, URL-safe representation intended for space-constrained environments such as HTTP Authorization headers and URI query parameters. The JWS JSON Serialization represents JWSs as JSON objects and enables multiple signatures and/or MACs to be applied to the same content. Both share the same cryptographic underpinnings.
为JWSs定义了两个密切相关的序列化。JWS Compact Serialization是一种紧凑的URL安全表示，用于空间受限的环境，如HTTP授权头和URI查询参数。JWS JSON序列化将JWS表示为JSON对象，并允许对同一内容应用多个签名和/或MAC。两者共享相同的加密基础。
Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) [JWA] specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) [JWE] specification.
与本规范一起使用的加密算法和标识符在单独的JSON Web算法（JWA）[JWA]规范和该规范定义的IANA注册表中进行了描述。相关的加密功能在单独的JSON Web加密（JWE）[JWE]规范中描述。
Names defined by this specification are short because a core goal is for the resulting representations to be compact.
本规范定义的名称很短，因为核心目标是使结果表示紧凑。
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.
根据第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。
These terms are defined by this specification:
这些术语由本规范定义：
JSON Web Signature (JWS) A data structure representing a digitally signed or MACed message.
JSON Web签名（JWS）表示数字签名或MACE消息的数据结构。
JOSE Header JSON object containing the parameters describing the cryptographic operations and parameters employed. The JOSE (JSON Object Signing and Encryption) Header is comprised of a set of Header Parameters.
JOSE Header JSON对象，包含描述加密操作和所用参数的参数。JOSE（JSON对象签名和加密）头由一组头参数组成。
JWS Payload The sequence of octets to be secured -- a.k.a. the message. The payload can contain an arbitrary sequence of octets.
JWS有效负载要保护的八位字节序列——也称为消息。有效载荷可以包含任意八位字节序列。
JWS Signature Digital signature or MAC over the JWS Protected Header and the JWS Payload.
JWS签名通过JWS保护的报头和JWS有效负载的数字签名或MAC。
Header Parameter A name/value pair that is member of the JOSE Header.
Header参数作为JOSE头成员的名称/值对。
JWS Protected Header JSON object that contains the Header Parameters that are integrity protected by the JWS Signature digital signature or MAC operation. For the JWS Compact Serialization, this comprises the entire JOSE Header. For the JWS JSON Serialization, this is one component of the JOSE Header.
JWS-Protected Header JSON对象，其中包含受JWS签名数字签名或MAC操作完整性保护的头参数。对于JWS紧凑序列化，这包括整个JOSE头。对于JWS-JSON序列化，这是JOSE头的一个组件。
JWS Unprotected Header JSON object that contains the Header Parameters that are not integrity protected. This can only be present when using the JWS JSON Serialization.
JWS Unprotected Header JSON对象，其中包含不受完整性保护的头参数。这只能在使用JWS JSON序列化时出现。
Base64url Encoding Base64 encoding using the URL- and filename-safe character set defined in Section 5 of RFC 4648 [RFC4648], with all trailing '=' characters omitted (as permitted by Section 3.2) and without the inclusion of any line breaks, whitespace, or other additional characters. Note that the base64url encoding of the empty octet sequence is the empty string. (See Appendix C for notes on implementing base64url encoding without padding.)
Base64url编码使用RFC 4648[RFC4648]第5节中定义的URL和文件名安全字符集进行Base64编码，省略所有尾随“=”字符（如第3.2节所允许），且不包含任何换行符、空白或其他附加字符。请注意，空八位字节序列的base64url编码是空字符串。（有关实现无填充的base64url编码的说明，请参见附录C。）
JWS Signing Input The input to the digital signature or MAC computation. Its value is ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload)).
JWS签名输入数字签名或MAC计算的输入。它的值是ASCII（BASE64URL（UTF8（JWS保护头））| |'。| | BASE64URL（JWS负载））。
JWS Compact Serialization A representation of the JWS as a compact, URL-safe string.
JWS紧凑序列化将JWS表示为紧凑的URL安全字符串。
JWS JSON Serialization A representation of the JWS as a JSON object. Unlike the JWS Compact Serialization, the JWS JSON Serialization enables multiple digital signatures and/or MACs to be applied to the same content. This representation is neither optimized for compactness nor URL-safe.
JWS JSON序列化将JWS表示为JSON对象。与JWS紧凑序列化不同，JWS JSON序列化允许对同一内容应用多个数字签名和/或MAC。此表示既不优化紧凑性，也不优化URL安全性。
Unsecured JWS A JWS that provides no integrity protection. Unsecured JWSs use the "alg" value "none".
不安全JWS不提供完整性保护的JWS。不安全的JWS使用“alg”值“none”。
Collision-Resistant Name A name in a namespace that enables names to be allocated in a manner such that they are highly unlikely to collide with other names. Examples of collision-resistant namespaces include: Domain Names, Object Identifiers (OIDs) as defined in the ITU-T X.660 and X.670 Recommendation series, and Universally Unique IDentifiers (UUIDs) [RFC4122]. When using an administratively delegated namespace, the definer of a name needs to take reasonable precautions to ensure they are in control of the portion of the namespace they use to define the name.
抗冲突名称命名空间中的名称，该名称允许以不太可能与其他名称冲突的方式分配名称。抗冲突名称空间的示例包括：域名、ITU-T X.660和X.670建议系列中定义的对象标识符（OID）以及通用唯一标识符（UUID）[RFC4122]。当使用管理委派的命名空间时，名称的定义者需要采取合理的预防措施，以确保他们能够控制用于定义名称的命名空间部分。
StringOrURI A JSON string value, with the additional requirement that while arbitrary string values MAY be used, any value containing a ":" character MUST be a URI [RFC3986]. StringOrURI values are compared as case-sensitive strings with no transformations or canonicalizations applied.
StringOrURI是一个JSON字符串值，另外还要求，尽管可以使用任意字符串值，但包含“：”字符的任何值都必须是URI[RFC3986]。StringOrURI值作为区分大小写的字符串进行比较，不应用任何转换或规范化。
The terms "JSON Web Encryption (JWE)", "JWE Compact Serialization", and "JWE JSON Serialization" are defined by the JWE specification [JWE].
术语“JSON Web加密（JWE）”、“JWE压缩序列化”和“JWE JSON序列化”由JWE规范[JWE]定义。
The terms "Digital Signature" and "Message Authentication Code (MAC)" are defined by the "Internet Security Glossary, Version 2" [RFC4949].
术语“数字签名”和“消息认证码（MAC）”由“互联网安全词汇表，第2版”[RFC4949]定义。
JWS represents digitally signed or MACed content using JSON data structures and base64url encoding. These JSON data structures MAY contain whitespace and/or line breaks before or after any JSON values or structural characters, in accordance with Section 2 of RFC 7159 [RFC7159]. A JWS represents these logical values (each of which is defined in Section 2):
JWS使用JSON数据结构和base64url编码表示数字签名或标记的内容。根据RFC 7159[RFC7159]第2节的规定，这些JSON数据结构可能在任何JSON值或结构字符之前或之后包含空格和/或换行符。JWS表示这些逻辑值（每个逻辑值在第2节中定义）：
o JOSE Header o JWS Payload o JWS Signature
o 何塞头o JWS有效载荷o JWS签名
For a JWS, the JOSE Header members are the union of the members of these values (each of which is defined in Section 2):
对于JWS，JOSE头成员是这些值的成员的并集（每个值在第2节中定义）：
o JWS Protected Header o JWS Unprotected Header
o JWS受保护的头文件到JWS未受保护的头文件
This document defines two serializations for JWSs: a compact, URL-safe serialization called the JWS Compact Serialization and a JSON serialization called the JWS JSON Serialization. In both serializations, the JWS Protected Header, JWS Payload, and JWS Signature are base64url encoded, since JSON lacks a way to directly represent arbitrary octet sequences.
本文档为JWSs定义了两种序列化：一种称为JWS紧凑序列化的紧凑的URL安全序列化和一种称为JWS JSON序列化的JSON序列化。在这两种序列化中，JWS-Protected头、JWS-Payload和JWS-Signature都是base64url编码的，因为JSON无法直接表示任意八位字节序列。
In the JWS Compact Serialization, no JWS Unprotected Header is used. In this case, the JOSE Header and the JWS Protected Header are the same.
在JWS紧凑序列化中，不使用JWS未受保护的头。在这种情况下，JOSE头和JWS-Protected头是相同的。
In the JWS Compact Serialization, a JWS is represented as the concatenation:
在JWS紧凑序列化中，JWS表示为串联：
BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) || '.' || BASE64URL(JWS Signature)
BASE64URL（UTF8（JWS保护头））| |'。| | BASE64URL（JWS有效负载）| |'。| | BASE64URL（JWS签名）
See Section 7.1 for more information about the JWS Compact Serialization.
有关JWS紧凑序列化的更多信息，请参见第7.1节。
In the JWS JSON Serialization, one or both of the JWS Protected Header and JWS Unprotected Header MUST be present. In this case, the members of the JOSE Header are the union of the members of the JWS Protected Header and the JWS Unprotected Header values that are present.
在JWS JSON序列化中，必须存在JWS受保护的头和JWS未受保护的头中的一个或两个。在这种情况下，JOSE头的成员是存在的JWS保护头和JWS未保护头值的成员的并集。
In the JWS JSON Serialization, a JWS is represented as a JSON object containing some or all of these four members:
在JWS JSON序列化中，JWS被表示为包含以下四个成员中的一部分或全部的JSON对象：
o "protected", with the value BASE64URL(UTF8(JWS Protected Header))
o "header", with the value JWS Unprotected Header
o "payload", with the value BASE64URL(JWS Payload)
o "signature", with the value BASE64URL(JWS Signature)
o "protected", with the value BASE64URL(UTF8(JWS Protected Header))
o "header", with the value JWS Unprotected Header
o "payload", with the value BASE64URL(JWS Payload)
o "signature", with the value BASE64URL(JWS Signature)
The three base64url-encoded result strings and the JWS Unprotected Header value are represented as members within a JSON object. The inclusion of some of these values is OPTIONAL. The JWS JSON Serialization can also represent multiple signature and/or MAC values, rather than just one. See Section 7.2 for more information about the JWS JSON Serialization.
三个base64url编码的结果字符串和JWS Unprotected头值表示为JSON对象中的成员。包含其中一些值是可选的。JWS JSON序列化还可以表示多个签名和/或MAC值，而不仅仅是一个。有关JWS JSON序列化的更多信息，请参见第7.2节。
This section provides an example of a JWS. Its computation is described in more detail in Appendix A.1, including specifying the exact octet sequences representing the JSON values used and the key value used.
本节提供了一个JWS的示例。其计算在附录A.1中有更详细的描述，包括指定表示所用JSON值和所用键值的精确八位字节序列。
The following example JWS Protected Header declares that the encoded object is a JSON Web Token [JWT] and the JWS Protected Header and the JWS Payload are secured using the HMAC SHA-256 [RFC2104] [SHS] algorithm:
以下示例JWS-Protected标头声明编码的对象是JSON Web令牌[JWT]，JWS-Protected标头和JWS负载使用HMAC SHA-256[RFC2104][SHS]算法进行保护：
{"typ":"JWT",
"alg":"HS256"}
{"typ":"JWT",
"alg":"HS256"}
Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value:
将此受JWS保护的标头编码为BASE64URL（UTF8（受JWS保护的标头））将给出以下值：
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
The UTF-8 representation of the following JSON object is used as the JWS Payload. (Note that the payload can be any content and need not be a representation of a JSON object.)
以下JSON对象的UTF-8表示用作JWS负载。（请注意，有效负载可以是任何内容，而不必是JSON对象的表示。）
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
Encoding this JWS Payload as BASE64URL(JWS Payload) gives this value (with line breaks for display purposes only):
将此JWS有效负载编码为BASE64URL（JWS有效负载）将给出此值（换行符仅用于显示目的）：
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
EYJPC3MIOIJQB2UILA0KIJLEHAIOJEZMDA4MTKZODAQIMH0DHA6LY9LEGFT cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
Computing the HMAC of the JWS Signing Input ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload)) with the HMAC SHA-256 algorithm using the key specified in Appendix A.1 and base64url-encoding the result yields this BASE64URL(JWS Signature) value:
使用HMAC SHA-256算法计算JWS签名输入ASCII（BASE64URL（UTF8（JWS保护头））| | |'。| | BASE64URL（JWS有效负载））的HMAC，使用附录A.1中指定的密钥和BASE64URL编码。结果产生此BASE64URL（JWS签名）值：
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
Concatenating these values in the order Header.Payload.Signature with period ('.') characters between the parts yields this complete JWS representation using the JWS Compact Serialization (with line breaks for display purposes only):
将order Header.Payload.Signature中的这些值与部分之间的句点（'.'）字符连接起来，可以使用JWS紧凑序列化（换行符仅用于显示目的）生成完整的JWS表示：
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ . dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9。EYJPC3MIOIJQB2UILA0KIJLEHAIOJEZMDA4MTKZODAZODAQIMH0DHA6LY9LEGFT cGxlLmNvbS9pc19yb290Ijp0cnVlfQ。dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
See Appendix A for additional examples, including examples using the JWS JSON Serialization in Sections A.6 and A.7.
更多示例请参见附录A，包括第A.6和A.7节中使用JWS JSON序列化的示例。
For a JWS, the members of the JSON object(s) representing the JOSE Header describe the digital signature or MAC applied to the JWS Protected Header and the JWS Payload and optionally additional properties of the JWS. The Header Parameter names within the JOSE Header MUST be unique; JWS parsers MUST either reject JWSs with duplicate Header Parameter names or use a JSON parser that returns only the lexically last duplicate member name, as specified in Section 15.12 ("The JSON Object") of ECMAScript 5.1 [ECMAScript].
对于JWS，表示JOSE头的JSON对象的成员描述了应用于JWS保护头的数字签名或MAC、JWS有效负载以及JWS的可选附加属性。JOSE头中的头参数名称必须是唯一的；JWS解析器必须拒绝具有重复头参数名称的JWSs，或者使用只返回词汇上最后一个重复成员名称的JSON解析器，如ECMAScript 5.1[ECMAScript]第15.12节（“JSON对象”）所述。
Implementations are required to understand the specific Header Parameters defined by this specification that are designated as "MUST be understood" and process them in the manner defined in this specification. All other Header Parameters defined by this
实现需要理解本规范定义的指定为“必须理解”的特定头参数，并以本规范中定义的方式处理它们。此文件定义的所有其他标题参数
specification that are not so designated MUST be ignored when not understood. Unless listed as a critical Header Parameter, per Section 4.1.11, all Header Parameters not defined by this specification MUST be ignored when not understood.
未指定的规范在不理解时必须忽略。根据第4.1.11节，除非列为关键标题参数，否则本规范未定义的所有标题参数在不理解时必须忽略。
There are three classes of Header Parameter names: Registered Header Parameter names, Public Header Parameter names, and Private Header Parameter names.
有三类头参数名称：注册头参数名称、公共头参数名称和私有头参数名称。
The following Header Parameter names for use in JWSs are registered in the IANA "JSON Web Signature and Encryption Header Parameters" registry established by Section 9.1, with meanings as defined in the subsections below.
JWSs中使用的以下标题参数名称在第9.1节建立的IANA“JSON Web签名和加密标题参数”注册表中注册，其含义如下小节所述。
As indicated by the common registry, JWSs and JWEs share a common Header Parameter space; when a parameter is used by both specifications, its usage must be compatible between the specifications.
如公共注册表所示，JWSs和JWEs共享一个公共头参数空间；当一个参数由两个规范使用时，其用法必须在两个规范之间兼容。
The "alg" (algorithm) Header Parameter identifies the cryptographic algorithm used to secure the JWS. The JWS Signature value is not valid if the "alg" value does not represent a supported algorithm or if there is not a key for use with that algorithm associated with the party that digitally signed or MACed the content. "alg" values should either be registered in the IANA "JSON Web Signature and Encryption Algorithms" registry established by [JWA] or be a value that contains a Collision-Resistant Name. The "alg" value is a case-sensitive ASCII string containing a StringOrURI value. This Header Parameter MUST be present and MUST be understood and processed by implementations.
“alg”（algorithm）头参数标识用于保护JWS的加密算法。如果“alg”值不表示受支持的算法，或者如果没有与该算法一起使用的密钥与对内容进行数字签名或标记的一方关联，则JWS签名值无效。“alg”值应该在[JWA]建立的IANA“JSON Web签名和加密算法”注册表中注册，或者是包含防冲突名称的值。“alg”值是一个区分大小写的ASCII字符串，包含StringOrURI值。此头参数必须存在，并且必须被实现理解和处理。
A list of defined "alg" values for this use can be found in the IANA "JSON Web Signature and Encryption Algorithms" registry established by [JWA]; the initial contents of this registry are the values defined in Section 3.1 of [JWA].
可在[JWA]建立的IANA“JSON Web签名和加密算法”注册表中找到此用途定义的“alg”值列表；本注册表的初始内容为[JWA]第3.1节中定义的值。
The "jku" (JWK Set URL) Header Parameter is a URI [RFC3986] that refers to a resource for a set of JSON-encoded public keys, one of which corresponds to the key used to digitally sign the JWS. The keys MUST be encoded as a JWK Set [JWK]. The protocol used to acquire the resource MUST provide integrity protection; an HTTP GET request to retrieve the JWK Set MUST use Transport Layer Security
“jku”（JWK Set URL）头参数是一个URI[RFC3986]，它引用一组JSON编码公钥的资源，其中一个公钥对应于用于对JWS进行数字签名的密钥。密钥必须编码为JWK集[JWK]。用于获取资源的协议必须提供完整性保护；检索JWK集的HTTP GET请求必须使用传输层安全性
(TLS) [RFC2818] [RFC5246]; and the identity of the server MUST be validated, as per Section 6 of RFC 6125 [RFC6125]. Also, see Section 8 on TLS requirements. Use of this Header Parameter is OPTIONAL.
（TLS）[RFC2818][RFC5246]；根据RFC 6125[RFC6125]第6节，必须验证服务器的身份。此外，参见第8节TLS要求。此标头参数的使用是可选的。
The "jwk" (JSON Web Key) Header Parameter is the public key that corresponds to the key used to digitally sign the JWS. This key is represented as a JSON Web Key [JWK]. Use of this Header Parameter is OPTIONAL.
“jwk”（JSON Web密钥）头参数是与用于对JWS进行数字签名的密钥相对应的公钥。此密钥表示为JSON Web密钥[JWK]。此标头参数的使用是可选的。
The "kid" (key ID) Header Parameter is a hint indicating which key was used to secure the JWS. This parameter allows originators to explicitly signal a change of key to recipients. The structure of the "kid" value is unspecified. Its value MUST be a case-sensitive string. Use of this Header Parameter is OPTIONAL.
“kid”（key ID）头参数是一个提示，指示用于保护JWS的密钥。此参数允许发起者向收件人明确发出密钥更改的信号。未指定“kid”值的结构。其值必须是区分大小写的字符串。此标头参数的使用是可选的。
When used with a JWK, the "kid" value is used to match a JWK "kid" parameter value.
与JWK一起使用时，“kid”值用于匹配JWK“kid”参数值。
The "x5u" (X.509 URL) Header Parameter is a URI [RFC3986] that refers to a resource for the X.509 public key certificate or certificate chain [RFC5280] corresponding to the key used to digitally sign the JWS. The identified resource MUST provide a representation of the certificate or certificate chain that conforms to RFC 5280 [RFC5280] in PEM-encoded form, with each certificate delimited as specified in Section 6.1 of RFC 4945 [RFC4945]. The certificate containing the public key corresponding to the key used to digitally sign the JWS MUST be the first certificate. This MAY be followed by additional certificates, with each subsequent certificate being the one used to certify the previous one. The protocol used to acquire the resource MUST provide integrity protection; an HTTP GET request to retrieve the certificate MUST use TLS [RFC2818] [RFC5246]; and the identity of the server MUST be validated, as per Section 6 of RFC 6125 [RFC6125]. Also, see Section 8 on TLS requirements. Use of this Header Parameter is OPTIONAL.
“x5u”（X.509 URL）头参数是一个URI[RFC3986]，它引用与用于对JWS进行数字签名的密钥相对应的X.509公钥证书或证书链[RFC5280]的资源。标识的资源必须以PEM编码形式提供符合RFC 5280[RFC5280]的证书或证书链的表示，每个证书按照RFC 4945[RFC4945]第6.1节的规定进行分隔。包含与用于对JWS进行数字签名的密钥相对应的公钥的证书必须是第一个证书。随后可能会有其他证书，每个后续证书都是用于认证前一个证书的证书。用于获取资源的协议必须提供完整性保护；检索证书的HTTP GET请求必须使用TLS[RFC2818][RFC5246]；根据RFC 6125[RFC6125]第6节，必须验证服务器的身份。此外，参见第8节TLS要求。此标头参数的使用是可选的。
The "x5c" (X.509 certificate chain) Header Parameter contains the X.509 public key certificate or certificate chain [RFC5280] corresponding to the key used to digitally sign the JWS. The certificate or certificate chain is represented as a JSON array of
“x5c”（X.509证书链）头参数包含与用于对JWS进行数字签名的密钥相对应的X.509公钥证书或证书链[RFC5280]。证书或证书链表示为
certificate value strings. Each string in the array is a base64-encoded (Section 4 of [RFC4648] -- not base64url-encoded) DER [ITU.X690.2008] PKIX certificate value. The certificate containing the public key corresponding to the key used to digitally sign the JWS MUST be the first certificate. This MAY be followed by additional certificates, with each subsequent certificate being the one used to certify the previous one. The recipient MUST validate the certificate chain according to RFC 5280 [RFC5280] and consider the certificate or certificate chain to be invalid if any validation failure occurs. Use of this Header Parameter is OPTIONAL.
证书值字符串。数组中的每个字符串都是[ITU.X690.2008]PKIX证书值下的base64编码（RFC4648的第4节——非base64url编码）。包含与用于对JWS进行数字签名的密钥相对应的公钥的证书必须是第一个证书。随后可能会有其他证书，每个后续证书都是用于认证前一个证书的证书。接收方必须根据RFC 5280 [RFC5280]验证证书链，并且如果发生任何验证失败，则认为证书或证书链无效。此标头参数的使用是可选的。
See Appendix B for an example "x5c" value.
有关“x5c”值的示例，请参见附录B。
The "x5t" (X.509 certificate SHA-1 thumbprint) Header Parameter is a base64url-encoded SHA-1 thumbprint (a.k.a. digest) of the DER encoding of the X.509 certificate [RFC5280] corresponding to the key used to digitally sign the JWS. Note that certificate thumbprints are also sometimes known as certificate fingerprints. Use of this Header Parameter is OPTIONAL.
“x5t”（X.509证书SHA-1指纹）头参数是X.509证书[RFC5280]的DER编码的base64url编码SHA-1指纹（也称为摘要），对应于用于对JWS进行数字签名的密钥。请注意，证书指纹有时也称为证书指纹。此标头参数的使用是可选的。
4.1.8. "x5t#S256" (X.509 Certificate SHA-256 Thumbprint) Header Parameter
4.1.8. “x5t#S256”（X.509证书SHA-256指纹）标题参数
The "x5t#S256" (X.509 certificate SHA-256 thumbprint) Header Parameter is a base64url-encoded SHA-256 thumbprint (a.k.a. digest) of the DER encoding of the X.509 certificate [RFC5280] corresponding to the key used to digitally sign the JWS. Note that certificate thumbprints are also sometimes known as certificate fingerprints. Use of this Header Parameter is OPTIONAL.
“x5t#S256”（X.509证书SHA-256指纹）头参数是X.509证书[RFC5280]的DER编码的base64url编码SHA-256指纹（也称为摘要），对应于用于对JWS进行数字签名的密钥。请注意，证书指纹有时也称为证书指纹。此标头参数的使用是可选的。
The "typ" (type) Header Parameter is used by JWS applications to declare the media type [IANA.MediaTypes] of this complete JWS. This is intended for use by the application when more than one kind of object could be present in an application data structure that can contain a JWS; the application can use this value to disambiguate among the different kinds of objects that might be present. It will typically not be used by applications when the kind of object is already known. This parameter is ignored by JWS implementations; any processing of this parameter is performed by the JWS application. Use of this Header Parameter is OPTIONAL.
JWS应用程序使用“typ”（type）头参数来声明此完整JWS的媒体类型[IANA.MediaTypes]。当可以包含JWS的应用程序数据结构中可能存在一种以上的对象时，应用程序可使用此功能；应用程序可以使用此值消除可能存在的不同类型对象之间的歧义。当对象类型已知时，应用程序通常不会使用它。JWS实现会忽略此参数；此参数的任何处理都由JWS应用程序执行。此标头参数的使用是可选的。
Per RFC 2045 [RFC2045], all media type values, subtype values, and parameter names are case insensitive. However, parameter values are case sensitive unless otherwise specified for the specific parameter.
根据RFC 2045[RFC2045]，所有媒体类型值、子类型值和参数名称都不区分大小写。但是，除非为特定参数另行指定，否则参数值区分大小写。
To keep messages compact in common situations, it is RECOMMENDED that producers omit an "application/" prefix of a media type value in a "typ" Header Parameter when no other '/' appears in the media type value. A recipient using the media type value MUST treat it as if "application/" were prepended to any "typ" value not containing a '/'. For instance, a "typ" value of "example" SHOULD be used to represent the "application/example" media type, whereas the media type "application/example;part="1/2"" cannot be shortened to "example;part="1/2"".
为了在常见情况下保持消息紧凑，建议生产者在“typ”头参数中省略媒体类型值的“application/”前缀，前提是媒体类型值中没有其他“/”出现。使用媒体类型值的收件人必须将其视为“application/”前置于任何不包含“/”的“typ”值。例如，“示例”的“typ”值应用于表示“应用程序/示例”媒体类型，而媒体类型“应用程序/示例；part=“1/2”不能缩短为“示例；part=“1/2”。
The "typ" value "JOSE" can be used by applications to indicate that this object is a JWS or JWE using the JWS Compact Serialization or the JWE Compact Serialization. The "typ" value "JOSE+JSON" can be used by applications to indicate that this object is a JWS or JWE using the JWS JSON Serialization or the JWE JSON Serialization. Other type values can also be used by applications.
应用程序可以使用“typ”值“JOSE”来指示此对象是使用JWS紧凑序列化或JWE紧凑序列化的JWS或JWE。应用程序可以使用“typ”值“JOSE+JSON”来指示此对象是使用JWS-JSON序列化或JWE-JSON序列化的JWS或JWE。应用程序也可以使用其他类型值。
The "cty" (content type) Header Parameter is used by JWS applications to declare the media type [IANA.MediaTypes] of the secured content (the payload). This is intended for use by the application when more than one kind of object could be present in the JWS Payload; the application can use this value to disambiguate among the different kinds of objects that might be present. It will typically not be used by applications when the kind of object is already known. This parameter is ignored by JWS implementations; any processing of this parameter is performed by the JWS application. Use of this Header Parameter is OPTIONAL.
JWS应用程序使用“cty”（内容类型）头参数来声明受保护内容（有效负载）的媒体类型[IANA.MediaTypes]。当JWS有效载荷中可能存在多种对象时，应用程序将使用该方法；应用程序可以使用此值消除可能存在的不同类型对象之间的歧义。当对象类型已知时，应用程序通常不会使用它。JWS实现会忽略此参数；此参数的任何处理都由JWS应用程序执行。此标头参数的使用是可选的。
Per RFC 2045 [RFC2045], all media type values, subtype values, and parameter names are case insensitive. However, parameter values are case sensitive unless otherwise specified for the specific parameter.
根据RFC 2045[RFC2045]，所有媒体类型值、子类型值和参数名称都不区分大小写。但是，除非为特定参数另行指定，否则参数值区分大小写。
To keep messages compact in common situations, it is RECOMMENDED that producers omit an "application/" prefix of a media type value in a "cty" Header Parameter when no other '/' appears in the media type value. A recipient using the media type value MUST treat it as if "application/" were prepended to any "cty" value not containing a '/'. For instance, a "cty" value of "example" SHOULD be used to represent the "application/example" media type, whereas the media type "application/example;part="1/2"" cannot be shortened to "example;part="1/2"".
为了在常见情况下保持消息的紧凑性，建议生产者在“cty”头参数中省略媒体类型值的“application/”前缀，前提是媒体类型值中没有其他“/”出现。使用媒体类型值的收件人必须将其视为“application/”前置于任何不包含“/”的“cty”值。例如，应使用“示例”的“cty”值表示“应用程序/示例”媒体类型，而媒体类型“应用程序/示例；part=“1/2”不能缩短为“示例；part=“1/2”。
The "crit" (critical) Header Parameter indicates that extensions to this specification and/or [JWA] are being used that MUST be understood and processed. Its value is an array listing the Header Parameter names present in the JOSE Header that use those extensions. If any of the listed extension Header Parameters are not understood and supported by the recipient, then the JWS is invalid. Producers MUST NOT include Header Parameter names defined by this specification or [JWA] for use with JWS, duplicate names, or names that do not occur as Header Parameter names within the JOSE Header in the "crit" list. Producers MUST NOT use the empty list "[]" as the "crit" value. Recipients MAY consider the JWS to be invalid if the critical list contains any Header Parameter names defined by this specification or [JWA] for use with JWS or if any other constraints on its use are violated. 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. This Header Parameter MUST be understood and processed by implementations.
“crit”（critical）头参数表示正在使用本规范和/或[JWA]的扩展，必须理解和处理这些扩展。它的值是一个数组，列出使用这些扩展名的JOSE头中存在的头参数名称。如果收件人不理解和支持列出的任何扩展标头参数，则JWS无效。生产者不得在“crit”列表中包含本规范或[JWA]定义的用于JWS的标题参数名称、重复名称或不作为JOSE标题中的标题参数名称出现的名称。生产者不得使用空列表“[]”作为“临界值”。如果关键列表包含由本规范定义的任何头参数名或JWS与JWS一起使用，或者如果对其使用的任何其他约束被违反，则接收方可能认为JWS无效。使用时，此标头参数必须受完整性保护；因此，它必须只出现在JWS保护的头中。此标头参数的使用是可选的。实现必须理解和处理此头参数。
An example use, along with a hypothetical "exp" (expiration time) field is:
示例使用以及假设的“exp”（过期时间）字段为：
{"alg":"ES256", "crit":["exp"], "exp":1363284000 }
{“alg”：“ES256”，“crit”：[“exp”]，“exp”：1363284000}
Additional Header Parameter names can be defined by those using JWSs. However, in order to prevent collisions, any new Header Parameter name should either be registered in the IANA "JSON Web Signature and Encryption Header Parameters" registry established by Section 9.1 or be a Public Name (a value that contains a Collision-Resistant Name). In each case, the definer of the name or value needs to take reasonable precautions to make sure they are in control of the part of the namespace they use to define the Header Parameter name.
使用JWSs的人可以定义其他头参数名称。但是，为了防止冲突，任何新的头参数名称都应该在第9.1节建立的IANA“JSON Web签名和加密头参数”注册表中注册，或者是一个公共名称（一个包含抗冲突名称的值）。在每种情况下，名称或值的定义者都需要采取合理的预防措施，以确保他们能够控制用于定义头参数名称的命名空间部分。
New Header Parameters should be introduced sparingly, as they can result in non-interoperable JWSs.
应该谨慎地引入新的头参数，因为它们可能导致不可互操作的JWS。
A producer and consumer of a JWS may agree to use Header Parameter names that are Private Names (names that are not Registered Header Parameter names (Section 4.1)) or Public Header Parameter names
JWS的生产者和消费者可能同意使用私有名称（未注册的头参数名称（第4.1节））或公共头参数名称的头参数名称
(Section 4.2). Unlike Public Header Parameter names, Private Header Parameter names are subject to collision and should be used with caution.
（第4.2节）。与公共标头参数名称不同，私有标头参数名称会发生冲突，应谨慎使用。
To create a JWS, the following steps are performed. The order of the steps is not significant in cases where there are no dependencies between the inputs and outputs of the steps.
要创建JWS，请执行以下步骤。在步骤的输入和输出之间没有依赖关系的情况下，步骤的顺序并不重要。
1. Create the content to be used as the JWS Payload.
1. 创建要用作JWS负载的内容。
2. Compute the encoded payload value BASE64URL(JWS Payload).
2. 计算编码的有效负载值BASE64URL（JWS有效负载）。
3. Create the JSON object(s) containing the desired set of Header Parameters, which together comprise the JOSE Header (the JWS Protected Header and/or the JWS Unprotected Header).
3. 创建包含所需的一组头参数的JSON对象，这些头参数共同构成JOSE头（JWS保护头和/或JWS未保护头）。
4. Compute the encoded header value BASE64URL(UTF8(JWS Protected Header)). If the JWS Protected Header is not present (which can only happen when using the JWS JSON Serialization and no "protected" member is present), let this value be the empty string.
4. 计算编码的头值BASE64URL（UTF8（JWS保护头））。如果JWS-Protected头不存在（这只能在使用JWS-JSON序列化且不存在“Protected”成员时发生），则将该值设为空字符串。
5. Compute the JWS Signature in the manner defined for the particular algorithm being used over the JWS Signing Input ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload)). The "alg" (algorithm) Header Parameter MUST be present in the JOSE Header, with the algorithm value accurately representing the algorithm used to construct the JWS Signature.
5. 按照为JWS签名输入ASCII（BASE64URL（UTF8（JWS保护头））| |'。| | BASE64URL（JWS有效负载））上使用的特定算法定义的方式计算JWS签名。“alg”（algorithm）头参数必须出现在JOSE头中，算法值准确地表示用于构造JWS签名的算法。
6. Compute the encoded signature value BASE64URL(JWS Signature).
6. 计算编码的签名值BASE64URL（JWS签名）。
7. If the JWS JSON Serialization is being used, repeat this process (steps 3-6) for each digital signature or MAC operation being performed.
7. 如果正在使用JWS JSON序列化，则对执行的每个数字签名或MAC操作重复此过程（步骤3-6）。
8. Create the desired serialized output. The JWS Compact Serialization of this result is BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) || '.' || BASE64URL(JWS Signature). The JWS JSON Serialization is described in Section 7.2.
8. 创建所需的序列化输出。此结果的JWS压缩序列化为BASE64URL（UTF8（JWS保护头））| |'。| | BASE64URL（JWS有效负载）| |'。| | BASE64URL（JWS签名）。JWS JSON序列化在第7.2节中进行了描述。
When validating a JWS, the following steps are performed. The order of the steps is not significant in cases where there are no dependencies between the inputs and outputs of the steps. If any of the listed steps fails, then the signature or MAC cannot be validated.
验证JWS时，将执行以下步骤。在步骤的输入和输出之间没有依赖关系的情况下，步骤的顺序并不重要。如果列出的任何步骤失败，则无法验证签名或MAC。
When there are multiple JWS Signature values, it is an application decision which of the JWS Signature values must successfully validate for the JWS to be accepted. In some cases, all must successfully validate, or the JWS will be considered invalid. In other cases, only a specific JWS Signature value needs to be successfully validated. However, in all cases, at least one JWS Signature value MUST successfully validate, or the JWS MUST be considered invalid.
当存在多个JWS签名值时，应用程序决定必须成功验证哪个JWS签名值才能接受JWS。在某些情况下，必须成功验证所有JWS，否则JWS将被视为无效。在其他情况下，只需要成功验证特定的JWS签名值。但是，在所有情况下，至少必须成功验证一个JWS签名值，否则JWS必须被视为无效。
1. Parse the JWS representation to extract the serialized values for the components of the JWS. When using the JWS Compact Serialization, these components are the base64url-encoded representations of the JWS Protected Header, the JWS Payload, and the JWS Signature, and when using the JWS JSON Serialization, these components also include the unencoded JWS Unprotected Header value. When using the JWS Compact Serialization, the JWS Protected Header, the JWS Payload, and the JWS Signature are represented as base64url-encoded values in that order, with each value being separated from the next by a single period ('.') character, resulting in exactly two delimiting period characters being used. The JWS JSON Serialization is described in Section 7.2.
1. 解析JWS表示以提取JWS组件的序列化值。当使用JWS紧凑序列化时，这些组件是JWS受保护的头、JWS有效负载和JWS签名的base64url编码表示，当使用JWS JSON序列化时，这些组件还包括未编码的JWS未受保护的头值。在使用JWS紧凑序列化时，JWS受保护的头、JWS有效负载和JWS签名按该顺序表示为base64url编码的值，每个值与下一个值之间用单个句点（'.'）字符分隔，从而正好使用两个定界句点字符。JWS JSON序列化在第7.2节中进行了描述。
2. Base64url-decode the encoded representation of the JWS Protected Header, following the restriction that no line breaks, whitespace, or other additional characters have been used.
2. Base64url解码受JWS保护的标头的编码表示形式，并遵循未使用换行符、空格或其他附加字符的限制。
3. Verify that the resulting octet sequence is a UTF-8-encoded representation of a completely valid JSON object conforming to RFC 7159 [RFC7159]; let the JWS Protected Header be this JSON object.
3. 验证生成的八位字节序列是符合RFC 7159[RFC7159]的完全有效JSON对象的UTF-8编码表示；让JWS受保护的头是这个JSON对象。
4. If using the JWS Compact Serialization, let the JOSE Header be the JWS Protected Header. Otherwise, when using the JWS JSON Serialization, let the JOSE Header be the union of the members of the corresponding JWS Protected Header and JWS Unprotected Header, all of which must be completely valid JSON objects. During this step, verify that the resulting JOSE Header does not contain duplicate Header Parameter names. When using the JWS
4. 如果使用JWS紧凑序列化，则让JOSE头成为JWS保护头。否则，在使用JWS JSON序列化时，让JOSE头成为相应JWS受保护头和JWS未受保护头的成员的并集，所有这些头都必须是完全有效的JSON对象。在此步骤中，验证生成的JOSE标头不包含重复的标头参数名称。使用JWS时
JSON Serialization, this restriction includes that the same Header Parameter name also MUST NOT occur in distinct JSON object values that together comprise the JOSE Header.
JSON序列化，此限制包括相同的头参数名称也不得出现在共同构成JOSE头的不同JSON对象值中。
5. Verify that the implementation understands and can process all fields that it is required to support, whether required by this specification, by the algorithm being used, or by the "crit" Header Parameter value, and that the values of those parameters are also understood and supported.
5. 验证实现是否理解并能够处理其需要支持的所有字段，无论是本规范、所用算法还是“crit”头参数值要求的字段，以及这些参数的值是否也被理解和支持。
6. Base64url-decode the encoded representation of the JWS Payload, following the restriction that no line breaks, whitespace, or other additional characters have been used.
6. Base64url对JWS有效负载的编码表示进行解码，并遵循未使用换行符、空格或其他附加字符的限制。
7. Base64url-decode the encoded representation of the JWS Signature, following the restriction that no line breaks, whitespace, or other additional characters have been used.
7. Base64url对JWS签名的编码表示形式进行解码，并遵守未使用换行符、空格或其他附加字符的限制。
8. Validate the JWS Signature against the JWS Signing Input ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload)) in the manner defined for the algorithm being used, which MUST be accurately represented by the value of the "alg" (algorithm) Header Parameter, which MUST be present. See Section 10.6 for security considerations on algorithm validation. Record whether the validation succeeded or not.
8. 根据JWS签名输入ASCII（BASE64URL（UTF8（JWS保护头））| | |'。| | BASE64URL（JWS有效负载））以为所用算法定义的方式验证JWS签名，该方法必须由必须存在的“alg”（算法）头参数的值准确表示。有关算法验证的安全注意事项，请参见第10.6节。记录验证是否成功。
9. If the JWS JSON Serialization is being used, repeat this process (steps 4-8) for each digital signature or MAC value contained in the representation.
9. 如果正在使用JWS JSON序列化，请对表示中包含的每个数字签名或MAC值重复此过程（步骤4-8）。
10. If none of the validations in step 9 succeeded, then the JWS MUST be considered invalid. Otherwise, in the JWS JSON Serialization case, return a result to the application indicating which of the validations succeeded and failed. In the JWS Compact Serialization case, the result can simply indicate whether or not the JWS was successfully validated.
10. 如果步骤9中的验证均未成功，则必须将JWS视为无效。否则，在JWS JSON序列化案例中，向应用程序返回一个结果，指示哪些验证成功，哪些验证失败。在JWS紧凑序列化案例中，结果可以简单地指示JWS是否已成功验证。
Finally, note that it is an application decision which algorithms may be used in a given context. Even if a JWS can be successfully validated, unless the algorithm(s) used in the JWS are acceptable to the application, it SHOULD consider the JWS to be invalid.
最后，请注意，在给定上下文中可以使用哪些算法是应用程序的决定。即使JWS可以被成功地验证，除非JWS中使用的算法对应用程序是可接受的，否则它应该考虑JWS无效。
Processing a JWS inevitably requires comparing known strings to members and values in JSON objects. For example, in checking what the algorithm is, the Unicode string "alg" will be checked against the member names in the JOSE Header to see if there is a matching
处理JWS不可避免地需要将已知字符串与JSON对象中的成员和值进行比较。例如，在检查算法时，将对照JOSE头中的成员名称检查Unicode字符串“alg”，以查看是否存在匹配
Header Parameter name. The same process is then used to determine if the value of the "alg" Header Parameter represents a supported algorithm.
标题参数名称。然后使用相同的过程确定“alg”头参数的值是否表示支持的算法。
The JSON rules for doing member name comparison are described in Section 8.3 of RFC 7159 [RFC7159]. Since the only string comparison operations that are performed are equality and inequality, the same rules can be used for comparing both member names and member values against known strings.
RFC 7159[RFC7159]第8.3节描述了用于进行成员名称比较的JSON规则。由于执行的唯一字符串比较操作是相等和不相等，因此可以使用相同的规则将成员名称和成员值与已知字符串进行比较。
These comparison rules MUST be used for all JSON string comparisons except in cases where the definition of the member explicitly calls out that a different comparison rule is to be used for that member value. Only the "typ" and "cty" member values defined in this specification do not use these comparison rules.
这些比较规则必须用于所有JSON字符串比较，除非该成员的定义明确要求对该成员值使用不同的比较规则。只有本规范中定义的“typ”和“cty”成员值不使用这些比较规则。
Some applications may include case-insensitive information in a case-sensitive value, such as including a DNS name as part of a "kid" (key ID) value. In those cases, the application may need to define a convention for the canonical case to use for representing the case-insensitive portions, such as lowercasing them, if more than one party might need to produce the same value so that they can be compared. (However, if all other parties consume whatever value the producing party emitted verbatim without attempting to compare it to an independently produced value, then the case used by the producer will not matter.)
一些应用程序可能在区分大小写的值中包含不区分大小写的信息，例如将DNS名称作为“kid”（密钥ID）值的一部分。在这些情况下，如果多个参与方可能需要生成相同的值以便可以对它们进行比较，则应用程序可能需要定义规范大小写用于表示不区分大小写的部分的约定，例如将它们小写。（但是，如果所有其他方使用制作方逐字发出的任何值，而不尝试将其与独立制作的值进行比较，则制作方使用的案例将不重要。）
Also, see the JSON security considerations in Section 10.12 and the Unicode security considerations in Section 10.13.
另外，请参阅第10.12节中的JSON安全注意事项和第10.13节中的Unicode安全注意事项。
It is necessary for the recipient of a JWS to be able to determine the key that was employed for the digital signature or MAC operation. The key employed can be identified using the Header Parameter methods described in Section 4.1 or can be identified using methods that are outside the scope of this specification. Specifically, the Header Parameters "jku", "jwk", "kid", "x5u", "x5c", "x5t", and "x5t#S256" can be used to identify the key used. These Header Parameters MUST be integrity protected if the information that they convey is to be utilized in a trust decision; however, if the only information used in the trust decision is a key, these parameters need not be integrity protected, since changing them in a way that causes a different key to be used will cause the validation to fail.
JWS的接收者必须能够确定用于数字签名或MAC操作的密钥。使用的键可以使用第4.1节中描述的标题参数方法识别，也可以使用本规范范围之外的方法识别。具体而言，头参数“jku”、“jwk”、“kid”、“x5u”、“x5c”、“x5t”和“x5t#S256”可用于识别所使用的密钥。如果要在信任决策中使用这些头参数所传递的信息，则必须对其进行完整性保护；但是，如果信任决策中使用的唯一信息是密钥，则不需要对这些参数进行完整性保护，因为以导致使用不同密钥的方式更改这些参数将导致验证失败。
The producer SHOULD include sufficient information in the Header Parameters to identify the key used, unless the application uses another means or convention to determine the key used. Validation of
生产者应在标题参数中包含足够的信息，以识别所使用的密钥，除非应用程序使用其他方法或约定来确定所使用的密钥。验证
the signature or MAC fails when the algorithm used requires a key (which is true of all algorithms except for "none") and the key used cannot be determined.
当所使用的算法需要密钥（除“无”之外的所有算法都是如此）且无法确定所使用的密钥时，签名或MAC失败。
The means of exchanging any shared symmetric keys used is outside the scope of this specification.
交换使用的任何共享对称密钥的方法不在本规范的范围内。
Also, see Appendix D for notes on possible key selection algorithms.
此外，有关可能的密钥选择算法的说明，请参见附录D。
JWSs use one of two serializations: the JWS Compact Serialization or the JWS JSON Serialization. Applications using this specification need to specify what serialization and serialization features are used for that application. For instance, applications might specify that only the JWS JSON Serialization is used, that only JWS JSON Serialization support for a single signature or MAC value is used, or that support for multiple signatures and/or MAC values is used. JWS implementations only need to implement the features needed for the applications they are designed to support.
JWS使用两种序列化之一：JWS紧凑序列化或JWS JSON序列化。使用此规范的应用程序需要指定该应用程序使用的序列化和序列化功能。例如，应用程序可能指定只使用JWS JSON序列化，只使用对单个签名或MAC值的JWS JSON序列化支持，或者使用对多个签名和/或MAC值的支持。JWS实现只需要实现其设计支持的应用程序所需的功能。
The JWS Compact Serialization represents digitally signed or MACed content as a compact, URL-safe string. This string is:
JWS紧凑序列化将数字签名或标记的内容表示为紧凑的URL安全字符串。此字符串是：
BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) || '.' || BASE64URL(JWS Signature)
BASE64URL（UTF8（JWS保护头））| |'。| | BASE64URL（JWS有效负载）| |'。| | BASE64URL（JWS签名）
Only one signature/MAC is supported by the JWS Compact Serialization and it provides no syntax to represent a JWS Unprotected Header value.
JWS紧凑序列化只支持一个签名/MAC，并且它不提供语法来表示JWS未受保护的头值。
The JWS JSON Serialization represents digitally signed or MACed content as a JSON object. This representation is neither optimized for compactness nor URL-safe.
JWS JSON序列化将数字签名或标记的内容表示为JSON对象。此表示既不优化紧凑性，也不优化URL安全性。
Two closely related syntaxes are defined for the JWS JSON Serialization: a fully general syntax, with which content can be secured with more than one digital signature and/or MAC operation, and a flattened syntax, which is optimized for the single digital signature or MAC case.
JWS JSON序列化定义了两个密切相关的语法：一个完全通用的语法，可以使用多个数字签名和/或MAC操作保护内容；一个扁平语法，针对单个数字签名或MAC情况进行了优化。
The following members are defined for use in top-level JSON objects used for the fully general JWS JSON Serialization syntax:
定义了以下成员，以便在用于完全通用JWS JSON序列化语法的顶级JSON对象中使用：
payload The "payload" member MUST be present and contain the value BASE64URL(JWS Payload).
payload“payload”成员必须存在并包含值BASE64URL（JWS payload）。
signatures The "signatures" member value MUST be an array of JSON objects. Each object represents a signature or MAC over the JWS Payload and the JWS Protected Header.
签名“signatures”成员值必须是JSON对象的数组。每个对象表示JWS有效负载和JWS保护头上的签名或MAC。
The following members are defined for use in the JSON objects that are elements of the "signatures" array:
定义了以下成员，以便在作为“签名”数组元素的JSON对象中使用：
protected The "protected" member MUST be present and contain the value BASE64URL(UTF8(JWS Protected Header)) when the JWS Protected Header value is non-empty; otherwise, it MUST be absent. These Header Parameter values are integrity protected.
受保护当JWS受保护标头值为非空时，“受保护”成员必须存在并包含值BASE64URL（UTF8（JWS受保护标头））；否则，它必须缺席。这些标头参数值受完整性保护。
header The "header" member MUST be present and contain the value JWS Unprotected Header when the JWS Unprotected Header value is non-empty; otherwise, it MUST be absent. This value is represented as an unencoded JSON object, rather than as a string. These Header Parameter values are not integrity protected.
header当JWS Unprotected header值为非空时，“header”成员必须存在并包含值JWS Unprotected header；否则，它必须缺席。此值表示为未编码的JSON对象，而不是字符串。这些标头参数值不受完整性保护。
signature The "signature" member MUST be present and contain the value BASE64URL(JWS Signature).
签名“签名”成员必须存在并包含值BASE64URL（JWS签名）。
At least one of the "protected" and "header" members MUST be present for each signature/MAC computation so that an "alg" Header Parameter value is conveyed.
每个签名/MAC计算必须至少存在一个“受保护”和“报头”成员，以便传递“alg”报头参数值。
Additional members can be present in both the JSON objects defined above; if not understood by implementations encountering them, they MUST be ignored.
在上面定义的两个JSON对象中都可以存在其他成员；如果遇到它们的实现无法理解它们，则必须忽略它们。
The Header Parameter values used when creating or validating individual signature or MAC values are the union of the two sets of Header Parameter values that may be present: (1) the JWS Protected Header represented in the "protected" member of the signature/MAC's array element, and (2) the JWS Unprotected Header in the "header"
创建或验证单个签名或MAC值时使用的头参数值是可能存在的两组头参数值的并集：（1）签名/MAC数组元素的“受保护”成员中表示的JWS受保护头，以及（2）“头”中表示的JWS未受保护头
member of the signature/MAC's array element. The union of these sets of Header Parameters comprises the JOSE Header. The Header Parameter names in the two locations MUST be disjoint.
签名/MAC的数组元素的成员。这些标头参数集的并集包括JOSE标头。两个位置中的标头参数名称必须不相交。
Each JWS Signature value is computed using the parameters of the corresponding JOSE Header value in the same manner as for the JWS Compact Serialization. This has the desirable property that each JWS Signature value represented in the "signatures" array is identical to the value that would have been computed for the same parameter in the JWS Compact Serialization, provided that the JWS Protected Header value for that signature/MAC computation (which represents the integrity-protected Header Parameter values) matches that used in the JWS Compact Serialization.
每个JWS签名值都是使用相应JOSE头值的参数以与JWS紧凑序列化相同的方式计算的。这有一个可取的特性，即“signatures”数组中表示的每个JWS签名值与JWS紧凑序列化中为同一参数计算的值相同，前提是该签名/MAC计算的JWS保护头值（表示完整性保护的头参数值）与JWS紧凑序列化中使用的匹配。
In summary, the syntax of a JWS using the general JWS JSON Serialization is as follows:
总之，使用通用JWS JSON序列化的JWS的语法如下：
{
"payload":"<payload contents>",
"signatures":[
{"protected":"<integrity-protected header 1 contents>",
"header":<non-integrity-protected header 1 contents>,
"signature":"<signature 1 contents>"},
...
{"protected":"<integrity-protected header N contents>",
"header":<non-integrity-protected header N contents>,
"signature":"<signature N contents>"}]
}
{
"payload":"<payload contents>",
"signatures":[
{"protected":"<integrity-protected header 1 contents>",
"header":<non-integrity-protected header 1 contents>,
"signature":"<signature 1 contents>"},
...
{"protected":"<integrity-protected header N contents>",
"header":<non-integrity-protected header N contents>,
"signature":"<signature N contents>"}]
}
See Appendix A.6 for an example JWS using the general JWS JSON Serialization syntax.
有关使用通用JWS JSON序列化语法的JWS示例，请参见附录A.6。
The flattened JWS JSON Serialization syntax is based upon the general syntax but flattens it, optimizing it for the single digital signature/MAC case. It flattens it by removing the "signatures" member and instead placing those members defined for use in the "signatures" array (the "protected", "header", and "signature" members) in the top-level JSON object (at the same level as the "payload" member).
扁平化JWS JSON序列化语法基于通用语法，但对其进行了扁平化，针对单个数字签名/MAC情况对其进行了优化。它通过删除“signatures”成员，将定义用于“signatures”数组的成员（“protected”、“header”和“signature”成员）放在顶级JSON对象（与“payload”成员处于同一级别）中，从而将其展平。
The "signatures" member MUST NOT be present when using this syntax. Other than this syntax difference, JWS JSON Serialization objects using the flattened syntax are processed identically to those using the general syntax.
使用此语法时，“签名”成员不得出现。除了这种语法差异之外，使用平坦语法的JWS JSON序列化对象的处理方式与使用常规语法的JWS JSON序列化对象的处理方式相同。
In summary, the syntax of a JWS using the flattened JWS JSON Serialization is as follows:
总之，使用扁平化JWS JSON序列化的JWS的语法如下：
{
"payload":"<payload contents>",
"protected":"<integrity-protected header contents>",
"header":<non-integrity-protected header contents>,
"signature":"<signature contents>"
}
{
"payload":"<payload contents>",
"protected":"<integrity-protected header contents>",
"header":<non-integrity-protected header contents>,
"signature":"<signature contents>"
}
See Appendix A.7 for an example JWS using the flattened JWS JSON Serialization syntax.
有关使用扁平化JWS JSON序列化语法的JWS示例，请参见附录A.7。
Implementations supporting the "jku" and/or "x5u" Header Parameters MUST support TLS. Which TLS version(s) ought to be implemented will vary over time and depend on the widespread deployment and known security vulnerabilities at the time of implementation. At the time of this writing, TLS version 1.2 [RFC5246] is the most recent version.
支持“jku”和/或“x5u”头参数的实现必须支持TLS。应实施哪些TLS版本将随时间而变化，并取决于广泛的部署和实施时已知的安全漏洞。在撰写本文时，TLS版本1.2[RFC5246]是最新版本。
To protect against information disclosure and tampering, confidentiality protection MUST be applied using TLS with a ciphersuite that provides confidentiality and integrity protection. See current publications by the IETF TLS working group, including RFC 6176 [RFC6176], for guidance on the ciphersuites currently considered to be appropriate for use. Also, see "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)" [RFC7525] for recommendations on improving the security of software and services using TLS.
为了防止信息泄露和篡改，必须使用TLS和提供机密性和完整性保护的密码套件应用机密性保护。参见IETF TLS工作组的最新出版物，包括RFC 6176[RFC6176]，了解目前认为适合使用的密码套件指南。此外，请参阅“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”[RFC7525]，了解使用TLS改进软件和服务安全性的建议。
Whenever TLS is used, the identity of the service provider encoded in the TLS server certificate MUST be verified using the procedures described in Section 6 of RFC 6125 [RFC6125].
无论何时使用TLS，必须使用RFC 6125[RFC6125]第6节中描述的程序验证TLS服务器证书中编码的服务提供商的身份。
The following registration procedure is used for all the registries established by this specification.
以下注册程序适用于本规范建立的所有注册中心。
Values are registered on a Specification Required [RFC5226] basis after a three-week review period on the jose-reg-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published.
在jose reg上经过三周的审查后，根据规范要求[RFC5226]登记数值-review@ietf.org根据一名或多名指定专家的建议，提供邮件列表。但是，为了允许在发布之前分配值，指定专家在确信此类规范将发布后，可批准注册。
Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register header parameter: example").
发送到邮件列表供审查的注册请求应使用适当的主题（例如，“注册请求标题参数：示例”）。
Within the review period, the Designated Experts will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@ietf.org mailing list) for resolution.
在审查期内，指定专家将批准或拒绝注册请求，并将此决定告知审查名单和IANA。拒绝应包括解释，以及（如适用）关于如何使请求成功的建议。超过21天未确定的注册请求可提请IESG注意（使用iesg@ietf.org邮件列表）以供解决。
Criteria that should be applied by the Designated Experts includes determining whether the proposed registration duplicates existing functionality, whether it is likely to be of general applicability or useful only for a single application, and whether the registration description is clear.
指定专家应适用的标准包括确定拟议登记是否与现有功能重复，是否可能具有普遍适用性或仅对单一申请有用，以及登记说明是否明确。
IANA must only accept registry updates from the Designated Experts and should direct all requests for registration to the review mailing list.
IANA必须只接受指定专家的注册更新，并将所有注册请求发送至审查邮件列表。
It is suggested that multiple Designated Experts be appointed who are able to represent the perspectives of different applications using this specification, in order to enable broadly informed review of registration decisions. In cases where a registration decision could be perceived as creating a conflict of interest for a particular Expert, that Expert should defer to the judgment of the other Experts.
建议任命多名指定专家，他们能够代表使用本规范的不同应用的观点，以便对注册决定进行广泛知情的审查。如果注册决定可能被视为对某一专家造成利益冲突，该专家应服从其他专家的判断。
This specification establishes the IANA "JSON Web Signature and Encryption Header Parameters" registry for Header Parameter names. The registry records the Header Parameter name and a reference to the specification that defines it. The same Header Parameter name can be registered multiple times, provided that the parameter usage is compatible between the specifications. Different registrations of the same Header Parameter name will typically use different Header Parameter Usage Locations values.
本规范为标题参数名称建立IANA“JSON Web签名和加密标题参数”注册表。注册表记录头参数名称和对定义它的规范的引用。如果参数用法在规范之间兼容，则可以多次注册相同的头参数名称。相同标头参数名称的不同注册通常会使用不同的标头参数使用位置值。
Header Parameter Name: The name requested (e.g., "kid"). Because a core goal of this specification is for the resulting representations to be compact, it is RECOMMENDED that the name be short -- not to exceed 8 characters without a compelling reason to do so. This name is
标题参数名称：请求的名称（例如，“kid”）。由于本规范的一个核心目标是使生成的表示形式紧凑，因此建议名称简短——如果没有令人信服的理由，名称不能超过8个字符。这个名字是
case sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception.
区分大小写。名称不得以不区分大小写的方式与其他注册名称匹配，除非指定专家声明有令人信服的理由允许例外。
Header Parameter Description: Brief description of the Header Parameter (e.g., "Key ID").
标题参数说明：标题参数的简要说明（例如，“密钥ID”）。
Header Parameter Usage Location(s): The Header Parameter usage locations, which should be one or more of the values "JWS" or "JWE".
标题参数使用位置：标题参数使用位置，应该是一个或多个值“JWS”或“JWE”。
Change Controller: For Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.
更改控制器：对于标准跟踪RFC，请列出“IESG”。对于其他人，请提供责任方的名称。还可以包括其他详细信息（例如，邮政地址、电子邮件地址、主页URI）。
Specification Document(s): Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required.
规范文档：指指定参数的一个或多个文档，最好包括可用于检索文档副本的URI。也可以包括相关章节的指示，但不需要。
This section registers the Header Parameter names defined in Section 4.1 in this registry.
本节在此注册表中注册第4.1节中定义的标题参数名称。
o Header Parameter Name: "alg" o Header Parameter Description: Algorithm o Header Parameter Usage Location(s): JWS o Change Controller: IESG o Specification Document(s): Section 4.1.1 of RFC 7515
o 标题参数名称：“alg”o标题参数说明：算法o标题参数使用位置：JWS o变更控制器：IESG o规范文件：RFC 7515第4.1.1节
o Header Parameter Name: "jku" o Header Parameter Description: JWK Set URL o Header Parameter Usage Location(s): JWS o Change Controller: IESG o Specification Document(s): Section 4.1.2 of RFC 7515
o 标题参数名称：“jku”o标题参数说明：JWK设置URL o标题参数使用位置：JWS o变更控制器：IESG o规范文件：RFC 7515第4.1.2节
o Header Parameter Name: "jwk" o Header Parameter Description: JSON Web Key o Header Parameter Usage Location(s): JWS o Change Controller: IESG o Specification Document(s): Section 4.1.3 of RFC 7515
o 标题参数名称：“jwk”o标题参数说明：JSON Web密钥o标题参数使用位置：JWS o变更控制器：IESG o规范文档：RFC 7515第4.1.3节
o Header Parameter Name: "kid" o Header Parameter Description: Key ID o Header Parameter Usage Location(s): JWS o Change Controller: IESG o Specification Document(s): Section 4.1.4 of RFC 7515
o 标题参数名称：“kid”o标题参数说明：密钥ID o标题参数使用位置：JWS o变更控制器：IESG o规范文件：RFC 7515第4.1.4节
o Header Parameter Name: "x5u" o Header Parameter Description: X.509 URL o Header Parameter Usage Location(s): JWS o Change Controller: IESG o Specification Document(s): Section 4.1.5 of RFC 7515
o 标题参数名称：“x5u”o标题参数说明：X.509 URL o标题参数使用位置：JWS o变更控制器：IESG o规范文件：RFC 7515第4.1.5节
o Header Parameter Name: "x5c" o Header Parameter Description: X.509 Certificate Chain o Header Parameter Usage Location(s): JWS o Change Controller: IESG o Specification Document(s): Section 4.1.6 of RFC 7515
o 标题参数名称：“x5c”o标题参数说明：X.509证书链o标题参数使用位置：JWS o更改控制器：IESG o规范文档：RFC 7515第4.1.6节
o Header Parameter Name: "x5t" o Header Parameter Description: X.509 Certificate SHA-1 Thumbprint o Header Parameter Usage Location(s): JWS o Change Controller: IESG o Specification Document(s): Section 4.1.7 of RFC 7515
o 标题参数名称：“x5t”o标题参数说明：X.509证书SHA-1指纹o标题参数使用位置：JWS o变更控制器：IESG o规范文件：RFC 7515第4.1.7节
o Header Parameter Name: "x5t#S256" o Header Parameter Description: X.509 Certificate SHA-256 Thumbprint o Header Parameter Usage Location(s): JWS o Change Controller: IESG o Specification Document(s): Section 4.1.8 of RFC 7515
o 标题参数名称：“x5t#S256”o标题参数说明：X.509证书SHA-256指纹o标题参数使用位置：JWS o变更控制器：IESG o规范文件：RFC 7515第4.1.8节
o Header Parameter Name: "typ" o Header Parameter Description: Type o Header Parameter Usage Location(s): JWS o Change Controller: IESG o Specification Document(s): Section 4.1.9 of RFC 7515
o 标题参数名称：“类型”o标题参数说明：类型o标题参数使用位置：JWS o变更控制器：IESG o规范文件：RFC 7515第4.1.9节
o Header Parameter Name: "cty" o Header Parameter Description: Content Type o Header Parameter Usage Location(s): JWS o Change Controller: IESG o Specification Document(s): Section 4.1.10 of RFC 7515
o 标题参数名称：“cty”o标题参数说明：内容类型o标题参数使用位置：JWS o变更控制器：IESG o规范文件：RFC 7515第4.1.10节
o Header Parameter Name: "crit" o Header Parameter Description: Critical o Header Parameter Usage Location(s): JWS o Change Controller: IESG o Specification Document(s): Section 4.1.11 of RFC 7515
o 标题参数名称：“crit”o标题参数说明：关键o标题参数使用位置：JWS o变更控制器：IESG o规范文件：RFC 7515第4.1.11节
This section registers the "application/jose" media type [RFC2046] in the "Media Types" registry [IANA.MediaTypes] in the manner described in RFC 6838 [RFC6838], which can be used to indicate that the content is a JWS or JWE using the JWS Compact Serialization or the JWE Compact Serialization. This section also registers the "application/ jose+json" media type in the "Media Types" registry, which can be used to indicate that the content is a JWS or JWE using the JWS JSON Serialization or the JWE JSON Serialization.
本节以RFC 6838[RFC6838]中所述的方式在“媒体类型”注册表[IANA.MediaTypes]中注册“应用程序/jose”媒体类型[RFC2046]，可用于指示内容是使用JWS压缩序列化或JWE压缩序列化的JWS或JWE。本节还将“application/jose+json”媒体类型注册到“media Types”注册表中，该注册表可用于指示内容是使用JWS json序列化或JWE json序列化的JWS或JWE。
o Type name: application o Subtype name: jose o Required parameters: n/a o Optional parameters: n/a o Encoding considerations: 8bit; application/jose values are encoded as a series of base64url-encoded values (some of which may be the empty string), each separated from the next by a single period ('.') character. o Security considerations: See the Security Considerations section of RFC 7515. o Interoperability considerations: n/a o Published specification: RFC 7515 o Applications that use this media type: OpenID Connect, Mozilla Persona, Salesforce, Google, Android, Windows Azure, Xbox One, Amazon Web Services, and numerous others that use JWTs o Fragment identifier considerations: n/a o Additional information:
o 类型名称：应用程序o子类型名称：o必需参数：n/a o可选参数：n/a o编码注意事项：8位；application/jose值编码为一系列base64url编码值（其中一些可能是空字符串），每个值与下一个值之间用单个句点（'.'）字符分隔。o安全注意事项：参见RFC 7515的安全注意事项部分。o互操作性注意事项：不适用o发布的规范：RFC 7515 o使用此媒体类型的应用程序：OpenID Connect、Mozilla Persona、Salesforce、Google、Android、Windows Azure、Xbox One、Amazon Web Services，以及许多其他使用JWTs的应用程序o片段标识符注意事项：不适用o其他信息：
Magic number(s): n/a
File extension(s): n/a
Macintosh file type code(s): n/a
Magic number(s): n/a
File extension(s): n/a
Macintosh file type code(s): n/a
o Person & email address to contact for further information: Michael B. Jones, mbj@microsoft.com o Intended usage: COMMON o Restrictions on usage: none o Author: Michael B. Jones, mbj@microsoft.com o Change Controller: IESG o Provisional registration? No
o 联系人和电子邮件地址，以获取更多信息：Michael B.Jones，mbj@microsoft.como预期用途：常见o使用限制：无o作者：Michael B.Jones，mbj@microsoft.como变更控制员：IESG o临时注册？不
o Type name: application o Subtype name: jose+json o Required parameters: n/a o Optional parameters: n/a o Encoding considerations: 8bit; application/jose+json values are represented as a JSON Object; UTF-8 encoding SHOULD be employed for the JSON object. o Security considerations: See the Security Considerations section of RFC 7515 o Interoperability considerations: n/a o Published specification: RFC 7515 o Applications that use this media type: Nimbus JOSE + JWT library o Fragment identifier considerations: n/a o Additional information:
o 类型名称：应用程序o子类型名称：jose+json o必需参数：n/a o可选参数：n/a o编码注意事项：8bit；application/jose+json值表示为一个json对象；JSON对象应采用UTF-8编码。o安全注意事项：请参阅RFC 7515的安全注意事项部分o互操作性注意事项：不适用o已发布的规范：RFC 7515 o使用此媒体类型的应用程序：Nimbus JOSE+JWT库o片段标识符注意事项：不适用o其他信息：
Magic number(s): n/a
File extension(s): n/a
Macintosh file type code(s): n/a
Magic number(s): n/a
File extension(s): n/a
Macintosh file type code(s): n/a
o Person & email address to contact for further information: Michael B. Jones, mbj@microsoft.com o Intended usage: COMMON o Restrictions on usage: none o Author: Michael B. Jones, mbj@microsoft.com o Change Controller: IESG o Provisional registration? No
o 联系人和电子邮件地址，以获取更多信息：Michael B.Jones，mbj@microsoft.como预期用途：常见o使用限制：无o作者：Michael B.Jones，mbj@microsoft.como变更控制员：IESG o临时注册？不
All of the security issues that are pertinent to any cryptographic application must be addressed by JWS/JWE/JWK agents. Among these issues are protecting the user's asymmetric private and symmetric secret keys and employing countermeasures to various attacks.
与任何加密应用程序相关的所有安全问题都必须由JWS/JWE/JWK代理解决。这些问题包括保护用户的非对称私钥和对称密钥以及对各种攻击采取对策。
All the security considerations in "XML Signature Syntax and Processing Version 2.0" [W3C.NOTE-xmldsig-core2-20130411], also apply to this specification, other than those that are XML specific. Likewise, many of the best practices documented in "XML Signature Best Practices" [W3C.NOTE-xmldsig-bestpractices-20130411] also apply to this specification, other than those that are XML specific.
“XML签名语法和处理版本2.0”[W3C.NOTE-xmldsig-core2-20130411]中的所有安全注意事项也适用于本规范，但特定于XML的除外。类似地，“XML签名最佳实践”[W3C.NOTE-xmldsig-bestpractices-20130411]中记录的许多最佳实践也适用于本规范，而不是特定于XML的。
Keys are only as strong as the amount of entropy used to generate them. A minimum of 128 bits of entropy should be used for all keys, and depending upon the application context, more may be required.
关键点的强度取决于生成它们所用的熵的大小。所有密钥至少应使用128位的熵，根据应用程序上下文，可能需要更多的熵。
Implementations must randomly generate public/private key pairs, MAC keys, and padding values. The use of inadequate pseudorandom number generators (PRNGs) to generate cryptographic keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of possibilities rather than brute-force searching the whole key space. The generation of quality random numbers is difficult. RFC 4086 [RFC4086] offers important guidance in this area.
实现必须随机生成公钥/私钥对、MAC密钥和填充值。使用不充分的伪随机数生成器（PRNG）生成加密密钥可能导致很少或没有安全性。攻击者可能会发现复制生成密钥的PRNG环境更容易，搜索生成的一小部分可能性，而不是暴力搜索整个密钥空间。生成高质量的随机数是困难的。RFC 4086[RFC4086]在这方面提供了重要的指导。
Implementations must protect the signer's private key. Compromise of the signer's private key permits an attacker to masquerade as the signer.
实现必须保护签名者的私钥。签名者私钥的泄露允许攻击者伪装成签名者。
Implementations must protect the MAC key. Compromise of the MAC key may result in undetectable modification of the authenticated content.
实现必须保护MAC密钥。MAC密钥的泄露可能会导致对认证内容进行无法检测的修改。
The key management technique employed to obtain public keys must authenticate the origin of the key; otherwise, it is unknown what party signed the message.
用于获取公钥的密钥管理技术必须验证密钥的来源；否则，不知道是哪一方签署了该消息。
Likewise, the key management technique employed to distribute MAC keys must provide data origin authentication; otherwise, the contents are delivered with integrity from an unknown source.
同样，用于分发MAC密钥的密钥管理技术必须提供数据源认证；否则，内容将从未知来源完整地交付。
See Section 8.1 of [JWA] for security considerations on cryptographic agility.
有关加密灵活性的安全注意事项，请参见[JWA]第8.1节。
While MACs and digital signatures can both be used for integrity checking, there are some significant differences between the security properties that each of them provides. These need to be taken into consideration when designing protocols and selecting the algorithms to be used in protocols.
虽然MAC和数字签名都可以用于完整性检查，但它们各自提供的安全属性之间存在一些显著差异。在设计协议和选择协议中使用的算法时，需要考虑这些因素。
Both signatures and MACs provide for integrity checking -- verifying that the message has not been modified since the integrity value was computed. However, MACs provide for origination identification only under specific circumstances. It can normally be assumed that a private key used for a signature is only in the hands of a single entity (although perhaps a distributed entity, in the case of
签名和MAC都提供完整性检查——验证消息在计算完整性值后是否未被修改。然而，MAC仅在特定情况下提供来源识别。通常可以假设，用于签名的私钥仅在单个实体手中（尽管在特定情况下可能是分布式实体）
replicated servers); however, a MAC key needs to be in the hands of all the entities that use it for integrity computation and checking. Validation of a MAC only provides corroboration that the message was generated by one of the parties that knows the symmetric MAC key. This means that origination can only be determined if a MAC key is known only to two entities and the recipient knows that it did not create the message. MAC validation cannot be used to prove origination to a third party.
复制服务器）；但是，MAC密钥需要掌握在所有使用它进行完整性计算和检查的实体手中。MAC的验证仅提供消息由知道对称MAC密钥的一方生成的确证。这意味着，只有当只有两个实体知道MAC密钥并且接收方知道它没有创建消息时，才能确定发起。MAC验证不能用于向第三方证明来源。
The digital signature representations for some algorithms include information about the algorithm used inside the signature value. For instance, signatures produced with RSASSA-PKCS1-v1_5 [RFC3447] encode the hash function used, and many libraries actually use the hash algorithm specified inside the signature when validating the signature. When using such libraries, as part of the algorithm validation performed, implementations MUST ensure that the algorithm information encoded in the signature corresponds to that specified with the "alg" Header Parameter. If this is not done, an attacker could claim to have used a strong hash algorithm while actually using a weak one represented in the signature value.
某些算法的数字签名表示包括签名值中使用的算法的相关信息。例如，使用RSASSA-PKCS1-v1_5[RFC3447]生成的签名对使用的哈希函数进行编码，许多库在验证签名时实际使用签名中指定的哈希算法。当使用这些库时，作为执行的算法验证的一部分，实现必须确保签名中编码的算法信息与“alg”头参数指定的算法信息相对应。如果不这样做，攻击者可能会声称使用了强哈希算法，而实际上使用了签名值中表示的弱哈希算法。
In some usages of JWS, there is a risk of algorithm substitution attacks, in which an attacker can use an existing digital signature value with a different signature algorithm to make it appear that a signer has signed something that it has not. These attacks have been discussed in detail in the context of Cryptographic Message Syntax (CMS) [RFC6211]. This risk arises when all of the following are true:
在JWS的某些用法中，存在算法替换攻击的风险，在这种情况下，攻击者可以使用具有不同签名算法的现有数字签名值，使签名者似乎签署了它没有签署的东西。这些攻击已在加密消息语法（CMS）[RFC6211]的上下文中详细讨论。当以下所有情况均为真时，就会出现这种风险：
o Verifiers of a signature support multiple algorithms.
o 签名的验证器支持多种算法。
o Given an existing signature, an attacker can find another payload that produces the same signature value with a different algorithm.
o 给定一个现有签名，攻击者可以找到另一个使用不同算法生成相同签名值的有效负载。
o The payload crafted by the attacker is valid in the application context.
o 攻击者精心编制的有效负载在应用程序上下文中有效。
There are several ways for an application to mitigate algorithm substitution attacks:
应用程序有几种方法可以减轻算法替换攻击：
o Use only digital signature algorithms that are not vulnerable to substitution attacks. Substitution attacks are only feasible if an attacker can compute pre-images for a hash function accepted by
o 仅使用不易受替换攻击的数字签名算法。替换攻击只有在攻击者能够为用户接受的哈希函数计算预映像时才可行
the recipient. All JWA-defined signature algorithms use SHA-2 hashes, for which there are no known pre-image attacks, as of the time of this writing.
收件人。截至本文撰写之时，所有JWA定义的签名算法都使用SHA-2散列，没有已知的图像前攻击。
o Require that the "alg" Header Parameter be carried in the JWS Protected Header. (This is always the case when using the JWS Compact Serialization and is the approach taken by CMS [RFC6211].)
o 要求在JWS受保护的标头中携带“alg”标头参数。（使用JWS紧凑序列化时总是这样，CMS[RFC6211]采用这种方法。）
o Include a field containing the algorithm in the application payload, and require that it be matched with the "alg" Header Parameter during verification. (This is the approach taken by PKIX [RFC5280].)
o 在应用程序有效负载中包含包含算法的字段，并要求在验证期间将其与“alg”头参数匹配。（这是PKIX[RFC5280]采用的方法。）
Creators of JWSs should not allow third parties to insert arbitrary content into the message without adding entropy not controlled by the third party.
JWSs的创建者不应允许第三方在不添加不受第三方控制的熵的情况下向消息中插入任意内容。
When cryptographic algorithms are implemented in such a way that successful operations take a different amount of time than unsuccessful operations, attackers may be able to use the time difference to obtain information about the keys employed. Therefore, such timing differences must be avoided.
当加密算法的实现方式使得成功操作所需的时间与不成功操作所需的时间不同时，攻击者可能会利用时间差获取有关所用密钥的信息。因此，必须避免这种时间差异。
While not directly in scope for this specification, note that applications using JWS (or JWE) objects can thwart replay attacks by including a unique message identifier as integrity-protected content in the JWS (or JWE) message and having the recipient verify that the message has not been previously received or acted upon.
虽然不直接在本规范的范围内，但请注意，使用JWS（或JWE）对象的应用程序可以通过在JWS（或JWE）消息中包含一个唯一的消息标识符作为完整性保护的内容，并让收件人验证消息之前未被接收或处理，从而阻止重播攻击。
A SHA-1 hash is used when computing "x5t" (X.509 certificate SHA-1 thumbprint) values, for compatibility reasons. Should an effective means of producing SHA-1 hash collisions be developed and should an attacker wish to interfere with the use of a known certificate on a given system, this could be accomplished by creating another certificate whose SHA-1 hash value is the same and adding it to the certificate store used by the intended victim. A prerequisite to this attack succeeding is the attacker having write access to the intended victim's certificate store.
出于兼容性原因，计算“x5t”（X.509证书SHA-1指纹）值时使用SHA-1哈希。如果开发了产生SHA-1哈希冲突的有效方法，并且如果攻击者希望干扰给定系统上已知证书的使用，则可以通过创建另一个SHA-1哈希值相同的证书并将其添加到目标受害者使用的证书存储中来实现。此攻击成功的先决条件是攻击者对目标受害者的证书存储具有写访问权。
Alternatively, the "x5t#S256" (X.509 certificate SHA-256 thumbprint) Header Parameter could be used instead of "x5t". However, at the time of this writing, no development platform is known to support SHA-256 certificate thumbprints.
或者，可以使用“x5t#S256”（X.509证书SHA-256指纹）头参数代替“x5t”。然而，在撰写本文时，还没有开发平台支持SHA-256证书指纹。
Strict JSON [RFC7159] validation is a security requirement. If malformed JSON is received, then the intent of the producer is impossible to reliably discern. Ambiguous and potentially exploitable situations could arise if the JSON parser used does not reject malformed JSON syntax. In particular, any JSON inputs not conforming to the JSON-text syntax defined in RFC 7159 MUST be rejected in their entirety by JSON parsers.
严格的JSON[RFC7159]验证是一项安全要求。如果接收到格式错误的JSON，则无法可靠地识别生产者的意图。如果使用的JSON解析器不拒绝格式错误的JSON语法，则可能会出现歧义和可能被利用的情况。特别是，JSON解析器必须完全拒绝任何不符合RFC 7159中定义的JSON文本语法的JSON输入。
Section 4 of "The JavaScript Object Notation (JSON) Data Interchange Format" [RFC7159] states, "The names within an object SHOULD be unique", whereas this specification states that
“JavaScript对象表示法（JSON）数据交换格式”[RFC7159]第4节指出，“对象中的名称应该是唯一的”，而本规范指出
The Header Parameter names within the JOSE Header MUST be unique; JWS parsers MUST either reject JWSs with duplicate Header Parameter names or use a JSON parser that returns only the lexically last duplicate member name, as specified in Section 15.12 ("The JSON Object") of ECMAScript 5.1 [ECMAScript].
JOSE头中的头参数名称必须是唯一的；JWS解析器必须拒绝具有重复头参数名称的JWSs，或者使用只返回词汇上最后一个重复成员名称的JSON解析器，如ECMAScript 5.1[ECMAScript]第15.12节（“JSON对象”）所述。
Thus, this specification requires that the "SHOULD" in Section 4 of [RFC7159] be treated as a "MUST" by producers and that it be either treated as a "MUST" or treated in the manner specified in ECMAScript 5.1 by consumers. Ambiguous and potentially exploitable situations could arise if the JSON parser used does not enforce the uniqueness of member names or returns an unpredictable value for duplicate member names.
因此，本规范要求生产者将[RFC7159]第4节中的“应该”视为“必须”，消费者将其视为“必须”或按ECMAScript 5.1中规定的方式处理。如果使用的JSON解析器不强制成员名称的唯一性或为重复的成员名称返回不可预测的值，则可能会出现不明确和可能被利用的情况。
Some JSON parsers might not reject input that contains extra significant characters after a valid input. For instance, the input "{"tag":"value"}ABCD" contains a valid JSON-text object followed by the extra characters "ABCD". Implementations MUST consider JWSs containing such input to be invalid.
一些JSON解析器可能不会拒绝在有效输入后包含额外有效字符的输入。例如，输入“{”标记“：“value”}ABCD”包含一个有效的JSON文本对象，后跟额外的字符“ABCD”。实现必须考虑包含这样的输入的JWSS无效。
Header Parameter names and algorithm names are Unicode strings. For security reasons, the representations of these names must be compared verbatim after performing any escape processing (as per Section 8.3 of RFC 7159 [RFC7159]). This means, for instance, that these JSON strings must compare as being equal ("sig", "\u0073ig"), whereas these must all compare as being not equal to the first set or to each other ("SIG", "Sig", "si\u0047").
标题参数名称和算法名称是Unicode字符串。出于安全原因，在执行任何转义处理后（根据RFC 7159[RFC7159]第8.3节），必须逐字比较这些名称的表示。这意味着，例如，这些JSON字符串必须进行相等的比较（“sig”、“sig”、“si\u0073ig”），而这些字符串必须进行不相等的比较（“sig”、“sig”、“si\u0047”）。
JSON strings can contain characters outside the Unicode Basic Multilingual Plane. For instance, the G clef character (U+1D11E) may be represented in a JSON string as "\uD834\uDD1E". Ideally, JWS implementations SHOULD ensure that characters outside the Basic Multilingual Plane are preserved and compared correctly; alternatively, if this is not possible due to these characters exercising limitations present in the underlying JSON implementation, then input containing them MUST be rejected.
JSON字符串可以包含Unicode基本多语言平面之外的字符。例如，G谱号字符（U+1D11E）可以在JSON字符串中表示为“\uD834\uDD1E”。理想情况下，JWS实现应该确保基本多语言平面之外的字符被正确地保留和比较；或者，如果由于这些字符在底层JSON实现中存在限制而无法执行此操作，则必须拒绝包含这些字符的输入。
[ECMAScript] Ecma International, "ECMAScript Language Specification, 5.1 Edition", ECMA 262, June 2011, <http://www.ecma-international.org/ecma-262/5.1/ ECMA-262.pdf>.
[ECMAScript]Ecma国际，“ECMAScript语言规范，5.1版”，Ecma 262，2011年6月<http://www.ecma-international.org/ecma-262/5.1/ ECMA-262.pdf>。
[IANA.MediaTypes] IANA, "Media Types", <http://www.iana.org/assignments/media-types>.
[IANA.MediaTypes]IANA，“媒体类型”<http://www.iana.org/assignments/media-types>.
[ITU.X690.2008] International Telecommunications Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, 2008.
[ITU.X690.2008]国际电信联盟，“信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，ITU-T建议X.690，2008年。
[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>.
[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>.
[RFC20] Cerf, V., "ASCII format for Network Interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <http://www.rfc-editor.org/info/rfc20>.
[RFC20]Cerf，V.，“网络交换的ASCII格式”，STD 80，RFC 20，DOI 10.17487/RFC0020，1969年10月<http://www.rfc-editor.org/info/rfc20>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <http://www.rfc-editor.org/info/rfc2045>.
[RFC2045]Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 2045，DOI 10.17487/RFC20451996年11月<http://www.rfc-editor.org/info/rfc2045>.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <http://www.rfc-editor.org/info/rfc2046>.
[RFC2046]Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 2046，DOI 10.17487/RFC2046，1996年11月<http://www.rfc-editor.org/info/rfc2046>.
[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>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC 2818，DOI 10.17487/RFC2818，2000年5月<http://www.rfc-editor.org/info/rfc2818>.
[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>.
[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>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC 4648，DOI 10.17487/RFC4648，2006年10月<http://www.rfc-editor.org/info/rfc4648>.
[RFC4945] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, DOI 10.17487/RFC4945, August 2007, <http://www.rfc-editor.org/info/rfc4945>.
[RFC4945]Korver，B.，“IKEv1/ISAKMP、IKEv2和PKIX的互联网IP安全PKI配置文件”，RFC 4945，DOI 10.17487/RFC4945，2007年8月<http://www.rfc-editor.org/info/rfc4945>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.
[RFC4949]Shirey，R.，“互联网安全词汇表，第2版”，FYI 36，RFC 4949，DOI 10.17487/RFC4949，2007年8月<http://www.rfc-editor.org/info/rfc4949>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<http://www.rfc-editor.org/info/rfc5280>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施内表示和验证基于域的应用程序服务身份”，RFC 6125，DOI 10.17487/RFC6125，2011年3月<http://www.rfc-editor.org/info/rfc6125>.
[RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March 2011, <http://www.rfc-editor.org/info/rfc6176>.
[RFC6176]Turner，S.和T.Polk，“禁止安全套接字层（SSL）2.0版”，RFC 6176，DOI 10.17487/RFC6176，2011年3月<http://www.rfc-editor.org/info/rfc6176>.
[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/>.
[CanvasApp] Facebook, "Canvas Applications", <http://developers.facebook.com/docs/authentication/ canvas>.
[CanvasApp]Facebook，“画布应用程序”<http://developers.facebook.com/docs/authentication/ 画布>。
[JSS] Bradley, J. and N. Sakimura, Ed., "JSON Simple Sign", September 2010, <http://jsonenc.info/jss/1.0/>.
[JSS]Bradley，J.和N.Sakimura编辑，“JSON简单符号”，2010年9月<http://jsonenc.info/jss/1.0/>.
[JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, <http://www.rfc-editor.org/info/rfc7516>.
[JWE]Jones，M.和J.Hildebrand，“JSON Web加密（JWE）”，RFC 7516，DOI 10.17487/RFC7516，2015年5月<http://www.rfc-editor.org/info/rfc7516>.
[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>.
[MagicSignatures] Panzer, J., Ed., Laurie, B., and D. Balfanz, "Magic Signatures", January 2011, <http://salmon-protocol.googlecode.com/svn/trunk/ draft-panzer-magicsig-01.html>.
[MagicSignatures]Panzer，J.，Ed.，Laurie，B.，和D.Balfanz，“魔法签名”，2011年1月<http://salmon-protocol.googlecode.com/svn/trunk/ draft-panzer-magicsig-01.html>。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <http://www.rfc-editor.org/info/rfc2104>.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，DOI 10.17487/RFC2104，1997年2月<http://www.rfc-editor.org/info/rfc2104>.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 2003, <http://www.rfc-editor.org/info/rfc3447>.
[RFC3447]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，DOI 10.17487/RFC3447，2003年2月<http://www.rfc-editor.org/info/rfc3447>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <http://www.rfc-editor.org/info/rfc4086>.
[RFC4086]Eastlake 3rd，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，DOI 10.17487/RFC4086，2005年6月<http://www.rfc-editor.org/info/rfc4086>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <http://www.rfc-editor.org/info/rfc4122>.
[RFC4122]Leach，P.，Mealling，M.和R.Salz，“通用唯一标识符（UUID）URN名称空间”，RFC 4122，DOI 10.17487/RFC4122，2005年7月<http://www.rfc-editor.org/info/rfc4122>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC6211] Schaad, J., "Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute", RFC 6211, DOI 10.17487/RFC6211, April 2011, <http://www.rfc-editor.org/info/rfc6211>.
[RFC6211]Schaad，J.“加密消息语法（CMS）算法标识符保护属性”，RFC 6211，DOI 10.17487/RFC6211，2011年4月<http://www.rfc-editor.org/info/rfc6211>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <http://www.rfc-editor.org/info/rfc6838>.
[RFC6838]Freed，N.，Klensin，J.和T.Hansen，“介质类型规范和注册程序”，BCP 13，RFC 6838，DOI 10.17487/RFC6838，2013年1月<http://www.rfc-editor.org/info/rfc6838>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<http://www.rfc-editor.org/info/rfc7525>.
[SHS] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, March 2012, <http://csrc.nist.gov/publications/fips/fips180-4/ fips-180-4.pdf>.
[SHS]国家标准与技术研究所，“安全哈希标准（SHS）”，FIPS PUB 180-42012年3月<http://csrc.nist.gov/publications/fips/fips180-4/ fips-180-4.pdf>。
[W3C.NOTE-xmldsig-bestpractices-20130411] Hirsch, F. and P. Datta, "XML Signature Best Practices", World Wide Web Consortium Note NOTE-xmldsig-bestpractices-20130411, April 2013, <http://www.w3.org/TR/2013/ NOTE-xmldsig-bestpractices-20130411/>.
[W3C.NOTE-xmldsig-bestpractices-20130411]Hirsch，F.和P.Datta，“XML签名最佳实践”，万维网联盟NOTE-xmldsig-bestpractices-201304111913年4月<http://www.w3.org/TR/2013/ 注-xmldsig-bestpractices-20130411/>。
[W3C.NOTE-xmldsig-core2-20130411] Eastlake, D., Reagle, J., Solo, D., Hirsch, F., Roessler, T., Yiu, K., Datta, P., and S. Cantor, "XML Signature Syntax and Processing Version 2.0", World Wide Web Consortium Note NOTE-xmldsig-core2-20130411, April 2013, <http://www.w3.org/TR/2013/NOTE-xmldsig-core2-20130411/>.
[W3C.NOTE-xmldsig-core2-20130411]伊斯特莱克，D.，雷格尔，J.，索洛，D.，赫希，F.，罗斯勒，T.，姚，K.，达塔，P.，和S.坎托，“XML签名语法和处理版本2.0”，万维网联盟NOTE-xmldsig-core2-20130411，2013年4月<http://www.w3.org/TR/2013/NOTE-xmldsig-core2-20130411/>.
This section provides several examples of JWSs. While the first three examples all represent JSON Web Tokens (JWTs) [JWT], the payload can be any octet sequence, as shown in Appendix A.4.
本节提供了几个JWSs示例。虽然前三个示例都表示JSON Web令牌（JWT）[JWT]，但有效负载可以是任何八位字节序列，如附录A.4所示。
The following example JWS Protected Header declares that the data structure is a JWT [JWT] and the JWS Signing Input is secured using the HMAC SHA-256 algorithm.
以下示例JWS-Protected标头声明数据结构是JWT[JWT]，JWS签名输入使用HMAC SHA-256算法进行保护。
{"typ":"JWT",
"alg":"HS256"}
{"typ":"JWT",
"alg":"HS256"}
To remove potential ambiguities in the representation of the JSON object above, the actual octet sequence representing UTF8(JWS Protected Header) used in this example is also included below. (Note that ambiguities can arise due to differing platform representations of line breaks (CRLF versus LF), differing spacing at the beginning and ends of lines, whether the last line has a terminating line break or not, and other causes. In the representation used in this example, the first line has no leading or trailing spaces, a CRLF line break (13, 10) occurs between the first and second lines, the second line has one leading space (32) and no trailing spaces, and the last line does not have a terminating line break.) The octets representing UTF8(JWS Protected Header) in this example (using JSON array notation) are:
为了消除上述JSON对象表示中的潜在歧义，下面还包括了表示本示例中使用的UTF8（JWS保护头）的实际八位字节序列。（请注意，由于换行符的平台表示不同（CRLF与LF），可能会产生歧义。），行首和行尾的间距不同，最后一行是否有终止换行符，以及其他原因。在本示例中使用的表示法中，第一行没有前导或尾随空格，第一行和第二行之间出现CRLF换行符（13，10），第二行有一个前导空格（32）并且没有尾随空格，最后一行没有终止换行符。）本例中代表UTF8（JWS保护头）的八位字节（使用JSON数组表示法）为：
[123, 34, 116, 121, 112, 34, 58, 34, 74, 87, 84, 34, 44, 13, 10, 32, 34, 97, 108, 103, 34, 58, 34, 72, 83, 50, 53, 54, 34, 125]
[123, 34, 116, 121, 112, 34, 58, 34, 74, 87, 84, 34, 44, 13, 10, 32, 34, 97, 108, 103, 34, 58, 34, 72, 83, 50, 53, 54, 34, 125]
Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value:
将此受JWS保护的标头编码为BASE64URL（UTF8（受JWS保护的标头））将给出以下值：
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
The JWS Payload used in this example is the octets of the UTF-8 representation of the JSON object below. (Note that the payload can be any base64url-encoded octet sequence and need not be a base64url-encoded JSON object.)
本例中使用的JWS负载是下面JSON对象的UTF-8表示形式的八位字节。（注意，有效负载可以是任何base64url编码的八位字节序列，而不需要是base64url编码的JSON对象。）
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
The following octet sequence, which is the UTF-8 representation used in this example for the JSON object above, is the JWS Payload:
以下八位字节序列是JWS有效负载，它是本例中用于上述JSON对象的UTF-8表示：
[123, 34, 105, 115, 115, 34, 58, 34, 106, 111, 101, 34, 44, 13, 10, 32, 34, 101, 120, 112, 34, 58, 49, 51, 48, 48, 56, 49, 57, 51, 56, 48, 44, 13, 10, 32, 34, 104, 116, 116, 112, 58, 47, 47, 101, 120, 97, 109, 112, 108, 101, 46, 99, 111, 109, 47, 105, 115, 95, 114, 111, 111, 116, 34, 58, 116, 114, 117, 101, 125]
[123, 34, 105, 115, 115, 34, 58, 34, 106, 111, 101, 34, 44, 13, 10, 32, 34, 101, 120, 112, 34, 58, 49, 51, 48, 48, 56, 49, 57, 51, 56, 48, 44, 13, 10, 32, 34, 104, 116, 116, 112, 58, 47, 47, 101, 120, 97, 109, 112, 108, 101, 46, 99, 111, 109, 47, 105, 115, 95, 114, 111, 111, 116, 34, 58, 116, 114, 117, 101, 125]
Encoding this JWS Payload as BASE64URL(UTF8(JWS Payload)) gives this value (with line breaks for display purposes only):
将此JWS有效负载编码为BASE64URL（UTF8（JWS有效负载））将给出此值（换行符仅用于显示目的）：
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
EYJPC3MIOIJQB2UILA0KIJLEHAIOJEZMDA4MTKZODAQIMH0DHA6LY9LEGFT cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
Combining these as BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) gives this string (with line breaks for display purposes only):
将它们组合为BASE64URL（UTF8（JWS保护的标头））| |'。| | BASE64URL（JWS有效负载）生成此字符串（带换行符，仅用于显示）：
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9。EYJPC3MIOIJQB2UILA0KIJLEHAIOJEZMDA4MTKZODAQIMH0DHA6LY9LEGFT cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
The resulting JWS Signing Input value, which is the ASCII representation of above string, is the following octet sequence (using JSON array notation):
生成的JWS签名输入值是上述字符串的ASCII表示形式，是以下八位字节序列（使用JSON数组表示法）：
[101, 121, 74, 48, 101, 88, 65, 105, 79, 105, 74, 75, 86, 49, 81, 105, 76, 65, 48, 75, 73, 67, 74, 104, 98, 71, 99, 105, 79, 105, 74, 73, 85, 122, 73, 49, 78, 105, 74, 57, 46, 101, 121, 74, 112, 99, 51, 77, 105, 79, 105, 74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67, 74, 108, 101, 72, 65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84, 107, 122, 79, 68, 65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100, 72, 65, 54, 76, 121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76, 109, 78, 118, 98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48, 99, 110, 86, 108, 102, 81]
[101, 121, 74, 48, 101, 88, 65, 105, 79, 105, 74, 75, 86, 49, 81, 105, 76, 65, 48, 75, 73, 67, 74, 104, 98, 71, 99, 105, 79, 105, 74, 73, 85, 122, 73, 49, 78, 105, 74, 57, 46, 101, 121, 74, 112, 99, 51, 77, 105, 79, 105, 74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67, 74, 108, 101, 72, 65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84, 107, 122, 79, 68, 65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100, 72, 65, 54, 76, 121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76, 109, 78, 118, 98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48, 99, 110, 86, 108, 102, 81]
HMACs are generated using keys. This example uses the symmetric key represented in JSON Web Key [JWK] format below (with line breaks within values for display purposes only):
HMAC是使用密钥生成的。此示例使用以下JSON Web key[JWK]格式表示的对称密钥（值中的换行符仅用于显示）：
{"kty":"oct", "k":"AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75 aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow" }
{“kty”：“oct”，“k”：“AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr\U T-1qS0gZH75 AKTMN3YJ0IPS4CGUUTWJAZR1Z9CAOW”}
Running the HMAC SHA-256 algorithm on the JWS Signing Input with this key yields this JWS Signature octet sequence:
使用此密钥在JWS签名输入上运行HMAC SHA-256算法将生成此JWS签名八位字节序列：
[116, 24, 223, 180, 151, 153, 224, 37, 79, 250, 96, 125, 216, 173, 187, 186, 22, 212, 37, 77, 105, 214, 191, 240, 91, 88, 5, 88, 83, 132, 141, 121]
[116, 24, 223, 180, 151, 153, 224, 37, 79, 250, 96, 125, 216, 173, 187, 186, 22, 212, 37, 77, 105, 214, 191, 240, 91, 88, 5, 88, 83, 132, 141, 121]
Encoding this JWS Signature as BASE64URL(JWS Signature) gives this value:
将此JWS签名编码为BASE64URL（JWS签名）将给出以下值：
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
Concatenating these values in the order Header.Payload.Signature with period ('.') characters between the parts yields this complete JWS representation using the JWS Compact Serialization (with line breaks for display purposes only):
将order Header.Payload.Signature中的这些值与部分之间的句点（'.'）字符连接起来，可以使用JWS紧凑序列化（换行符仅用于显示目的）生成完整的JWS表示：
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ . dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9。EYJPC3MIOIJQB2UILA0KIJLEHAIOJEZMDA4MTKZODAZODAQIMH0DHA6LY9LEGFT cGxlLmNvbS9pc19yb290Ijp0cnVlfQ。dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
Since the "alg" Header Parameter is "HS256", we validate the HMAC SHA-256 value contained in the JWS Signature.
因为“alg”头参数是“HS256”，所以我们验证JWS签名中包含的HMAC SHA-256值。
To validate the HMAC value, we repeat the previous process of using the correct key and the JWS Signing Input (which is the initial substring of the JWS Compact Serialization representation up until but not including the second period character) as input to the HMAC SHA-256 function and then taking the output and determining if it matches the JWS Signature (which is base64url decoded from the value encoded in the JWS representation). If it matches exactly, the HMAC has been validated.
为了验证HMAC值，我们重复前面的过程，使用正确的密钥和JWS签名输入（这是JWS紧凑序列化表示的初始子字符串，直到但不包括第二个句点字符）作为HMAC SHA-256函数的输入，然后获取输出并确定其是否匹配JWS签名（该签名是从JWS表示中编码的值解码而来的base64url）。如果完全匹配，则已验证HMAC。
The JWS Protected Header in this example is different from the previous example in two ways. First, because a different algorithm is being used, the "alg" value is different. Second, for illustration purposes only, the optional "typ" (type) Header Parameter is not used. (This difference is not related to the algorithm employed.) The JWS Protected Header used is:
本例中受JWS保护的头在两个方面与前一个示例不同。首先，由于使用了不同的算法，“alg”值不同。其次，仅出于说明目的，不使用可选的“typ”（type）头参数。（此差异与所采用的算法无关。）使用的JWS保护标头为：
{"alg":"RS256"}
{"alg":"RS256"}
The octets representing UTF8(JWS Protected Header) in this example (using JSON array notation) are:
本例中代表UTF8（JWS保护头）的八位字节（使用JSON数组表示法）为：
[123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 50, 53, 54, 34, 125]
[123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 50, 53, 54, 34, 125]
Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value:
将此受JWS保护的标头编码为BASE64URL（UTF8（受JWS保护的标头））将给出以下值：
eyJhbGciOiJSUzI1NiJ9
EYJHBGCOIJSUZI1NIJ9
The JWS Payload used in this example, which follows, is the same as in the previous example. Since the BASE64URL(JWS Payload) value will therefore be the same, its computation is not repeated here.
下面的示例中使用的JWS有效负载与前面的示例中相同。由于BASE64URL（JWS有效负载）值因此是相同的，因此这里不重复其计算。
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
Combining these as BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) gives this string (with line breaks for display purposes only):
将它们组合为BASE64URL（UTF8（JWS保护的标头））| |'。| | BASE64URL（JWS有效负载）生成此字符串（带换行符，仅用于显示）：
eyJhbGciOiJSUzI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
eyJhbGciOiJSUzI1NiJ9。EYJPC3MIOIJQB2UILA0KIJLEHAIOJEZMDA4MTKZODAQIMH0DHA6LY9LEGFT cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
The resulting JWS Signing Input value, which is the ASCII representation of above string, is the following octet sequence:
生成的JWS签名输入值是上述字符串的ASCII表示形式，是以下八位字节序列：
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 122, 73, 49, 78, 105, 74, 57, 46, 101, 121, 74, 112, 99, 51, 77, 105, 79, 105, 74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67, 74, 108, 101, 72, 65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84, 107, 122, 79, 68, 65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100, 72, 65, 54, 76, 121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76, 109, 78, 118, 98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48, 99, 110, 86, 108, 102, 81]
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 122, 73, 49, 78, 105, 74, 57, 46, 101, 121, 74, 112, 99, 51, 77, 105, 79, 105, 74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67, 74, 108, 101, 72, 65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84, 107, 122, 79, 68, 65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100, 72, 65, 54, 76, 121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76, 109, 78, 118, 98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48, 99, 110, 86, 108, 102, 81]
This example uses the RSA key represented in JSON Web Key [JWK] format below (with line breaks within values for display purposes only):
此示例使用以下JSON Web key[JWK]格式表示的RSA密钥（值中的换行符仅用于显示）：
{"kty":"RSA", "n":"ofgWCuLjybRlzo0tZWJjNiuSfb4p4fAkd_wWJcyQoTbji9k0l8W26mPddx HmfHQp-Vaw-4qPCJrcS2mJPMEzP1Pt0Bm4d4QlL-yRT-SFd2lZS-pCgNMs D1W_YpRPEwOWvG6b32690r2jZ47soMZo9wGzjb_7OMg0LOL-bSf63kpaSH SXndS5z5rexMdbBYUsLA9e-KXBdQOS-UTo7WTBEMa2R2CapHg665xsmtdV MTBQY4uDZlxvb3qCo5ZwKh9kG4LT6_I5IhlJH7aGhyxXFvUK-DWNmoudF8 NAco9_h9iaGNj8q2ethFkMLs91kzk2PAcDTW9gb54h4FRWyuXpoQ", "e":"AQAB", "d":"Eq5xpGnNCivDflJsRQBXHx1hdR1k6Ulwe2JZD50LpXyWPEAeP88vLNO97I jlA7_GQ5sLKMgvfTeXZx9SE-7YwVol2NXOoAJe46sui395IW_GO-pWJ1O0 BkTGoVEn2bKVRUCgu-GjBVaYLU6f3l9kJfFNS3E0QbVdxzubSu3Mkqzjkn 439X0M_V51gfpRLI9JYanrC4D4qAdGcopV_0ZHHzQlBjudU2QvXt4ehNYT CBr6XCLQUShb1juUO1ZdiYoFaFQT5Tw8bGUl_x_jTj3ccPDVZFD9pIuhLh BOneufuBiB4cS98l2SR_RQyGWSeWjnczT0QU91p1DhOVRuOopznQ", "p":"4BzEEOtIpmVdVEZNCqS7baC4crd0pqnRH_5IB3jw3bcxGn6QLvnEtfdUdi YrqBdss1l58BQ3KhooKeQTa9AB0Hw_Py5PJdTJNPY8cQn7ouZ2KKDcmnPG BY5t7yLc1QlQ5xHdwW1VhvKn-nXqhJTBgIPgtldC-KDV5z-y2XDwGUc", "q":"uQPEfgmVtjL0Uyyx88GZFF1fOunH3-7cepKmtH4pxhtCoHqpWmT8YAmZxa ewHgHAjLYsp1ZSe7zFYHj7C6ul7TjeLQeZD_YwD66t62wDmpe_HlB-TnBA -njbglfIsRLtXlnDzQkv5dTltRJ11BKBBypeeF6689rjcJIDEz9RWdc", "dp":"BwKfV3Akq5_MFZDFZCnW-wzl-CCo83WoZvnLQwCTeDv8uzluRSnm71I3Q CLdhrqE2e9YkxvuxdBfpT_PI7Yz-FOKnu1R6HsJeDCjn12Sk3vmAktV2zb 34MCdy7cpdTh_YVr7tss2u6vneTwrA86rZtu5Mbr1C1XsmvkxHQAdYo0", "dq":"h_96-mK1R_7glhsum81dZxjTnYynPbZpHziZjeeHcXYsXaaMwkOlODsWa 7I9xXDoRwbKgB719rrmI2oKr6N3Do9U0ajaHF-NKJnwgjMd2w9cjz3_-ky NlxAr2v4IKhGNpmM5iIgOS1VZnOZ68m6_pbLBSp3nssTdlqvd0tIiTHU", "qi":"IYd7DHOhrWvxkwPQsRM2tOgrjbcrfvtQJipd-DlcxyVuuM9sQLdgjVk2o y26F0EmpScGLq2MowX7fhd_QJQ3ydy5cY7YIBi87w93IKLEdfnbJtoOPLU W0ITrJReOgo1cq9SbsxYawBgfp_gh6A5603k2-ZQwVK0JKSHuLFkuQ3U" }
{“kty”：“RSA”，“n”：4.在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，NJ8Q2ethFKMLS91KZK2PacDTW9GB54H4FRWYUxPOQ，“e”：“AQAB”，“d”：6月6日，中国政府在一份研究报告中给出了一份关于一份研究报告的一份研究报告，一份研究报告中给出了一份关于一份研究文件，一份研究文件，一份研究文件，一份研究文件，一份研究文件，一份研究文件，一份研究文件，一份研究文件，一份研究文件，一份研究文件，一份研究文件，一份研究文件，一份研究文件，一份研究一份研究，一份研究一份研究，一份研究一份研究，一份非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非非_rqygwsewjncznt0qu91p1dhovruoopznq“，“p”：“4BzEEOtIpmVdVEZNCqS7baC4crd0pqnRH_5IB3jw3bcxGn6QLvnEtfdUdi YRQBDSS18BQ3KHOOKEQTA9AB0HW_Py5Py5PjDjPy8CQN7OUZ2KKDCMNPG由5T7YLC1QLQ5XHDWW1VHVKN-nXqhJTBgIPgtldC-KDV5z-y2XDwGUc提供”，“q”：”“UQPEFGMGMvtjl0UYX88GZFF1FOUNH3-7CEPKMTH4PXHTCHQPWMT8YAMZXA EWGHAJLYSP1ZSE7ZFYHJ7C6UL7TJELQEZD_YWD666; WDMPE_HlB-TnBA-NJBGLFLTLTxlndZQKV5DTRJ11BKB类型EF6689CJIDEZ9RWDC”，“dp”：”BWKF3AKQ5_MFZDFZCnW-wzl-CCo83WoZvnLQwCTeDv8uzluRSnm71I3Q CLdhrqE2e9YkxvuxdBfpT_PI7Yz-FOKnu1R6HsJeDCjn12Sk3vmAktV2zb 34MCD7CPDTH_YVR7TS2U6VNetra86RZTU5MBR1C1XSMvKXHQADY0，“dq”：”h_96-mK1R_7glhsum81dzxjtnypbzphzizjeehcxysxaamwkolodswa 7I9xXDoRwbKgB719rrmI2oKr6N3Do9U0ajaHF-NKJnwgjMd2w9cjz3-ky NlxAr2v4IKhGNpmM5iIgOS1VZnOZ68m6_pblbsp3nstdlqvd0tiithu，“qi”：IYD7DHOHRVxKWPQSRM2TOGRJBCRFvTQJIPD-DLCXYVUUUM9SQLDGJVK2O y26F0EmpScGLq2MowX7fhd\u QJQYDYDYD5CY7YBI87W93IKLEDFNbjTooplu W0ITrJReOgo1cq9SbsxYawBgfp\u gh6A5603k2-ZQWVK0JKShulfKUQU
The RSA private key is then passed to the RSA signing function, which also takes the hash type, SHA-256, and the JWS Signing Input as inputs. The result of the digital signature is an octet sequence, which represents a big-endian integer. In this example, it is:
然后将RSA私钥传递给RSA签名函数，该函数还将哈希类型SHA-256和JWS签名输入作为输入。数字签名的结果是一个八进制序列，它表示一个大端整数。在本例中，它是：
[112, 46, 33, 137, 67, 232, 143, 209, 30, 181, 216, 45, 191, 120, 69, 243, 65, 6, 174, 27, 129, 255, 247, 115, 17, 22, 173, 209, 113, 125, 131, 101, 109, 66, 10, 253, 60, 150, 238, 221, 115, 162, 102, 62, 81, 102, 104, 123, 0, 11, 135, 34, 110, 1, 135, 237, 16, 115, 249, 69, 229, 130, 173, 252, 239, 22, 216, 90, 121, 142, 232, 198, 109, 219, 61, 184, 151, 91, 23, 208, 148, 2, 190, 237, 213, 217, 217, 112, 7, 16, 141, 178, 129, 96, 213, 248, 4, 12, 167, 68, 87, 98, 184, 31, 190, 127, 249, 217, 46, 10, 231, 111, 36, 242, 91, 51, 187, 230, 244, 74, 230, 30, 177, 4, 10, 203, 32, 4, 77, 62, 249, 18, 142, 212, 1, 48, 121, 91, 212, 189, 59, 65, 238, 202, 208, 102, 171, 101, 25, 129, 253, 228, 141, 247, 127, 55, 45, 195, 139, 159, 175, 221, 59, 239, 177, 139, 93, 163, 204, 60, 46, 176, 47, 158, 58, 65, 214, 18, 202, 173, 21, 145, 18, 115, 160, 95, 35, 185, 232, 56, 250, 175, 132, 157, 105, 132, 41, 239, 90, 30, 136, 121, 130, 54, 195, 212, 14, 96, 69, 34, 165, 68, 200, 242, 122, 122, 45, 184, 6, 99, 209, 108, 247, 202, 234, 86, 222, 64, 92, 178, 33, 90, 69, 178, 194, 85, 102, 181, 90, 193, 167, 72, 160, 112, 223, 200, 163, 42, 70, 149, 67, 208, 25, 238, 251, 71]
[112, 46, 33, 137, 67, 232, 143, 209, 30, 181, 216, 45, 191, 120, 69, 243, 65, 6, 174, 27, 129, 255, 247, 115, 17, 22, 173, 209, 113, 125, 131, 101, 109, 66, 10, 253, 60, 150, 238, 221, 115, 162, 102, 62, 81, 102, 104, 123, 0, 11, 135, 34, 110, 1, 135, 237, 16, 115, 249, 69, 229, 130, 173, 252, 239, 22, 216, 90, 121, 142, 232, 198, 109, 219, 61, 184, 151, 91, 23, 208, 148, 2, 190, 237, 213, 217, 217, 112, 7, 16, 141, 178, 129, 96, 213, 248, 4, 12, 167, 68, 87, 98, 184, 31, 190, 127, 249, 217, 46, 10, 231, 111, 36, 242, 91, 51, 187, 230, 244, 74, 230, 30, 177, 4, 10, 203, 32, 4, 77, 62, 249, 18, 142, 212, 1, 48, 121, 91, 212, 189, 59, 65, 238, 202, 208, 102, 171, 101, 25, 129, 253, 228, 141, 247, 127, 55, 45, 195, 139, 159, 175, 221, 59, 239, 177, 139, 93, 163, 204, 60, 46, 176, 47, 158, 58, 65, 214, 18, 202, 173, 21, 145, 18, 115, 160, 95, 35, 185, 232, 56, 250, 175, 132, 157, 105, 132, 41, 239, 90, 30, 136, 121, 130, 54, 195, 212, 14, 96, 69, 34, 165, 68, 200, 242, 122, 122, 45, 184, 6, 99, 209, 108, 247, 202, 234, 86, 222, 64, 92, 178, 33, 90, 69, 178, 194, 85, 102, 181, 90, 193, 167, 72, 160, 112, 223, 200, 163, 42, 70, 149, 67, 208, 25, 238, 251, 71]
Encoding the signature as BASE64URL(JWS Signature) produces this value (with line breaks for display purposes only):
将签名编码为BASE64URL（JWS签名）将生成此值（换行符仅用于显示）：
cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZmh7
AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjbKBYNX4
BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHlb1L07Qe7K
0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZESc6BfI7noOPqv
hJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AXLIhWkWywlVmtVrB
p0igcN_IoypGlUPQGe77Rw
cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZmh7
AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjbKBYNX4
BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHlb1L07Qe7K
0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZESc6BfI7noOPqv
hJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AXLIhWkWywlVmtVrB
p0igcN_IoypGlUPQGe77Rw
Concatenating these values in the order Header.Payload.Signature with period ('.') characters between the parts yields this complete JWS representation using the JWS Compact Serialization (with line breaks for display purposes only):
将order Header.Payload.Signature中的这些值与部分之间的句点（'.'）字符连接起来，可以使用JWS紧凑序列化（换行符仅用于显示目的）生成完整的JWS表示：
eyJhbGciOiJSUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZmh7
AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjbKBYNX4
BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHlb1L07Qe7K
0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZESc6BfI7noOPqv
hJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AXLIhWkWywlVmtVrB
p0igcN_IoypGlUPQGe77Rw
eyJhbGciOiJSUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZmh7
AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjbKBYNX4
BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHlb1L07Qe7K
0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZESc6BfI7noOPqv
hJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AXLIhWkWywlVmtVrB
p0igcN_IoypGlUPQGe77Rw
Since the "alg" Header Parameter is "RS256", we validate the RSASSA-PKCS1-v1_5 SHA-256 digital signature contained in the JWS Signature.
由于“alg”头参数是“RS256”，我们验证JWS签名中包含的RSASSA-PKCS1-v1_5 SHA-256数字签名。
Validating the JWS Signature is a bit different from the previous example. We pass the public key (n, e), the JWS Signature (which is base64url decoded from the value encoded in the JWS representation), and the JWS Signing Input (which is the initial substring of the JWS Compact Serialization representation up until but not including the second period character) to an RSASSA-PKCS1-v1_5 signature verifier that has been configured to use the SHA-256 hash function.
验证JWS签名与前面的示例略有不同。我们传递公钥（n，e）、JWS签名（它是从JWS表示中编码的值解码而来的base64url）和JWS签名输入（它是JWS紧凑序列化表示的初始子字符串，直到但不包括第二个句点字符）发送到已配置为使用SHA-256哈希函数的RSASSA-PKCS1-v1_5签名验证器。
The JWS Protected Header for this example differs from the previous example because a different algorithm is being used. The JWS Protected Header used is:
此示例的JWS受保护标头与前一示例不同，因为使用了不同的算法。使用的JWS受保护标头为：
{"alg":"ES256"}
{"alg":"ES256"}
The octets representing UTF8(JWS Protected Header) in this example (using JSON array notation) are:
本例中代表UTF8（JWS保护头）的八位字节（使用JSON数组表示法）为：
[123, 34, 97, 108, 103, 34, 58, 34, 69, 83, 50, 53, 54, 34, 125]
[123, 34, 97, 108, 103, 34, 58, 34, 69, 83, 50, 53, 54, 34, 125]
Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value:
将此受JWS保护的标头编码为BASE64URL（UTF8（受JWS保护的标头））将给出以下值：
eyJhbGciOiJFUzI1NiJ9
EYJHBGCOIJFUZI1NIJ9
The JWS Payload used in this example, which follows, is the same as in the previous examples. Since the BASE64URL(JWS Payload) value will therefore be the same, its computation is not repeated here.
下面的示例中使用的JWS有效负载与前面的示例中相同。由于BASE64URL（JWS有效负载）值因此是相同的，因此这里不重复其计算。
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
Combining these as BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) gives this string (with line breaks for display purposes only):
将它们组合为BASE64URL（UTF8（JWS保护的标头））| |'。| | BASE64URL（JWS有效负载）生成此字符串（带换行符，仅用于显示）：
eyJhbGciOiJFUzI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
EYJHBGCOIJFUZI1NIJ9。EYJPC3MIOIJQB2UILA0KIJLEHAIOJEZMDA4MTKZODAQIMH0DHA6LY9LEGFT cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
The resulting JWS Signing Input value, which is the ASCII representation of above string, is the following octet sequence:
生成的JWS签名输入值是上述字符串的ASCII表示形式，是以下八位字节序列：
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 70, 85, 122, 73, 49, 78, 105, 74, 57, 46, 101, 121, 74, 112, 99, 51, 77, 105, 79, 105, 74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67, 74, 108, 101, 72, 65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84, 107, 122, 79, 68, 65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100, 72, 65, 54, 76, 121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76, 109, 78, 118, 98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48, 99, 110, 86, 108, 102, 81]
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 70, 85, 122, 73, 49, 78, 105, 74, 57, 46, 101, 121, 74, 112, 99, 51, 77, 105, 79, 105, 74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67, 74, 108, 101, 72, 65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84, 107, 122, 79, 68, 65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100, 72, 65, 54, 76, 121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76, 109, 78, 118, 98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48, 99, 110, 86, 108, 102, 81]
This example uses the Elliptic Curve key represented in JSON Web Key [JWK] format below:
此示例使用以下JSON Web密钥[JWK]格式表示的椭圆曲线密钥：
{"kty":"EC", "crv":"P-256", "x":"f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU", "y":"x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0", "d":"jpsQnnGQmL-YBIffH1136cspYG6-0iY7X1fCE9-E9LI" }
{“kty”：“EC”，“crv”：“P-256”，“x”：“F83OJ3D2xF1BG8VUB9TLEGHMZV76E8TUS9UPHVRVEU”，“y”：“x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0”，“d”：“jpsQnnGQmL-YBIffH1136cspYG6-0iY7X1fCE9-E9LI”
The Elliptic Curve Digital Signature Algorithm (ECDSA) private part d is then passed to an ECDSA signing function, which also takes the curve type, P-256, the hash type, SHA-256, and the JWS Signing Input as inputs. The result of the digital signature is the Elliptic Curve
然后将椭圆曲线数字签名算法（ECDSA）私有部分d传递给ECDSA签名函数，该函数还将曲线类型P-256、哈希类型SHA-256和JWS签名输入作为输入。数字签名的结果是椭圆曲线
(EC) point (R, S), where R and S are unsigned integers. In this example, the R and S values, given as octet sequences representing big-endian integers are:
（EC）点（R，S），其中R和S是无符号整数。在本例中，作为表示大端整数的八位字节序列给出的R和S值为：
+--------+----------------------------------------------------------+
| Result | Value |
| Name | |
+--------+----------------------------------------------------------+
| R | [14, 209, 33, 83, 121, 99, 108, 72, 60, 47, 127, 21, 88, |
| | 7, 212, 2, 163, 178, 40, 3, 58, 249, 124, 126, 23, 129, |
| | 154, 195, 22, 158, 166, 101] |
| S | [197, 10, 7, 211, 140, 60, 112, 229, 216, 241, 45, 175, |
| | 8, 74, 84, 128, 166, 101, 144, 197, 242, 147, 80, 154, |
| | 143, 63, 127, 138, 131, 163, 84, 213] |
+--------+----------------------------------------------------------+
+--------+----------------------------------------------------------+
| Result | Value |
| Name | |
+--------+----------------------------------------------------------+
| R | [14, 209, 33, 83, 121, 99, 108, 72, 60, 47, 127, 21, 88, |
| | 7, 212, 2, 163, 178, 40, 3, 58, 249, 124, 126, 23, 129, |
| | 154, 195, 22, 158, 166, 101] |
| S | [197, 10, 7, 211, 140, 60, 112, 229, 216, 241, 45, 175, |
| | 8, 74, 84, 128, 166, 101, 144, 197, 242, 147, 80, 154, |
| | 143, 63, 127, 138, 131, 163, 84, 213] |
+--------+----------------------------------------------------------+
The JWS Signature is the value R || S. Encoding the signature as BASE64URL(JWS Signature) produces this value (with line breaks for display purposes only):
JWS签名是值R | | S。将签名编码为BASE64URL（JWS签名）将生成此值（换行符仅用于显示）：
DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSA pmWQxfKTUJqPP3-Kg6NU1Q
DTEHU3LJBEG8L38VWAFAQUAQOYKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSA pmWQxfKTUJqPP3-Kg6NU1Q
Concatenating these values in the order Header.Payload.Signature with period ('.') characters between the parts yields this complete JWS representation using the JWS Compact Serialization (with line breaks for display purposes only):
将order Header.Payload.Signature中的这些值与部分之间的句点（'.'）字符连接起来，可以使用JWS紧凑序列化（换行符仅用于显示目的）生成完整的JWS表示：
eyJhbGciOiJFUzI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ . DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSA pmWQxfKTUJqPP3-Kg6NU1Q
EYJHBGCOIJFUZI1NIJ9。EYJPC3MIOIJQB2UILA0KIJLEHAIOJEZMDA4MTKZODAZODAQIMH0DHA6LY9LEGFT cGxlLmNvbS9pc19yb290Ijp0cnVlfQ。DTEHU3LJBEG8L38VWAFAQUAQOYKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSA pmWQxfKTUJqPP3-Kg6NU1Q
Since the "alg" Header Parameter is "ES256", we validate the ECDSA P-256 SHA-256 digital signature contained in the JWS Signature.
由于“alg”头参数是“ES256”，我们验证JWS签名中包含的ECDSA P-256 SHA-256数字签名。
Validating the JWS Signature is a bit different from the previous examples. We need to split the 64 member octet sequence of the JWS Signature (which is base64url decoded from the value encoded in the JWS representation) into two 32 octet sequences, the first representing R and the second S. We then pass the public key (x, y), the signature (R, S), and the JWS Signing Input (which is the initial substring of the JWS Compact Serialization representation up until
验证JWS签名与前面的示例略有不同。我们需要将JWS签名的64个成员八位组序列（从JWS表示中编码的值中解码的base64url）拆分为两个32个八位组序列，第一个表示R，第二个表示S。然后我们传递公钥（x，y）、签名（R，S）和JWS签名输入（这是JWS紧凑序列化表示的初始子字符串，直到
but not including the second period character) to an ECDSA signature verifier that has been configured to use the P-256 curve with the SHA-256 hash function.
但不包括第二个句点字符）到已配置为使用P-256曲线和SHA-256哈希函数的ECDSA签名验证器。
The JWS Protected Header for this example differs from the previous example because different ECDSA curves and hash functions are used. The JWS Protected Header used is:
本例的JWS-Protected标头与上一个示例不同，因为使用了不同的ECDSA曲线和哈希函数。使用的JWS受保护标头为：
{"alg":"ES512"}
{"alg":"ES512"}
The octets representing UTF8(JWS Protected Header) in this example (using JSON array notation) are:
本例中代表UTF8（JWS保护头）的八位字节（使用JSON数组表示法）为：
[123, 34, 97, 108, 103, 34, 58, 34, 69, 83, 53, 49, 50, 34, 125]
[123, 34, 97, 108, 103, 34, 58, 34, 69, 83, 53, 49, 50, 34, 125]
Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value:
将此受JWS保护的标头编码为BASE64URL（UTF8（受JWS保护的标头））将给出以下值：
eyJhbGciOiJFUzUxMiJ9
eyJhbGciOiJFUzUxMiJ9
The JWS Payload used in this example is the ASCII string "Payload". The representation of this string is the following octet sequence:
本例中使用的JWS有效负载是ASCII字符串“Payload”。此字符串的表示形式为以下八位字节序列：
[80, 97, 121, 108, 111, 97, 100]
[80, 97, 121, 108, 111, 97, 100]
Encoding this JWS Payload as BASE64URL(JWS Payload) gives this value:
将此JWS有效负载编码为BASE64URL（JWS有效负载）将给出以下值：
UGF5bG9hZA
UGF5bG9hZA
Combining these as BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) gives this string:
将它们组合为BASE64URL（UTF8（JWS保护头））| |'。| | BASE64URL（JWS有效负载）给出以下字符串：
eyJhbGciOiJFUzUxMiJ9.UGF5bG9hZA
eyJhbGciOiJFUzUxMiJ9.UGF5bG9hZA
The resulting JWS Signing Input value, which is the ASCII representation of above string, is the following octet sequence:
生成的JWS签名输入值是上述字符串的ASCII表示形式，是以下八位字节序列：
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 70, 85, 122, 85, 120, 77, 105, 74, 57, 46, 85, 71, 70, 53, 98, 71, 57, 104, 90, 65]
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 70, 85, 122, 85, 120, 77, 105, 74, 57, 46, 85, 71, 70, 53, 98, 71, 57, 104, 90, 65]
This example uses the Elliptic Curve key represented in JSON Web Key [JWK] format below (with line breaks within values for display purposes only):
此示例使用以下JSON Web key[JWK]格式表示的椭圆曲线密钥（值中的换行符仅用于显示）：
{"kty":"EC", "crv":"P-521", "x":"AekpBQ8ST8a8VcfVOTNl353vSrDCLLJXmPk06wTjxrrjcBpXp5EOnYG_ NjFZ6OvLFV1jSfS9tsz4qUxcWceqwQGk", "y":"ADSmRA43Z1DSNx_RvcLI87cdL07l6jQyyBXMoxVg_l2Th-x3S1WDhjDl y79ajL4Kkd0AZMaZmh9ubmf63e3kyMj2", "d":"AY5pb7A0UFiB3RELSD64fTLOSV_jazdF7fLYyuTw8lOfRhWg6Y6rUrPA xerEzgdRhajnu0ferB0d53vM9mE15j2C" }
“x”x”x”x“x”x“x”x“x”x“x”x“x”x“x”x“x”x“x”x“x”x“x”x“x”x“x”x“x”x“x”x“x”x“x”x“x”x“x”x”x“y”x“y”y”y：“y”y”y：“y”y”y：“y”y”y：“y”y”x“y”x“y”x“y”y”x“y”x“y”y”y”y：“ADSMRA“ADSMR43ZZNNNZZZNNNX x x x x x x“x“x”x“x”x“x“x”x”x”x“x“x“x”x”x”x“x“x”x”x“x”x”x“x“x”x”x”x”x“x“x”x”x“x”x“x”“}
The ECDSA private part d is then passed to an ECDSA signing function, which also takes the curve type, P-521, the hash type, SHA-512, and the JWS Signing Input as inputs. The result of the digital signature is the EC point (R, S), where R and S are unsigned integers. In this example, the R and S values, given as octet sequences representing big-endian integers are:
ECDSA私有部分d随后被传递给ECDSA签名函数，该函数还将曲线类型P-521、哈希类型SHA-512和JWS签名输入作为输入。数字签名的结果是EC点（R，S），其中R和S是无符号整数。在本例中，作为表示大端整数的八位字节序列给出的R和S值为：
+--------+----------------------------------------------------------+
| Result | Value |
| Name | |
+--------+----------------------------------------------------------+
| R | [1, 220, 12, 129, 231, 171, 194, 209, 232, 135, 233, |
| | 117, 247, 105, 122, 210, 26, 125, 192, 1, 217, 21, 82, |
| | 91, 45, 240, 255, 83, 19, 34, 239, 71, 48, 157, 147, |
| | 152, 105, 18, 53, 108, 163, 214, 68, 231, 62, 153, 150, |
| | 106, 194, 164, 246, 72, 143, 138, 24, 50, 129, 223, 133, |
| | 206, 209, 172, 63, 237, 119, 109] |
| S | [0, 111, 6, 105, 44, 5, 41, 208, 128, 61, 152, 40, 92, |
| | 61, 152, 4, 150, 66, 60, 69, 247, 196, 170, 81, 193, |
| | 199, 78, 59, 194, 169, 16, 124, 9, 143, 42, 142, 131, |
| | 48, 206, 238, 34, 175, 83, 203, 220, 159, 3, 107, 155, |
| | 22, 27, 73, 111, 68, 68, 21, 238, 144, 229, 232, 148, |
| | 188, 222, 59, 242, 103] |
+--------+----------------------------------------------------------+
+--------+----------------------------------------------------------+
| Result | Value |
| Name | |
+--------+----------------------------------------------------------+
| R | [1, 220, 12, 129, 231, 171, 194, 209, 232, 135, 233, |
| | 117, 247, 105, 122, 210, 26, 125, 192, 1, 217, 21, 82, |
| | 91, 45, 240, 255, 83, 19, 34, 239, 71, 48, 157, 147, |
| | 152, 105, 18, 53, 108, 163, 214, 68, 231, 62, 153, 150, |
| | 106, 194, 164, 246, 72, 143, 138, 24, 50, 129, 223, 133, |
| | 206, 209, 172, 63, 237, 119, 109] |
| S | [0, 111, 6, 105, 44, 5, 41, 208, 128, 61, 152, 40, 92, |
| | 61, 152, 4, 150, 66, 60, 69, 247, 196, 170, 81, 193, |
| | 199, 78, 59, 194, 169, 16, 124, 9, 143, 42, 142, 131, |
| | 48, 206, 238, 34, 175, 83, 203, 220, 159, 3, 107, 155, |
| | 22, 27, 73, 111, 68, 68, 21, 238, 144, 229, 232, 148, |
| | 188, 222, 59, 242, 103] |
+--------+----------------------------------------------------------+
The JWS Signature is the value R || S. Encoding the signature as BASE64URL(JWS Signature) produces this value (with line breaks for display purposes only):
JWS签名是值R | | S。将签名编码为BASE64URL（JWS签名）将生成此值（换行符仅用于显示）：
AdwMgeerwtHoh-l192l60hp9wAHZFVJbLfD_UxMi70cwnZOYaRI1bKPWROc-mZZq wqT2SI-KGDKB34XO0aw_7XdtAG8GaSwFKdCAPZgoXD2YBJZCPEX3xKpRwcdOO8Kp EHwJjyqOgzDO7iKvU8vcnwNrmxYbSW9ERBXukOXolLzeO_Jn
AdwMgeerwtHoh-l192l60hp9wAHZFVJbLfD_UxMi70cwnZOYaRI1bKPWROc-mZZq wqT2SI-KGDKB34XO0aw_7XdtAG8GaSwFKdCAPZgoXD2YBJZCPEX3xKpRwcdOO8Kp EHWJJJYGZDO7IKVU8VCNWNRMXYBSW9ERBxUKOXOLZEO Jn
Concatenating these values in the order Header.Payload.Signature with period ('.') characters between the parts yields this complete JWS representation using the JWS Compact Serialization (with line breaks for display purposes only):
将order Header.Payload.Signature中的这些值与部分之间的句点（'.'）字符连接起来，可以使用JWS紧凑序列化（换行符仅用于显示目的）生成完整的JWS表示：
eyJhbGciOiJFUzUxMiJ9 . UGF5bG9hZA . AdwMgeerwtHoh-l192l60hp9wAHZFVJbLfD_UxMi70cwnZOYaRI1bKPWROc-mZZq wqT2SI-KGDKB34XO0aw_7XdtAG8GaSwFKdCAPZgoXD2YBJZCPEX3xKpRwcdOO8Kp EHwJjyqOgzDO7iKvU8vcnwNrmxYbSW9ERBXukOXolLzeO_Jn
eyJhbGciOiJFUzUxMiJ9。UGF5bG9hZA。AdwMgeerwtHoh-l192l60hp9wAHZFVJbLfD_UxMi70cwnZOYaRI1bKPWROc-mZZq wqT2SI-KGDKB34XO0aw_7XdtAG8GaSwFKdCAPZgoXD2YBJZCPEX3xKpRwcdOO8Kp EHWJJJYGZDO7IKVU8VCNWNRMXYBSW9ERBxUKOXOLZEO Jn
Since the "alg" Header Parameter is "ES512", we validate the ECDSA P-521 SHA-512 digital signature contained in the JWS Signature.
由于“alg”头参数是“ES512”，我们验证JWS签名中包含的ECDSA P-521 SHA-512数字签名。
Validating this JWS Signature is very similar to the previous example. We need to split the 132-member octet sequence of the JWS Signature into two 66-octet sequences, the first representing R and the second S. We then pass the public key (x, y), the signature (R, S), and the JWS Signing Input to an ECDSA signature verifier that has been configured to use the P-521 curve with the SHA-512 hash function.
验证此JWS签名与前面的示例非常相似。我们需要将JWS签名的132个成员八位组序列拆分为两个66个八位组序列，第一个代表R，第二个代表S。然后，我们将公钥（x，y）、签名（R，S）和JWS签名输入传递给ECDSA签名验证器，该验证器已配置为使用带有SHA-512哈希函数的P-521曲线。
The following example JWS Protected Header declares that the encoded object is an Unsecured JWS:
以下示例JWS-Protected标头声明编码的对象是不安全的JWS：
{"alg":"none"}
{"alg":"none"}
Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value:
将此受JWS保护的标头编码为BASE64URL（UTF8（受JWS保护的标头））将给出以下值：
eyJhbGciOiJub25lIn0
eyJhbGciOiJub25lIn0
The JWS Payload used in this example, which follows, is the same as in the previous examples. Since the BASE64URL(JWS Payload) value will therefore be the same, its computation is not repeated here.
下面的示例中使用的JWS有效负载与前面的示例中相同。由于BASE64URL（JWS有效负载）值因此是相同的，因此这里不重复其计算。
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
The JWS Signature is the empty octet string and BASE64URL(JWS Signature) is the empty string.
JWS签名是空的八位字节字符串，BASE64URL（JWS签名）是空字符串。
Concatenating these values in the order Header.Payload.Signature with period ('.') characters between the parts yields this complete JWS representation using the JWS Compact Serialization (with line breaks for display purposes only):
将order Header.Payload.Signature中的这些值与部分之间的句点（'.'）字符连接起来，可以使用JWS紧凑序列化（换行符仅用于显示目的）生成完整的JWS表示：
eyJhbGciOiJub25lIn0 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ .
eyJhbGciOiJub25lIn0。EYJPC3MIOIJQB2UILA0KIJLEHAIOJEZMDA4MTKZODAZODAQIMH0DHA6LY9LEGFT cGxlLmNvbS9pc19yb290Ijp0cnVlfQ。
This section contains an example using the general JWS JSON Serialization syntax. This example demonstrates the capability for conveying multiple digital signatures and/or MACs for the same payload.
本节包含一个使用通用JWS JSON序列化语法的示例。此示例演示了为同一有效负载传输多个数字签名和/或MAC的能力。
The JWS Payload used in this example is the same as that used in the examples in Appendix A.2 and Appendix A.3 (with line breaks for display purposes only):
本示例中使用的JWS有效载荷与附录A.2和附录A.3中示例中使用的JWS有效载荷相同（换行符仅用于显示目的）：
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
EYJPC3MIOIJQB2UILA0KIJLEHAIOJEZMDA4MTKZODAQIMH0DHA6LY9LEGFT cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
Two digital signatures are used in this example: the first using RSASSA-PKCS1-v1_5 SHA-256 and the second using ECDSA P-256 SHA-256. For the first, the JWS Protected Header and key are the same as in Appendix A.2, resulting in the same JWS Signature value; therefore, its computation is not repeated here. For the second, the JWS Protected Header and key are the same as in Appendix A.3, resulting in the same JWS Signature value; therefore, its computation is not repeated here.
本例中使用了两个数字签名：第一个使用RSASSA-PKCS1-v1_5 SHA-256，第二个使用ECDSA P-256 SHA-256。对于第一种情况，JWS保护的头和密钥与附录A.2中的相同，从而产生相同的JWS签名值；因此，此处不再重复其计算。对于第二种情况，JWS保护的头和密钥与附录A.3中的相同，从而产生相同的JWS签名值；因此，此处不再重复其计算。
The JWS Protected Header value used for the first signature is:
用于第一个签名的JWS受保护标头值为：
{"alg":"RS256"}
{"alg":"RS256"}
Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value:
将此受JWS保护的标头编码为BASE64URL（UTF8（受JWS保护的标头））将给出以下值：
eyJhbGciOiJSUzI1NiJ9
EYJHBGCOIJSUZI1NIJ9
The JWS Protected Header value used for the second signature is:
用于第二个签名的JWS受保护标头值为：
{"alg":"ES256"}
{"alg":"ES256"}
Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value:
将此受JWS保护的标头编码为BASE64URL（UTF8（受JWS保护的标头））将给出以下值：
eyJhbGciOiJFUzI1NiJ9
EYJHBGCOIJFUZI1NIJ9
Key ID values are supplied for both keys using per-signature Header Parameters. The two JWS Unprotected Header values used to represent these key IDs are:
使用每个签名头参数为两个密钥提供密钥ID值。用于表示这些密钥ID的两个JWS未受保护的头值是：
{"kid":"2010-12-29"}
{"kid":"2010-12-29"}
and
和
{"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"}
{"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"}
Combining the JWS Protected Header and JWS Unprotected Header values supplied, the JOSE Header values used for the first and second signatures, respectively, are:
结合提供的JWS受保护标头和JWS未受保护标头值，分别用于第一个和第二个签名的JOSE标头值为：
{"alg":"RS256",
"kid":"2010-12-29"}
{"alg":"RS256",
"kid":"2010-12-29"}
and
和
{"alg":"ES256",
"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"}
{"alg":"ES256",
"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"}
The complete JWS JSON Serialization for these values is as follows (with line breaks within values for display purposes only):
这些值的完整JWS JSON序列化如下（值中的换行符仅用于显示）：
{
"payload":
"eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGF
tcGxlLmNvbS9pc19yb290Ijp0cnVlfQ",
"signatures":[
{"protected":"eyJhbGciOiJSUzI1NiJ9",
"header":
{"kid":"2010-12-29"},
"signature":
"cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZ
mh7AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjb
KBYNX4BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHl
b1L07Qe7K0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZES
c6BfI7noOPqvhJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AX
LIhWkWywlVmtVrBp0igcN_IoypGlUPQGe77Rw"},
{"protected":"eyJhbGciOiJFUzI1NiJ9",
"header":
{"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"},
"signature":
"DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8IS
lSApmWQxfKTUJqPP3-Kg6NU1Q"}]
}
{
"payload":
"eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGF
tcGxlLmNvbS9pc19yb290Ijp0cnVlfQ",
"signatures":[
{"protected":"eyJhbGciOiJSUzI1NiJ9",
"header":
{"kid":"2010-12-29"},
"signature":
"cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZ
mh7AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjb
KBYNX4BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHl
b1L07Qe7K0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZES
c6BfI7noOPqvhJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AX
LIhWkWywlVmtVrBp0igcN_IoypGlUPQGe77Rw"},
{"protected":"eyJhbGciOiJFUzI1NiJ9",
"header":
{"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"},
"signature":
"DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8IS
lSApmWQxfKTUJqPP3-Kg6NU1Q"}]
}
This section contains an example using the flattened JWS JSON Serialization syntax. This example demonstrates the capability for conveying a single digital signature or MAC in a flattened JSON structure.
本节包含一个使用扁平化JWS JSON序列化语法的示例。此示例演示了在扁平JSON结构中传输单个数字签名或MAC的能力。
The values in this example are the same as those in the second signature of the previous example in Appendix A.6.
本示例中的值与附录A.6中前一示例的第二个签名中的值相同。
The complete JWS JSON Serialization for these values is as follows (with line breaks within values for display purposes only):
这些值的完整JWS JSON序列化如下（值中的换行符仅用于显示）：
{
"payload":
"eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGF
tcGxlLmNvbS9pc19yb290Ijp0cnVlfQ",
"protected":"eyJhbGciOiJFUzI1NiJ9",
"header":
{"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"},
"signature":
"DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8IS
lSApmWQxfKTUJqPP3-Kg6NU1Q"
}
{
"payload":
"eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGF
tcGxlLmNvbS9pc19yb290Ijp0cnVlfQ",
"protected":"eyJhbGciOiJFUzI1NiJ9",
"header":
{"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"},
"signature":
"DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8IS
lSApmWQxfKTUJqPP3-Kg6NU1Q"
}
Appendix B. "x5c" (X.509 Certificate Chain) Example
附录B“x5c”（X.509证书链）示例
The JSON array below is an example of a certificate chain that could be used as the value of an "x5c" (X.509 certificate chain) Header Parameter, per Section 4.1.6 (with line breaks within values for display purposes only):
下面的JSON数组是一个证书链示例，根据第4.1.6节，该证书链可用作“x5c”（X.509证书链）头参数的值（值中的换行符仅用于显示）：
["MIIE3jCCA8agAwIBAgICAwEwDQYJKoZIhvcNAQEFBQAwYzELMAkGA1UEBhMCVVM xITAfBgNVBAoTGFRoZSBHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR2 8gRGFkZHkgQ2xhc3MgMiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNjExM TYwMTU0MzdaFw0yNjExMTYwMTU0MzdaMIHKMQswCQYDVQQGEwJVUzEQMA4GA1UE CBMHQXJpem9uYTETMBEGA1UEBxMKU2NvdHRzZGFsZTEaMBgGA1UEChMRR29EYWR keS5jb20sIEluYy4xMzAxBgNVBAsTKmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYW RkeS5jb20vcmVwb3NpdG9yeTEwMC4GA1UEAxMnR28gRGFkZHkgU2VjdXJlIENlc nRpZmljYXRpb24gQXV0aG9yaXR5MREwDwYDVQQFEwgwNzk2OTI4NzCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMQt1RWMnCZM7DI161+4WQFapmGBWTt wY6vj3D3HKrjJM9N55DrtPDAjhI6zMBS2sofDPZVUBJ7fmd0LJR4h3mUpfjWoqV Tr9vcyOdQmVZWt7/v+WIbXnvQAjYwqDL1CBM6nPwT27oDyqu9SoWlm2r4arV3aL GbqGmu75RpRSgAvSMeYddi5Kcju+GZtCpyz8/x4fKL4o/K1w/O5epHBp+YlLpyo 7RJlbmr2EkRTcDCVw5wrWCs9CHRK8r5RsL+H0EwnWGu1NcWdrxcx+AuP7q2BNgW JCJjPOq8lh8BJ6qf9Z/dFjpfMFDniNoW1fho3/Rb2cRGadDAW/hOUoz+EDU8CAw EAAaOCATIwggEuMB0GA1UdDgQWBBT9rGEyk2xF1uLuhV+auud2mWjM5zAfBgNVH SMEGDAWgBTSxLDSkdRMEXGzYcs9of7dqGrU4zASBgNVHRMBAf8ECDAGAQH/AgEA MDMGCCsGAQUFBwEBBCcwJTAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AuZ29kYWR keS5jb20wRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NlcnRpZmljYXRlcy5nb2 RhZGR5LmNvbS9yZXBvc2l0b3J5L2dkcm9vdC5jcmwwSwYDVR0gBEQwQjBABgRVH SAAMDgwNgYIKwYBBQUHAgEWKmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5j b20vcmVwb3NpdG9yeTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggE BANKGwOy9+aG2Z+5mC6IGOgRQjhVyrEp0lVPLN8tESe8HkGsz2ZbwlFalEzAFPI UyIXvJxwqoJKSQ3kbTJSMUA2fCENZvD117esyfxVgqwcSeIaha86ykRvOe5GPLL 5CkKSkB2XIsKd83ASe8T+5o0yGPwLPk9Qnt0hCqU7S+8MxZC9Y7lhyVJEnfzuz9 p0iRFEUOOjZv2kWzRaJBydTXRE4+uXR21aITVSzGh6O1mawGhId/dQb8vxRMDsx uxN89txJx9OjxUUAiKEngHUuHqDTMBqLdElrRhjZkAzVvb3du6/KFUJheqwNTrZ EjYx8WnM25sgVjOuH0aBsXBTWVU+4=", "MIIE+zCCBGSgAwIBAgICAQ0wDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1Z hbGlDZXJ0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIE luYy4xNTAzBgNVBAsTLFZhbGlDZXJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb 24gQXV0aG9yaXR5MSEwHwYDVQQDExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8x IDAeBgkqhkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29tMB4XDTA0MDYyOTE3MDY yMFoXDTI0MDYyOTE3MDYyMFowYzELMAkGA1UEBhMCVVMxITAfBgNVBAoTGFRoZS BHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR28gRGFkZHkgQ2xhc3MgM iBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASAwDQYJKoZIhvcNAQEBBQADggEN ADCCAQgCggEBAN6d1+pXGEmhW+vXX0iG6r7d/+TvZxz0ZWizV3GgXne77ZtJ6XC APVYYYwhv2vLM0D9/AlQiVBDYsoHUwHU9S3/Hd8M+eKsaA7Ugay9qK7HFiH7Eux 6wwdhFJ2+qN1j3hybX2C32qRe3H3I2TqYXP2WYktsqbl2i/ojgC95/5Y0V4evLO tXiEqITLdiOr18SPaAIBQi2XKVlOARFmR6jYGB0xUGlcmIbYsUfb18aQr4CUWWo riMYavx4A6lNf4DD+qta/KFApMoZFv6yyO9ecw3ud72a9nmYvLEHZ6IVDd2gWMZ Eewo+YihfukEHU1jPEX44dMX4/7VpkI+EdOqXG68CAQOjggHhMIIB3TAdBgNVHQ
["Miie3JCCA8Agawibagicawewdqjkozihvcnafbqawyzelmaka1ebhmcvm-xitafbgnbaogfrozbhbybeywrkesbhCM91CCWGSW5JLJEXMC8GA1ECXMOR2 GrGFKZhKGqxHc3MgmiBdZxJ0AWZPy2AW9UiFg6F0Wnjexml0Wnjexm-tyWnjezdWnjezdWnjezdWnzDamzDamqmWnzWnzWcWnzWczWcqmWc2EcqmWc2Ec2Gc2Gc2Gc2Gc2Gc2Gc8Gc2Xg2Xg2Wg2Wg2Wg2Wg2Wg2Wg2Wg2Wg2Wnz2W2.在中国的一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，两个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，一个城市，WT27ODYQU9SOWLM2R4A一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，或者CCWJTA2.一个中国政府在一个中国政府在一个中国政府在一个中国政府在一个中国政府在一个中国政府在一个中国政府在一个中国政府在一个中国政府在一个中国政府在一个中国政府在一个中国政府在一个中国政府在一个中国政府在一个中国政府在一个中国政府在一个中国政府在一个中国政府在一个中国政府在一个中国政府在一个中国的一个中国政府在一个中国政府在一个中国的一个中国政府在一个中国的一个中国政府在一个中国政府在一个中国在一个中国的一个中国政府在一个中国政府在一个中国在一个中国在一个中国的2个中国政府在一个中国在一个中国政府在一个中国的2个中国政府在一个中国政府在一个中国的2个中国的政府在一个中国政府在一个中国的2个中国政府在一个中国政府在一个中国的2个中国政府在一个中国的2个tese8hkgsz2zbwlFalEzAFPI Uyixvjxwqojksq3kbtjsmua2fcenzvd117esyfxvgqwcseiah86ykrvoe5cpll 5kkskb2xiskd83ase8t+5o0yGPwLPk9Qnt0hCqU7S+8mxzc9y7yvj7yfzuz9 p0irfeuojzv2kwzrajbydtxre4+uxr2aitvzg6o1awghid/dqqb8vx8vxrmdsx uxxjjjx9ojjjjjjjjvzkjjjjjjjjjjjjvzzkvzvzk8vzjjjjjjjjjjjzzzvzzzzzzzzzvzzzzvzzvzzzMIIE+ZCcbgsgawibagicaq0Wdqyjkozihvcnaqfbqawgbsxjdaibgnbactg1z HBgldzxJ0IfzHBglyxRPB24GTMV0D29Yazexmbuga1uechmovmqs Luy4xNtazGnzGnzHBgldzxJ0iensynzyG9Saw5IfzHBglyxKyxRPB 24GqQdxV0G9Ag9If8V0If8Vd3LnzHBglyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKyKy2.中文意思是一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，一个单词，2I/ojgC95/5Y0V4evLO TXIEQITLDIOR18SPAIQI2xKVLOARFMR6JYGB0XUGLCMIBYSUFB18AQR4CUWWO riMYavx4A6lNf4DD+qta/KFApMoZFv6yyO9ecw3ud72a9nmYvLEHZ6IVDd2gWMZ Eewo+YihfukEHU1jPEX44dMX4/7VpkI+EDOQG68CAQOGHMIIB3ADBGNVHQ
4EFgQU0sSw0pHUTBFxs2HLPaH+3ahq1OMwgdIGA1UdIwSByjCBx6GBwaSBvjCBu zEkMCIGA1UEBxMbVmFsaUNlcnQgVmFsaWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQK Ew5WYWxpQ2VydCwgSW5jLjE1MDMGA1UECxMsVmFsaUNlcnQgQ2xhc3MgMiBQb2x pY3kgVmFsaWRhdGlvbiBBdXRob3JpdHkxITAfBgNVBAMTGGh0dHA6Ly93d3cudm FsaWNlcnQuY29tLzEgMB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5jb22CA QEwDwYDVR0TAQH/BAUwAwEB/zAzBggrBgEFBQcBAQQnMCUwIwYIKwYBBQUHMAGG F2h0dHA6Ly9vY3NwLmdvZGFkZHkuY29tMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA 6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeS9yb290LmNybD BLBgNVHSAERDBCMEAGBFUdIAAwODA2BggrBgEFBQcCARYqaHR0cDovL2NlcnRpZ mljYXRlcy5nb2RhZGR5LmNvbS9yZXBvc2l0b3J5MA4GA1UdDwEB/wQEAwIBBjAN BgkqhkiG9w0BAQUFAAOBgQC1QPmnHfbq/qQaQlpE9xXUhUaJwL6e4+PrxeNYiY+ Sn1eocSxI0YGyeR+sBjUZsE4OWBsUs5iB0QQeyAfJg594RAoYC5jcdnplDQ1tgM QLARzLrUc+cb53S8wGd9D0VmsfSxOaFIqII6hR8INMqzW/Rn453HWkrugp++85j 09VZw==", "MIIC5zCCAlACAQEwDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1ZhbGlDZXJ 0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNT AzBgNVBAsTLFZhbGlDZXJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb24gQXV0a G9yaXR5MSEwHwYDVQQDExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkq hkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29tMB4XDTk5MDYyNjAwMTk1NFoXDTE 5MDYyNjAwMTk1NFowgbsxJDAiBgNVBAcTG1ZhbGlDZXJ0IFZhbGlkYXRpb24gTm V0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNTAzBgNVBAsTLFZhbGlDZ XJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb24gQXV0aG9yaXR5MSEwHwYDVQQD ExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkqhkiG9w0BCQEWEWluZm9 AdmFsaWNlcnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOOnHK5a vIWZJV16vYdA757tn2VUdZZUcOBVXc65g2PFxTXdMwzzjsvUGJ7SVCCSRrCl6zf N1SLUzm1NZ9WlmpZdRJEy0kTRxQb7XBhVQ7/nHk01xC+YDgkRoKWzk2Z/M/VXwb P7RfZHM047QSv4dk+NoS/zcnwbNDu+97bi5p9wIDAQABMA0GCSqGSIb3DQEBBQU AA4GBADt/UG9vUJSZSWI4OB9L+KXIPqeCgfYrx+jFzug6EILLGACOTb2oWH+heQ C1u+mNr0HZDzTuIYEZoDJJKPTEjlbVUjP9UNV+mWwD5MlM/Mtsq2azSiGM5bUMM j4QssxsodyamEwCW/POuZ6lcg5Ktz885hZo+L7tdEy8W9ViH0Pd"]
4EFgQU0sSw0pHUTBFxs2HLPaH+3HQ1OmWgWgWgWgWgWgWgWbWbWjcbu Zekmciga1ebxMbbWmFgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWgWQEWDWYDVR0TACH/BAUwAwEB/ZAZBGGGRBGEFBQCBAQNMCUWIIKWYBBQUHMAGG F2H0Dha6L9VY3WLVZGFKKKUY29TMEQGA1DHQ9MDSWOAA3 ODWGM2H0DHA 6Y9JZXJ0AWZPY2F0ZXMUZ29KYEWR5JB20VCMVWB3PDG9YES9YB290LMNYBB BLBGN7NYB7NYB7NYB7NYB9BLBGN7N7NYB7NYB7NYB9BLBGNYB9BLBGN7NYBYBYBYB9L2LKKKKKKKK2L2L2L2L2L2LKKKKYBYBYBYBYBYBYBYBYBYBBgkqhkiG9w0BAQUFAAOBgQC1QPmnHfbq/qQaQlpE9xXUhUaJwL6e4+PRXENYY+SN1EOCSXI0YGYYYY+SBJUZSE4OWBSUS5IB0QEYAFJG594RAOYC5JCDNPLDQ1TGM QLARZLUC+CB53S8WGD9D0VMSFXOAFIIQI6HR8INMQZW/RN453WKRUGP++85j 09VZw==“，”Miic5zcalacaqewdqyjkozihvcnaqfbgwgbsxjdaigugbgbg1zhbglyxrpb24gtmv0d29yazexmbuchmovznqsieluy4xnt Azbgbgzbgzbgzbgxj0iensynzidg9sawn5ifzhbglyxrpb24gxv0a g9yaxr5msehwwydqdqdxqdqdxwqdxhqdxwqdxhqdxwwwwwzzzzg3d3d3Lnzb3Lnzb9Lnzb9Lnzhbglyzg9wg9wzg9wg9wg9dxxxxxxxxxxxxxxxxxxxxxx5DYNJAWMTK1NFOWGBSXJDAIBGNVBACTG1ZHBGLDZJ0IFZHBGLKYXRPB24GTM V0D29YAZEXMBUGA1UECHMOVSANLCNQSIELUY4NTAZGNVBASTLFZHBGLDZ XJ0IENSYXNZIDIGUG9SAWN5IFZHBGLKYXRPB24GF0AG9YAXR5MSWHWYDVQQQD8LZHBGLJJ0LMNVB8I8IDAEBQQQKK9B9F9B9FKKKK4G4G4G4G4G4G4G4G4G4G4G4G4G4G4G4G4G4G4G4G4G4G4G4G4G4G4G4G4G4G4G4G4G4G4G4G4VIWZJV16VYDA757TN2VUDZUZUCBvxC65G2FxTxDmWzJSvG7SvCsRrcl6ZF N1SLUzm1NZ9WlmpZdRJEy0kTRxQb7XBhVQ7/nHk01xC+YDGROKWZK2Z/M/VXwb P7RfZHM047QSv4dk+NoS/zcnwbNDu+97BI5P9WID9WID9MNT/UG9VU9VU9VuJZZWI4OB9L+KXIPQECGFYRZYR2ZYR9M+JZU9JJZZU9J9J9JJZZZU9M+JJ9JJJ9J9ZZZZZZZZZU9M/JJJ9ZZZZZZZZZZZZZU9L9LJ4QSSXSSODYAMEWCW/POuZ6lcg5Ktz885hZo+L7tdEy8W9ViH0Pd“]
This appendix describes how to implement base64url encoding and decoding functions without padding based upon standard base64 encoding and decoding functions that do use padding.
本附录描述了如何基于使用填充的标准base64编码和解码函数，在没有填充的情况下实现base64url编码和解码函数。
To be concrete, example C# code implementing these functions is shown below. Similar code could be used in other languages.
具体来说，实现这些函数的示例C#代码如下所示。类似的代码可以在其他语言中使用。
static string base64urlencode(byte [] arg)
{
string s = Convert.ToBase64String(arg); // Regular base64 encoder
s = s.Split('=')[0]; // Remove any trailing '='s
s = s.Replace('+', '-'); // 62nd char of encoding
s = s.Replace('/', '_'); // 63rd char of encoding
return s;
}
static string base64urlencode(byte [] arg)
{
string s = Convert.ToBase64String(arg); // Regular base64 encoder
s = s.Split('=')[0]; // Remove any trailing '='s
s = s.Replace('+', '-'); // 62nd char of encoding
s = s.Replace('/', '_'); // 63rd char of encoding
return s;
}
static byte [] base64urldecode(string arg)
{
string s = arg;
s = s.Replace('-', '+'); // 62nd char of encoding
s = s.Replace('_', '/'); // 63rd char of encoding
switch (s.Length % 4) // Pad with trailing '='s
{
case 0: break; // No pad chars in this case
case 2: s += "=="; break; // Two pad chars
case 3: s += "="; break; // One pad char
default: throw new System.Exception(
"Illegal base64url string!");
}
return Convert.FromBase64String(s); // Standard base64 decoder
}
static byte [] base64urldecode(string arg)
{
string s = arg;
s = s.Replace('-', '+'); // 62nd char of encoding
s = s.Replace('_', '/'); // 63rd char of encoding
switch (s.Length % 4) // Pad with trailing '='s
{
case 0: break; // No pad chars in this case
case 2: s += "=="; break; // Two pad chars
case 3: s += "="; break; // One pad char
default: throw new System.Exception(
"Illegal base64url string!");
}
return Convert.FromBase64String(s); // Standard base64 decoder
}
As per the example code above, the number of '=' padding characters that needs to be added to the end of a base64url-encoded string without padding to turn it into one with padding is a deterministic function of the length of the encoded string. Specifically, if the length mod 4 is 0, no padding is added; if the length mod 4 is 2, two '=' padding characters are added; if the length mod 4 is 3, one '=' padding character is added; if the length mod 4 is 1, the input is malformed.
根据上面的示例代码，需要添加到base64url编码字符串末尾的“=”填充字符数（无需填充即可将其转换为带填充的字符串）是编码字符串长度的确定函数。具体而言，如果长度mod 4为0，则不添加填充；如果长度mod 4为2，则添加两个“=”填充字符；如果长度mod 4为3，则添加一个“=”填充字符；如果长度mod 4为1，则输入格式不正确。
An example correspondence between unencoded and encoded values follows. The octet sequence below encodes into the string below, which when decoded, reproduces the octet sequence.
下面是未编码值和编码值之间的对应关系示例。下面的八位字节序列编码到下面的字符串中，该字符串在解码时再现八位字节序列。
3 236 255 224 193 A-z_4ME
3 236 255 224 193 A-ze
This appendix describes a set of possible algorithms for selecting the key to be used to validate the digital signature or MAC of a JWS or for selecting the key to be used to decrypt a JWE. This guidance describes a family of possible algorithms rather than a single algorithm, because in different contexts, not all the sources of keys will be used, they can be tried in different orders, and sometimes not all the collected keys will be tried; hence, different algorithms will be used in different application contexts.
本附录描述了一组可能的算法，用于选择用于验证JWS的数字签名或MAC的密钥，或选择用于解密JWE的密钥。本指南描述了一系列可能的算法，而不是单一的算法，因为在不同的上下文中，不会使用所有的密钥源，它们可以按不同的顺序进行尝试，有时也不会尝试所有收集的密钥；因此，将在不同的应用环境中使用不同的算法。
The steps below are described for illustration purposes only; specific applications can and are likely to use different algorithms or perform some of the steps in different orders. Specific applications will frequently have a much simpler method of determining the keys to use, as there may be one or two key selection methods that are profiled for the application's use. This appendix supplements the normative information on key location in Section 6.
以下步骤仅用于说明目的；特定的应用程序可以并且可能使用不同的算法，或者以不同的顺序执行某些步骤。特定的应用程序通常会有一个更简单的方法来确定要使用的键，因为可能有一个或两个键选择方法供应用程序使用。本附录补充了第6节中关于关键位置的规范性信息。
These algorithms include the following steps. Note that the steps can be performed in any order and do not need to be treated as distinct. For example, keys can be tried as soon as they are found, rather than collecting all the keys before trying any.
这些算法包括以下步骤。请注意，这些步骤可以按任何顺序执行，无需视为不同的步骤。例如，可以在找到密钥后立即进行尝试，而不是在尝试任何密钥之前收集所有密钥。
1. Collect the set of potentially applicable keys. Sources of keys may include:
1. 收集可能适用的密钥集。钥匙的来源可能包括：
* Keys supplied by the application protocol being used.
* 由正在使用的应用程序协议提供的密钥。
* Keys referenced by the "jku" (JWK Set URL) Header Parameter.
* “jku”（JWK Set URL）头参数引用的键。
* The key provided by the "jwk" (JSON Web Key) Header Parameter.
* “jwk”（JSON Web键）头参数提供的键。
* The key referenced by the "x5u" (X.509 URL) Header Parameter.
* “x5u”（X.509 URL）头参数引用的键。
* The key provided by the "x5c" (X.509 certificate chain) Header Parameter.
* “x5c”（X.509证书链）头参数提供的密钥。
* Other applicable keys available to the application.
* 应用程序可用的其他适用密钥。
The order for collecting and trying keys from different key sources is typically application dependent. For example, frequently, all keys from a one set of locations, such as local caches, will be tried before collecting and trying keys from other locations.
从不同密钥源收集和尝试密钥的顺序通常取决于应用程序。例如，通常情况下，在从其他位置收集和尝试密钥之前，将尝试来自一组位置（如本地缓存）的所有密钥。
2. Filter the set of collected keys. For instance, some applications will use only keys referenced by "kid" (key ID) or "x5t" (X.509 certificate SHA-1 thumbprint) parameters. If the application uses the JWK "alg" (algorithm), "use" (public key use), or "key_ops" (key operations) parameters, keys with inappropriate values of those parameters would be excluded. Additionally, keys might be filtered to include or exclude keys with certain other member values in an application-specific manner. For some applications, no filtering will be applied.
2. 筛选收集的密钥集。例如，某些应用程序将仅使用“kid”（密钥ID）或“x5t”（X.509证书SHA-1指纹）参数引用的密钥。如果应用程序使用JWK“alg”（算法）、“use”（公钥使用）或“key_ops”（密钥操作）参数，则这些参数值不正确的密钥将被排除在外。此外，可以过滤键，以特定于应用程序的方式包括或排除具有某些其他成员值的键。对于某些应用程序，将不应用任何筛选。
3. Order the set of collected keys. For instance, keys referenced by "kid" (key ID) or "x5t" (X.509 certificate SHA-1 thumbprint) parameters might be tried before keys with neither of these values. Likewise, keys with certain member values might be ordered before keys with other member values. For some applications, no ordering will be applied.
3. 对收集的密钥集进行排序。例如，“kid”（密钥ID）或“x5t”（X.509证书SHA-1指纹）参数引用的密钥可能会在没有这两个值的密钥之前进行尝试。同样，具有某些成员值的键可能会在具有其他成员值的键之前排序。对于某些应用，将不进行订购。
4. Make trust decisions about the keys. Signatures made with keys not meeting the application's trust criteria would not be accepted. Such criteria might include, but is not limited to, the source of the key, whether the TLS certificate validates for keys retrieved from URLs, whether a key in an X.509 certificate is backed by a valid certificate chain, and other information known by the application.
4. 对密钥进行信任决策。使用不符合应用程序信任标准的密钥进行的签名将不被接受。此类标准可能包括但不限于密钥的来源、TLS证书是否验证从URL检索的密钥、X.509证书中的密钥是否由有效的证书链支持以及应用程序已知的其他信息。
5. Attempt signature or MAC validation for a JWS or decryption of a JWE with some or all of the collected and possibly filtered and/ or ordered keys. A limit on the number of keys to be tried might be applied. This process will normally terminate following a successful validation or decryption.
5. 尝试对JWS进行签名或MAC验证，或使用部分或全部收集的、可能已过滤和/或已排序的密钥对JWE进行解密。可能会对要尝试的密钥数量施加限制。此过程通常在成功验证或解密后终止。
Note that it is reasonable for some applications to perform signature or MAC validation prior to making a trust decision about a key, since keys for which the validation fails need no trust decision.
请注意，某些应用程序在对密钥作出信任决定之前执行签名或MAC验证是合理的，因为验证失败的密钥不需要信任决定。
Appendix E. Negative Test Case for "crit" Header Parameter
附录E“crit”标题参数的否定测试用例
Conforming implementations must reject input containing critical extensions that are not understood or cannot be processed. The following JWS must be rejected by all implementations, because it uses an extension Header Parameter name "http://example.invalid/ UNDEFINED" that they do not understand. Any other similar input, in which the use of the value "http://example.invalid/UNDEFINED" is substituted for any other Header Parameter name not understood by the implementation, must also be rejected.
一致性实现必须拒绝包含未理解或无法处理的关键扩展的输入。以下JWS必须被所有实现拒绝，因为它使用扩展头参数名“http://example.invalid/ 他们不理解的“未定义”。任何其他类似输入，其中值的使用“http://example.invalid/UNDEFINED“替换为实现无法理解的任何其他标头参数名称，也必须被拒绝。
The JWS Protected Header value for this JWS is:
此JWS的JWS保护标头值为：
{"alg":"none",
"crit":["http://example.invalid/UNDEFINED"],
"http://example.invalid/UNDEFINED":true
}
{"alg":"none",
"crit":["http://example.invalid/UNDEFINED"],
"http://example.invalid/UNDEFINED":true
}
The complete JWS that must be rejected is as follows (with line breaks for display purposes only):
必须拒绝的完整JWS如下（换行符仅用于显示目的）：
eyJhbGciOiJub25lIiwNCiAiY3JpdCI6WyJodHRwOi8vZXhhbXBsZS5jb20vVU5ERU ZJTkVEIl0sDQogImh0dHA6Ly9leGFtcGxlLmNvbS9VTkRFRklORUQiOnRydWUNCn0. RkFJTA.
EYJHBGCIOIJUB25LIIWYJODHRWOI8VZXHBXBS5JB20VVU5ERU ZJTKVEIL0SDQOGIMH0DHA6LY9LegftCGXLLMNVBS9VTKRFKloruQionRYDWUNCN0。RkFJTA。
In some contexts, it is useful to integrity-protect content that is not itself contained in a JWS. One way to do this is to create a JWS in the normal fashion using a representation of the content as the payload but then delete the payload representation from the JWS and send this modified object to the recipient rather than the JWS. When using the JWS Compact Serialization, the deletion is accomplished by replacing the second field (which contains BASE64URL(JWS Payload)) value with the empty string; when using the JWS JSON Serialization, the deletion is accomplished by deleting the "payload" member. This method assumes that the recipient can reconstruct the exact payload used in the JWS. To use the modified object, the recipient reconstructs the JWS by re-inserting the payload representation into the modified object and uses the resulting JWS in the usual manner. Note that this method needs no support from JWS libraries, as applications can use this method by modifying the inputs and outputs of standard JWS libraries.
在某些上下文中，保护JWS中不包含的内容的完整性非常有用。一种方法是以正常方式创建JWS，使用内容的表示作为有效负载，然后从JWS中删除有效负载表示，并将修改后的对象发送给收件人，而不是JWS。使用JWS紧凑序列化时，删除是通过将第二个字段（包含BASE64URL（JWS有效负载））值替换为空字符串来完成的；使用JWS JSON序列化时，删除是通过删除“payload”成员来完成的。此方法假设接收方可以重建JWS中使用的确切有效负载。为了使用修改后的对象，接收者通过将有效负载表示重新插入到修改后的对象中来重构JW，并以通常的方式使用生成的JW。请注意，此方法不需要JWS库的支持，因为应用程序可以通过修改标准JWS库的输入和输出来使用此方法。
Acknowledgements
致谢
Solutions for signing JSON content were previously explored by Magic Signatures [MagicSignatures], JSON Simple Sign [JSS], and Canvas Applications [CanvasApp], all of which influenced this document.
签名JSON内容的解决方案之前由Magic Signatures[MagicSignatures]、JSON Simple Sign[JSS]和CanvasApp[CanvasApp]探索，所有这些都影响了本文档。
Thanks to Axel Nennker for his early implementation and feedback on the JWS and JWE specifications.
感谢Axel Nennker对JWS和JWE规范的早期实施和反馈。
This specification is the work of the JOSE working group, which includes dozens of active and dedicated participants. In particular, the following individuals contributed ideas, feedback, and wording that influenced this specification:
本规范是JOSE工作组的工作，该工作组包括数十名积极和专注的参与者。特别是，以下个人提供了影响本规范的想法、反馈和措辞：
Dirk Balfanz, Richard Barnes, Brian Campbell, Alissa Cooper, Breno de Medeiros, Stephen Farrell, Yaron Y. Goland, Dick Hardt, Joe Hildebrand, Jeff Hodges, Russ Housley, Edmund Jay, Tero Kivinen, Ben Laurie, Ted Lemon, James Manger, Matt Miller, Kathleen Moriarty, Tony Nadalin, Hideki Nara, Axel Nennker, John Panzer, Ray Polk, Emmanuel Raviart, Eric Rescorla, Pete Resnick, Jim Schaad, Paul Tarjan, Hannes Tschofenig, and Sean Turner.
德克·巴尔芬兹、理查德·巴恩斯、布赖恩·坎贝尔、艾莉莎·库珀、布伦诺·德梅德罗斯、斯蒂芬·法雷尔、雅伦·戈兰、迪克·哈特、乔·希尔德布兰德、杰夫·霍奇斯、罗斯·霍斯利、埃德蒙·杰伊、特罗·基维宁、本·劳里、特德·莱蒙、詹姆斯·马格尔、马特·米勒、凯瑟琳·莫里亚蒂、托尼·纳达林、希德基·纳拉、阿克塞尔·内内克尔、约翰·帕泽、雷·波尔克、艾曼纽尔·拉维特、，Eric Rescorla、Pete Resnick、Jim Schaad、Paul Tarjan、Hannes Tschofenig和Sean Turner。
Jim Schaad and Karen O'Donoghue chaired the JOSE working group and Sean Turner, Stephen Farrell, and Kathleen Moriarty served as Security Area Directors during the creation of this specification.
Jim Schaad和Karen O'Donoghue担任JOSE工作组主席，Sean Turner、Stephen Farrell和Kathleen Moriarty在创建本规范期间担任安全区域主管。
Authors' Addresses
作者地址
Michael B. Jones Microsoft
迈克尔·琼斯微软公司
EMail: mbj@microsoft.com
URI: http://self-issued.info/
EMail: mbj@microsoft.com
URI: http://self-issued.info/
John Bradley Ping Identity
约翰·布拉德利·平身份
EMail: ve7jtb@ve7jtb.com
URI: http://www.thread-safe.com/
EMail: ve7jtb@ve7jtb.com
URI: http://www.thread-safe.com/
Nat Sakimura Nomura Research Institute
野村新樱研究所
EMail: n-sakimura@nri.co.jp
URI: http://nat.sakimura.org/
EMail: n-sakimura@nri.co.jp
URI: http://nat.sakimura.org/