draft-ietf-jose-json-web-signature-11.txt   draft-ietf-jose-json-web-signature-12.txt 
JOSE Working Group M. Jones JOSE Working Group M. Jones
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track J. Bradley Intended status: Standards Track J. Bradley
Expires: November 29, 2013 Ping Identity Expires: January 12, 2014 Ping Identity
N. Sakimura N. Sakimura
NRI NRI
May 28, 2013 July 11, 2013
JSON Web Signature (JWS) JSON Web Signature (JWS)
draft-ietf-jose-json-web-signature-11 draft-ietf-jose-json-web-signature-12
Abstract Abstract
JSON Web Signature (JWS) is a means of representing content secured JSON Web Signature (JWS) is a means of representing content secured
with digital signatures or Message Authentication Codes (MACs) using with digital signatures or Message Authentication Codes (MACs) using
JavaScript Object Notation (JSON) based data structures. JavaScript Object Notation (JSON) based data structures.
Cryptographic algorithms and identifiers for use with this Cryptographic algorithms and identifiers for use with this
specification are described in the separate JSON Web Algorithms (JWA) specification are described in the separate JSON Web Algorithms (JWA)
specification. Related encryption capabilities are described in the specification. Related encryption capabilities are described in the
separate JSON Web Encryption (JWE) specification. separate JSON Web Encryption (JWE) specification.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 29, 2013. This Internet-Draft will expire on January 12, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. JSON Web Signature (JWS) Overview . . . . . . . . . . . . . . 6 3. JSON Web Signature (JWS) Overview . . . . . . . . . . . . . . 6
3.1. Example JWS . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Example JWS . . . . . . . . . . . . . . . . . . . . . . . 6
4. JWS Header . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. JWS Header . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Reserved Header Parameter Names . . . . . . . . . . . . . 8 4.1. Reserved Header Parameter Names . . . . . . . . . . . . . 8
4.1.1. "alg" (Algorithm) Header Parameter . . . . . . . . . . 8 4.1.1. "alg" (Algorithm) Header Parameter . . . . . . . . . . 8
4.1.2. "jku" (JWK Set URL) Header Parameter . . . . . . . . . 9 4.1.2. "jku" (JWK Set URL) Header Parameter . . . . . . . . . 9
4.1.3. "jwk" (JSON Web Key) Header Parameter . . . . . . . . 9 4.1.3. "jwk" (JSON Web Key) Header Parameter . . . . . . . . 9
4.1.4. "x5u" (X.509 URL) Header Parameter . . . . . . . . . . 9 4.1.4. "x5u" (X.509 URL) Header Parameter . . . . . . . . . . 9
4.1.5. "x5t" (X.509 Certificate Thumbprint) Header 4.1.5. "x5t" (X.509 Certificate Thumbprint) Header
Parameter . . . . . . . . . . . . . . . . . . . . . . 9 Parameter . . . . . . . . . . . . . . . . . . . . . . 10
4.1.6. "x5c" (X.509 Certificate Chain) Header Parameter . . . 10 4.1.6. "x5c" (X.509 Certificate Chain) Header Parameter . . . 10
4.1.7. "kid" (Key ID) Header Parameter . . . . . . . . . . . 10 4.1.7. "kid" (Key ID) Header Parameter . . . . . . . . . . . 10
4.1.8. "typ" (Type) Header Parameter . . . . . . . . . . . . 10 4.1.8. "typ" (Type) Header Parameter . . . . . . . . . . . . 11
4.1.9. "cty" (Content Type) Header Parameter . . . . . . . . 11 4.1.9. "cty" (Content Type) Header Parameter . . . . . . . . 11
4.1.10. "crit" (Critical) Header Parameter . . . . . . . . . . 11 4.1.10. "crit" (Critical) Header Parameter . . . . . . . . . . 11
4.2. Public Header Parameter Names . . . . . . . . . . . . . . 11 4.2. Public Header Parameter Names . . . . . . . . . . . . . . 12
4.3. Private Header Parameter Names . . . . . . . . . . . . . . 12 4.3. Private Header Parameter Names . . . . . . . . . . . . . . 12
5. Producing and Consuming JWSs . . . . . . . . . . . . . . . . . 12 5. Producing and Consuming JWSs . . . . . . . . . . . . . . . . . 12
5.1. Message Signing or MACing . . . . . . . . . . . . . . . . 12 5.1. Message Signing or MACing . . . . . . . . . . . . . . . . 12
5.2. Message Signature or MAC Validation . . . . . . . . . . . 13 5.2. Message Signature or MAC Validation . . . . . . . . . . . 13
5.3. String Comparison Rules . . . . . . . . . . . . . . . . . 14 5.3. String Comparison Rules . . . . . . . . . . . . . . . . . 15
6. Cryptographic Algorithms . . . . . . . . . . . . . . . . . . . 15 6. Key Identification . . . . . . . . . . . . . . . . . . . . . . 15
7. Key Identification . . . . . . . . . . . . . . . . . . . . . . 15 7. Serializations . . . . . . . . . . . . . . . . . . . . . . . . 16
8. JWS JSON Serialization . . . . . . . . . . . . . . . . . . . . 15 7.1. JWS Compact Serialization . . . . . . . . . . . . . . . . 16
9. Implementation Considerations . . . . . . . . . . . . . . . . 18 7.2. JWS JSON Serialization . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10.1. JSON Web Signature and Encryption Header Parameters 8.1. JSON Web Signature and Encryption Header Parameters
Registry . . . . . . . . . . . . . . . . . . . . . . . . . 18 Registry . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1.1. Registration Template . . . . . . . . . . . . . . . . 19 8.1.1. Registration Template . . . . . . . . . . . . . . . . 19
10.1.2. Initial Registry Contents . . . . . . . . . . . . . . 19 8.1.2. Initial Registry Contents . . . . . . . . . . . . . . 19
10.2. JSON Web Signature and Encryption Type Values Registry . . 20 8.2. JSON Web Signature and Encryption Type Values Registry . . 21
10.2.1. Registration Template . . . . . . . . . . . . . . . . 20 8.2.1. Registration Template . . . . . . . . . . . . . . . . 21
10.2.2. Initial Registry Contents . . . . . . . . . . . . . . 21 8.2.2. Initial Registry Contents . . . . . . . . . . . . . . 21
10.3. Media Type Registration . . . . . . . . . . . . . . . . . 21 8.3. Media Type Registration . . . . . . . . . . . . . . . . . 22
10.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 21 8.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 22
11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
11.1. Cryptographic Security Considerations . . . . . . . . . . 23 9.1. Cryptographic Security Considerations . . . . . . . . . . 23
11.2. JSON Security Considerations . . . . . . . . . . . . . . . 24 9.2. JSON Security Considerations . . . . . . . . . . . . . . . 24
11.3. Unicode Comparison Security Considerations . . . . . . . . 24 9.3. Unicode Comparison Security Considerations . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.4. TLS Requirements . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References . . . . . . . . . . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.2. Informative References . . . . . . . . . . . . . . . . . . 26 10.1. Normative References . . . . . . . . . . . . . . . . . . . 25
Appendix A. JWS Examples . . . . . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . . . . . . . . . . . 27
A.1. Example JWS using HMAC SHA-256 . . . . . . . . . . . . . . 27 Appendix A. JWS Examples . . . . . . . . . . . . . . . . . . . . 28
A.1.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 27 A.1. Example JWS using HMAC SHA-256 . . . . . . . . . . . . . . 28
A.1.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 29 A.1.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 28
A.1.3. Validating . . . . . . . . . . . . . . . . . . . . . . 29 A.1.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 30
A.2. Example JWS using RSASSA-PKCS-v1_5 SHA-256 . . . . . . . . 29 A.1.3. Validating . . . . . . . . . . . . . . . . . . . . . . 30
A.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 29 A.2. Example JWS using RSASSA-PKCS-v1_5 SHA-256 . . . . . . . . 30
A.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 31
A.2.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 33 A.2.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 33
A.2.3. Validating . . . . . . . . . . . . . . . . . . . . . . 33 A.2.3. Validating . . . . . . . . . . . . . . . . . . . . . . 33
A.3. Example JWS using ECDSA P-256 SHA-256 . . . . . . . . . . 34 A.3. Example JWS using ECDSA P-256 SHA-256 . . . . . . . . . . 34
A.3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 34 A.3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 34
A.3.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 36 A.3.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 36
A.3.3. Validating . . . . . . . . . . . . . . . . . . . . . . 36 A.3.3. Validating . . . . . . . . . . . . . . . . . . . . . . 36
A.4. Example JWS using ECDSA P-521 SHA-512 . . . . . . . . . . 37 A.4. Example JWS using ECDSA P-521 SHA-512 . . . . . . . . . . 36
A.4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 37 A.4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 36
A.4.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 39 A.4.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 38
A.4.3. Validating . . . . . . . . . . . . . . . . . . . . . . 39 A.4.3. Validating . . . . . . . . . . . . . . . . . . . . . . 39
A.5. Example Plaintext JWS . . . . . . . . . . . . . . . . . . 40 A.5. Example Plaintext JWS . . . . . . . . . . . . . . . . . . 39
A.6. Example JWS Using JWS JSON Serialization . . . . . . . . . 41 A.6. Example JWS Using JWS JSON Serialization . . . . . . . . . 40
A.6.1. JWS Protected Header . . . . . . . . . . . . . . . . . 41 A.6.1. JWS Protected Header . . . . . . . . . . . . . . . . . 40
A.6.2. JWS Per-Signature Unprotected Headers . . . . . . . . 41 A.6.2. JWS Per-Signature Unprotected Headers . . . . . . . . 40
A.6.3. Complete JWS Header Values . . . . . . . . . . . . . . 41 A.6.3. Complete JWS Header Values . . . . . . . . . . . . . . 41
A.6.4. Complete JWS JSON Serialization Representation . . . . 42 A.6.4. Complete JWS JSON Serialization Representation . . . . 41
A.6.5. RSA Key Used for Second Signature . . . . . . . . . . 42 A.6.5. RSA Key Used for Second Signature . . . . . . . . . . 42
Appendix B. "x5c" (X.509 Certificate Chain) Example . . . . . . . 44 Appendix B. "x5c" (X.509 Certificate Chain) Example . . . . . . . 42
Appendix C. Notes on implementing base64url encoding without Appendix C. Notes on implementing base64url encoding without
padding . . . . . . . . . . . . . . . . . . . . . . . 46 padding . . . . . . . . . . . . . . . . . . . . . . . 44
Appendix D. Negative Test Case for "crit" Header Parameter . . . 47 Appendix D. Negative Test Case for "crit" Header Parameter . . . 45
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 47 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 45
Appendix F. Document History . . . . . . . . . . . . . . . . . . 48 Appendix F. Document History . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction 1. Introduction
JSON Web Signature (JWS) is a means of representing content secured JSON Web Signature (JWS) is a means of representing content secured
with digital signatures or Message Authentication Codes (MACs) using with digital signatures or Message Authentication Codes (MACs) using
JavaScript Object Notation (JSON) [RFC4627] based data structures. JavaScript Object Notation (JSON) [RFC4627] based data structures.
The JWS cryptographic mechanisms provide integrity protection for The JWS cryptographic mechanisms provide integrity protection for
arbitrary sequences of octets. arbitrary sequences of octets.
Two closely related representations for JWS objects are defined. The Two closely related representations for JWS objects are defined. The
skipping to change at page 6, line 33 skipping to change at page 6, line 33
3. JSON Web Signature (JWS) Overview 3. JSON Web Signature (JWS) Overview
JWS represents digitally signed or MACed content using JSON data JWS represents digitally signed or MACed content using JSON data
structures and base64url encoding. Three values are represented in a structures and base64url encoding. Three values are represented in a
JWS: the JWS Header, the JWS Payload, and the JWS Signature. In the JWS: the JWS Header, the JWS Payload, and the JWS Signature. In the
Compact Serialization, the three values are base64url-encoded for Compact Serialization, the three values are base64url-encoded for
transmission, and represented as the concatenation of the encoded transmission, and represented as the concatenation of the encoded
strings in that order, with the three strings being separated by two strings in that order, with the three strings being separated by two
period ('.') characters. A JSON Serialization for this information period ('.') characters. A JSON Serialization for this information
is also defined in Section 8. is also defined in Section 7.2.
The JWS Header describes the signature or MAC method and parameters The JWS Header describes the signature or MAC method and parameters
employed. The JWS Payload is the message content to be secured. The employed. The JWS Payload is the message content to be secured. The
JWS Signature ensures the integrity of both the JWS Protected Header JWS Signature ensures the integrity of both the JWS Protected Header
and the JWS Payload. and the JWS Payload.
3.1. Example JWS 3.1. Example JWS
The following example JWS Header declares that the encoded object is The following example JWS Header declares that the encoded object is
a JSON Web Token (JWT) [JWT] and the JWS Header and the JWS Payload a JSON Web Token (JWT) [JWT] and the JWS Header and the JWS Payload
skipping to change at page 7, line 15 skipping to change at page 7, line 15
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
The following is an example of a JSON object that can be used as a The following is an example of a JSON object that can be used as a
JWS Payload. (Note that the payload can be any content, and need not JWS Payload. (Note that the payload can be any content, and need not
be a representation of a JSON object.) be a representation of a JSON object.)
{"iss":"joe", {"iss":"joe",
"exp":1300819380, "exp":1300819380,
"http://example.com/is_root":true} "http://example.com/is_root":true}
Base64url encoding the octets of the UTF-8 representation of the JSON The following octet sequence, which is the UTF-8 representation of
object yields the following Encoded JWS Payload (with line breaks for the JSON object above, is the JWS Payload:
display purposes only):
[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]
Base64url encoding the JWS Payload yields this Encoded JWS Payload
(with line breaks for display purposes only):
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
Computing the HMAC of the octets of the ASCII [USASCII] Computing the HMAC of the octets of the ASCII [USASCII]
representation of the JWS Signing Input (the concatenation of the representation of the JWS Signing Input (the concatenation of the
Encoded JWS Header, a period ('.') character, and the Encoded JWS Encoded JWS Header, a period ('.') character, and the Encoded JWS
Payload) with the HMAC SHA-256 algorithm using the key specified in Payload) with the HMAC SHA-256 algorithm using the key specified in
Appendix A.1 and base64url encoding the result yields this Encoded Appendix A.1 and base64url encoding the result yields this Encoded
JWS Signature value: JWS Signature value:
skipping to change at page 7, line 48 skipping to change at page 8, line 7
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
. .
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
This computation is illustrated in more detail in Appendix A.1. See This computation is illustrated in more detail in Appendix A.1. See
Appendix A for additional examples. Appendix A for additional examples.
4. JWS Header 4. JWS Header
The members of the JSON object(s) represented by the JWS Header The members of the JSON object(s) representing the JWS Header
describe the digital signature or MAC applied to the Encoded JWS describe the digital signature or MAC applied to the Encoded JWS
Header and the Encoded JWS Payload and optionally additional Header and the Encoded JWS Payload and optionally additional
properties of the JWS. The Header Parameter Names within the JWS properties of the JWS. The Header Parameter Names within the JWS
Header MUST be unique; JWSs with duplicate Header Parameter Names Header MUST be unique; receipients MUST either reject JWSs with
MUST be rejected. 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].
Implementations are required to understand the specific header Implementations are required to understand the specific header
parameters defined by this specification that are designated as "MUST parameters defined by this specification that are designated as "MUST
be understood" and process them in the manner defined in this be understood" and process them in the manner defined in this
specification. All other header parameters defined by this specification. All other header parameters defined by this
specification that are not so designated MUST be ignored when not specification that are not so designated MUST be ignored when not
understood. Unless listed as a critical header parameter, per understood. Unless listed as a critical header parameter, per
Section 4.1.10, all other header parameters MUST be ignored when not Section 4.1.10, all header parameters not defined by this
understood. specification MUST be ignored when not understood.
There are three classes of Header Parameter Names: Reserved Header There are three classes of Header Parameter Names: Reserved Header
Parameter Names, Public Header Parameter Names, and Private Header Parameter Names, Public Header Parameter Names, and Private Header
Parameter Names. Parameter Names.
4.1. Reserved Header Parameter Names 4.1. Reserved Header Parameter Names
The following Header Parameter Names are reserved with meanings as The following Header Parameter Names are reserved with meanings as
defined below. All the names are short because a core goal of this defined below. All the names are short because a core goal of this
specification is for the resulting representations using the JWS specification is for the resulting representations using the JWS
Compact Serialization to be compact. Compact Serialization to be compact.
Additional reserved Header Parameter Names can be defined via the Additional reserved Header Parameter Names can be defined via the
IANA JSON Web Signature and Encryption Header Parameters registry IANA JSON Web Signature and Encryption Header Parameters registry
Section 10.1. As indicated by the common registry, JWSs and JWEs Section 8.1. As indicated by the common registry, JWSs and JWEs
share a common header parameter space; when a parameter is used by share a common header parameter space; when a parameter is used by
both specifications, its usage must be compatible between the both specifications, its usage must be compatible between the
specifications. specifications.
4.1.1. "alg" (Algorithm) Header Parameter 4.1.1. "alg" (Algorithm) Header Parameter
The "alg" (algorithm) header parameter identifies the cryptographic The "alg" (algorithm) header parameter identifies a cryptographic
algorithm used to secure the JWS. The algorithm specified by the algorithm used to secure the JWS. The recipient MUST reject the JWS
"alg" value MUST be supported by the implementation and there MUST be if the "alg" value does not represent a supported algorithm, or if
a key for use with that algorithm associated with the party that there is not a key for use with that algorithm associated with the
digitally signed or MACed the content or the JWS MUST be rejected. party that digitally signed or MACed the content. "alg" values SHOULD
"alg" values SHOULD either be registered in the IANA JSON Web either be registered in the IANA JSON Web Signature and Encryption
Signature and Encryption Algorithms registry [JWA] or be a value that Algorithms registry [JWA] or be a value that contains a Collision
contains a Collision Resistant Namespace. The "alg" value is a case Resistant Namespace. The "alg" value is a case sensitive string
sensitive string containing a StringOrURI value. Use of this header containing a StringOrURI value. Use of this header parameter is
parameter is REQUIRED. This header parameter MUST be understood by REQUIRED. This header parameter MUST be understood by
implementations. implementations.
A list of defined "alg" values can be found in the IANA JSON Web A list of defined "alg" values can be found in the IANA JSON Web
Signature and Encryption Algorithms registry [JWA]; the initial Signature and Encryption Algorithms registry [JWA]; the initial
contents of this registry are the values defined in Section 3.1 of contents of this registry are the values defined in Section 3.1 of
the JSON Web Algorithms (JWA) [JWA] specification. the JSON Web Algorithms (JWA) [JWA] specification.
4.1.2. "jku" (JWK Set URL) Header Parameter 4.1.2. "jku" (JWK Set URL) Header Parameter
The "jku" (JWK Set URL) header parameter is a URI [RFC3986] that 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 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 which corresponds to the key used to digitally sign the JWS. The
keys MUST be encoded as a JSON Web Key Set (JWK Set) [JWK]. The keys MUST be encoded as a JSON Web Key Set (JWK Set) [JWK]. The
protocol used to acquire the resource MUST provide integrity protocol used to acquire the resource MUST provide integrity
protection; an HTTP GET request to retrieve the certificate MUST use protection; an HTTP GET request to retrieve the JWK Set MUST use TLS
TLS [RFC2818] [RFC5246]; the identity of the server MUST be [RFC2818] [RFC5246]; the identity of the server MUST be validated, as
validated, as per Section 3.1 of HTTP Over TLS [RFC2818]. Use of per Section 3.1 of HTTP Over TLS [RFC2818]. Use of this header
this header parameter is OPTIONAL. parameter is OPTIONAL.
4.1.3. "jwk" (JSON Web Key) Header Parameter 4.1.3. "jwk" (JSON Web Key) Header Parameter
The "jwk" (JSON Web Key) header parameter is the public key that 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 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 represented as a JSON Web Key [JWK]. Use of this header parameter is
OPTIONAL. OPTIONAL.
4.1.4. "x5u" (X.509 URL) Header Parameter 4.1.4. "x5u" (X.509 URL) Header Parameter
skipping to change at page 10, line 6 skipping to change at page 10, line 19
encoding of the X.509 certificate [RFC5280] corresponding to the key encoding of the X.509 certificate [RFC5280] corresponding to the key
used to digitally sign the JWS. Use of this header parameter is used to digitally sign the JWS. Use of this header parameter is
OPTIONAL. OPTIONAL.
If, in the future, certificate thumbprints need to be computed using If, in the future, certificate thumbprints need to be computed using
hash functions other than SHA-1, it is suggested that additional hash functions other than SHA-1, it is suggested that additional
related header parameters be defined for that purpose. For example, related header parameters be defined for that purpose. For example,
it is suggested that a new "x5t#S256" (X.509 Certificate Thumbprint it is suggested that a new "x5t#S256" (X.509 Certificate Thumbprint
using SHA-256) header parameter could be defined by registering it in using SHA-256) header parameter could be defined by registering it in
the IANA JSON Web Signature and Encryption Header Parameters registry the IANA JSON Web Signature and Encryption Header Parameters registry
Section 10.1. Section 8.1.
4.1.6. "x5c" (X.509 Certificate Chain) Header Parameter 4.1.6. "x5c" (X.509 Certificate Chain) Header Parameter
The "x5c" (X.509 Certificate Chain) header parameter contains the The "x5c" (X.509 Certificate Chain) header parameter contains the
X.509 public key certificate or certificate chain [RFC5280] X.509 public key certificate or certificate chain [RFC5280]
corresponding to the key used to digitally sign the JWS. The corresponding to the key used to digitally sign the JWS. The
certificate or certificate chain is represented as a JSON array of certificate or certificate chain is represented as a JSON array of
certificate value strings. Each string in the array is a base64 certificate value strings. Each string in the array is a base64
encoded ([RFC4648] Section 4 -- not base64url encoded) DER encoded ([RFC4648] Section 4 -- not base64url encoded) DER
[ITU.X690.1994] PKIX certificate value. The certificate containing [ITU.X690.1994] PKIX certificate value. The certificate containing
skipping to change at page 10, line 41 skipping to change at page 11, line 7
recipient be unable to locate a key corresponding to the "kid" value, recipient be unable to locate a key corresponding to the "kid" value,
they SHOULD treat that condition as an error. The interpretation of they SHOULD treat that condition as an error. The interpretation of
the "kid" value is unspecified. Its value MUST be a string. Use of the "kid" value is unspecified. Its value MUST be a string. Use of
this header parameter is OPTIONAL. this header parameter is OPTIONAL.
When used with a JWK, the "kid" value can be used to match a JWK When used with a JWK, the "kid" value can be used to match a JWK
"kid" parameter value. "kid" parameter value.
4.1.8. "typ" (Type) Header Parameter 4.1.8. "typ" (Type) Header Parameter
The "typ" (type) header parameter is used to declare the type of this The "typ" (type) header parameter MAY be used to declare the type of
object. The type value "JWS" is used to indicate that this object is this complete JWS object in an application-specific manner in
a JWS using the JWS Compact Serialization. The type value "JWS+JSON" contexts where this is useful to the application. This parameter has
is used to indicate that this object is a JWS using the JWS JSON no effect upon the JWS processing. The type value "JOSE" MAY be used
Serialization. Other type values MAY be used, and if not understood, to indicate that this object is a JWS or JWE using the JWS Compact
SHOULD be ignored. The "typ" value is a case sensitive string. Use Serialization or the JWE Compact Serialization. The type value
of this header parameter is OPTIONAL. "JOSE+JSON" MAY be used to indicate that this object is a JWS or JWE
using the JWS JSON Serialization or the JWE JSON Serialization.
Other type values MAY be used, and if not understood, SHOULD be
ignored. The "typ" value is a case sensitive string. Use of this
header parameter is OPTIONAL.
MIME Media Type [RFC2046] values MAY be used as "typ" values. MIME Media Type [RFC2046] values MAY be used as "typ" values.
"typ" values SHOULD either be registered in the IANA JSON Web "typ" values SHOULD either be registered in the IANA JSON Web
Signature and Encryption Type Values registry Section 10.2 or be a Signature and Encryption Type Values registry Section 8.2 or be a
value that contains a Collision Resistant Namespace. value that contains a Collision Resistant Namespace.
4.1.9. "cty" (Content Type) Header Parameter 4.1.9. "cty" (Content Type) Header Parameter
The "cty" (content type) header parameter is used to declare the type The "cty" (content type) header parameter MAY be used to declare the
of the secured content (the Payload). For example, the JSON Web type of the secured content (the payload) in an application-specific
Token (JWT) [JWT] specification uses the "cty" value "JWT" to manner in contexts where this is useful to the application. This
indicate that the Payload is a JSON Web Token (JWT). Content type parameter has no effect upon the JWS processing. Content type values
values that are not understood SHOULD be ignored. The "cty" value is that are not understood SHOULD be ignored. The "cty" value is a case
a case sensitive string. Use of this header parameter is OPTIONAL. sensitive string. Use of this header parameter is OPTIONAL.
The values used for the "cty" header parameter come from the same The values used for the "cty" header parameter come from the same
value space as the "typ" header parameter, with the same rules value space as the "typ" header parameter, with the same rules
applying. applying.
4.1.10. "crit" (Critical) Header Parameter 4.1.10. "crit" (Critical) Header Parameter
The "crit" (critical) header parameter indicates that extensions to The "crit" (critical) header parameter indicates that extensions to
[[ this specification ]] are being used that MUST be understood and [[ this specification ]] are being used that MUST be understood and
processed. Its value is an array listing the header parameter names processed. Its value is an array listing the header parameter names
defined by those extensions that are used in the JWS Header. If any defined by those extensions that are used in the JWS Header. If any
of the listed extension header parameters are not understood and of the listed extension header parameters are not understood and
supported by the receiver, it MUST reject the JWS. Senders MUST NOT supported by the receiver, it MUST reject the JWS. Senders MUST NOT
include header parameter names defined by [[ this specification ]], include header parameter names defined by [[ this specification ]] or
duplicate names, or names that do not occur as header parameter names by [JWA] for use with JWS, duplicate names, or names that do not
within the JWS Header in the "crit" list. Senders MUST not use the occur as header parameter names within the JWS Header in the "crit"
empty list "[]" as the "crit" value. Recipients MAY reject the JWS list. Senders MUST not use the empty list "[]" as the "crit" value.
if the critical list contains any header parameter names defined by Recipients MAY reject the JWS if the critical list contains any
[[ this specification ]] or any other constraints on its use are header parameter names defined by [[ this specification ]] or by
[JWA] for use with JWS, or any other constraints on its use are
violated. This header parameter MUST be integrity protected, and violated. This header parameter MUST be integrity protected, and
therefore MUST occur only with the JWS Protected Header, when used. therefore MUST occur only with the JWS Protected Header, when used.
Use of this header parameter is OPTIONAL. This header parameter MUST Use of this header parameter is OPTIONAL. This header parameter MUST
be understood by implementations. be understood by implementations.
An example use, along with a hypothetical "exp" (expiration-time) An example use, along with a hypothetical "exp" (expiration-time)
field is: field is:
{"alg":"ES256", {"alg":"ES256",
"crit":["exp"], "crit":["exp"],
"exp":1363284000 "exp":1363284000
} }
4.2. Public Header Parameter Names 4.2. Public Header Parameter Names
Additional Header Parameter Names can be defined by those using JWSs. Additional Header Parameter Names can be defined by those using JWSs.
However, in order to prevent collisions, any new Header Parameter However, in order to prevent collisions, any new Header Parameter
Name SHOULD either be registered in the IANA JSON Web Signature and Name SHOULD either be registered in the IANA JSON Web Signature and
Encryption Header Parameters registry Section 10.1 or be a Public Encryption Header Parameters registry Section 8.1 or be a Public
Name: a value that contains a Collision Resistant Namespace. In each Name: a value that contains a Collision Resistant Namespace. In each
case, the definer of the name or value needs to take reasonable 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 precautions to make sure they are in control of the part of the
namespace they use to define the Header Parameter Name. namespace they use to define the Header Parameter Name.
New header parameters should be introduced sparingly, as they can New header parameters should be introduced sparingly, as they can
result in non-interoperable JWSs. result in non-interoperable JWSs.
4.3. Private Header Parameter Names 4.3. Private Header Parameter Names
skipping to change at page 12, line 42 skipping to change at page 13, line 13
becomes the Encoded JWS Payload. becomes the Encoded JWS Payload.
3. Create a JWS Header containing the desired set of header 3. Create a JWS Header containing the desired set of header
parameters. Note that white space is explicitly allowed in the parameters. Note that white space is explicitly allowed in the
representation and no canonicalization need be performed before representation and no canonicalization need be performed before
encoding. encoding.
4. Base64url encode the octets of the UTF-8 representation of the 4. Base64url encode the octets of the UTF-8 representation of the
JWS Protected Header to create the Encoded JWS Header. If the JWS Protected Header to create the Encoded JWS Header. If the
JWS Protected Header is not present (which can only happen when JWS Protected Header is not present (which can only happen when
using the JWS JSON Serialization), let the Encoded JWS Header be using the JWS JSON Serialization and no "protected" member is
the empty string. present), let the Encoded JWS Header be the empty string.
5. Compute the JWS Signature in the manner defined for the 5. Compute the JWS Signature in the manner defined for the
particular algorithm being used over the JWS Signing Input (the particular algorithm being used over the JWS Signing Input (the
concatenation of the Encoded JWS Header, a period ('.') concatenation of the Encoded JWS Header, a period ('.')
character, and the Encoded JWS Payload). The "alg" (algorithm) character, and the Encoded JWS Payload). The "alg" (algorithm)
header parameter MUST be present in the JWS Header, with the header parameter MUST be present in the JWS Header, with the
algorithm value accurately representing the algorithm used to algorithm value accurately representing the algorithm used to
construct the JWS Signature. construct the JWS Signature.
6. Base64url encode the representation of the JWS Signature to 6. Base64url encode the representation of the JWS Signature to
skipping to change at page 13, line 21 skipping to change at page 13, line 39
representations. representations.
8. If the JWS JSON Serialization is being used, repeat this process 8. If the JWS JSON Serialization is being used, repeat this process
for each digital signature or MAC value being applied. for each digital signature or MAC value being applied.
9. Create the desired serialized output. The JWS Compact 9. Create the desired serialized output. The JWS Compact
Serialization of this result is the concatenation of the Encoded Serialization of this result is the concatenation of the Encoded
JWS Header, the Encoded JWS Payload, and the Encoded JWS JWS Header, the Encoded JWS Payload, and the Encoded JWS
Signature in that order, with the three strings being separated Signature in that order, with the three strings being separated
by two period ('.') characters. The JWS JSON Serialization is by two period ('.') characters. The JWS JSON Serialization is
described in Section 8. described in Section 7.2.
5.2. Message Signature or MAC Validation 5.2. Message Signature or MAC Validation
When validating a JWS, the following steps MUST be taken. The order When validating a JWS, the following steps MUST be taken. The order
of the steps is not significant in cases where there are no of the steps is not significant in cases where there are no
dependencies between the inputs and outputs of the steps. If any of dependencies between the inputs and outputs of the steps. If any of
the listed steps fails, then the JWS MUST be rejected. the listed steps fails, then the JWS MUST be rejected.
1. Parse the serialized input to determine the values of the JWS 1. Parse the serialized input to determine the values of the JWS
Header, the Encoded JWS Payload, and the Encoded JWS Signature. Header, the Encoded JWS Payload, and the Encoded JWS Signature.
When using the JWS Compact Serialization, the Encoded JWS When using the JWS Compact Serialization, the Encoded JWS
Header, the Encoded JWS Payload, and the Encoded JWS Signature Header, the Encoded JWS Payload, and the Encoded JWS Signature
are represented as text strings in that order, separated by two are represented as text strings in that order, separated by two
period ('.') characters. The JWS JSON Serialization is period ('.') characters. The JWS JSON Serialization is
described in Section 8. described in Section 7.2.
2. The Encoded JWS Header MUST be successfully base64url decoded 2. The Encoded JWS Header MUST be successfully base64url decoded
following the restriction given in this specification that no following the restriction given in this specification that no
padding characters have been used. padding characters have been used.
3. Let the JWS Protected Header value be the result of base64url 3. Let the JWS Protected Header value be the result of base64url
decoding the Encoded JWS Header. decoding the Encoded JWS Header.
4. The resulting JWS Protected Header MUST be a completely valid 4. The resulting JWS Protected Header MUST be a completely valid
JSON object conforming to RFC 4627 [RFC4627]. JSON object conforming to RFC 4627 [RFC4627].
skipping to change at page 15, line 17 skipping to change at page 15, line 33
3. Unicode Normalization [USA15] MUST NOT be applied at any point to 3. Unicode Normalization [USA15] MUST NOT be applied at any point to
either the JSON string or to the string it is to be compared either the JSON string or to the string it is to be compared
against. against.
4. Comparisons between the two strings MUST be performed as a 4. Comparisons between the two strings MUST be performed as a
Unicode code point to code point equality comparison. (Note that Unicode code point to code point equality comparison. (Note that
values that originally used different Unicode encodings (UTF-8, values that originally used different Unicode encodings (UTF-8,
UTF-16, etc.) may result in the same code point values.) UTF-16, etc.) may result in the same code point values.)
Also, see the JSON security considerations in Section 11.2 and the Also, see the JSON security considerations in Section 9.2 and the
Unicode security considerations in Section 11.3. Unicode security considerations in Section 9.3.
6. Cryptographic Algorithms
JWS uses cryptographic algorithms to digitally sign or MAC the JWS
Protected Header and the JWS Payload. The JSON Web Algorithms (JWA)
[JWA] specification describes a set of cryptographic algorithms and
identifiers to be used with this specification. Specifically,
Section 3.1 specifies a set of "alg" (algorithm) header parameter
values intended for use this specification. It also describes the
semantics and operations that are specific to these algorithms.
7. Key Identification 6. Key Identification
It is necessary for the recipient of a JWS to be able to determine 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 that was employed for the digital signature or MAC operation.
The key employed can be identified using the Header Parameter methods The key employed can be identified using the Header Parameter methods
described in Section 4.1 or can be identified using methods that are described in Section 4.1 or can be identified using methods that are
outside the scope of this specification. Specifically, the Header outside the scope of this specification. Specifically, the Header
Parameters "jku", "jwk", "x5u", "x5t", "x5c", and "kid" can be used Parameters "jku", "jwk", "x5u", "x5t", "x5c", and "kid" can be used
to identify the key used. The sender SHOULD include sufficient to identify the key used. The sender SHOULD include sufficient
information in the Header Parameters to identify the key used, unless information in the Header Parameters to identify the key used, unless
the application uses another means or convention to determine the key the application uses another means or convention to determine the key
used. Recipients MUST reject the input when the algorithm used used. Recipients MUST reject the input when the algorithm used
requires a key (which is true of all algorithms except for "none") requires a key (which is true of all algorithms except for "none")
and the key used cannot be determined. and the key used cannot be determined.
8. JWS JSON Serialization 7. Serializations
JWS objects use one of two serializations, the JWS Compact
Serialization or the JWS JSON Serialization. The JWS Compact
Serialization is mandatory to implement. Implementation of the JWS
JSON Serialization is OPTIONAL.
7.1. JWS Compact Serialization
The JWS Compact Serialization represents digitally signed or MACed
content as a compact URL-safe string. This string is the
concatenation of the Encoded JWS Header, the Encoded JWS Payload, and
the Encoded JWS Signature in that order, with the three strings being
separated by two period ('.') characters. Only one signature/MAC is
supported by the JWS Compact Serialization.
7.2. JWS JSON Serialization
The JWS JSON Serialization represents digitally signed or MACed The JWS JSON Serialization represents digitally signed or MACed
content as a JSON object. Unlike the JWS Compact Serialization, content as a JSON object. Unlike the JWS Compact Serialization,
content using the JWS JSON Serialization can be secured with more content using the JWS JSON Serialization can be secured with more
than one digital signature and/or MAC value. than one digital signature and/or MAC value.
The representation is closely related to that used in the JWS Compact The representation is closely related to that used in the JWS Compact
Serialization, with the following differences for the JWS JSON Serialization, with the following differences for the JWS JSON
Serialization: Serialization:
skipping to change at page 18, line 6 skipping to change at page 18, line 28
property that each Encoded JWS Signature value in the "signatures" property that each Encoded JWS Signature value in the "signatures"
array is identical to the value that would have been computed for the array is identical to the value that would have been computed for the
same parameter in the JWS Compact Serialization, provided that the same parameter in the JWS Compact Serialization, provided that the
Encoded JWS Header value (which represents the integrity-protected Encoded JWS Header value (which represents the integrity-protected
header parameter values) matches that used in the JWS Compact header parameter values) matches that used in the JWS Compact
Serialization. Serialization.
See Appendix A.6 for an example of computing a JWS using the JWS JSON See Appendix A.6 for an example of computing a JWS using the JWS JSON
Serialization. Serialization.
9. Implementation Considerations 8. IANA Considerations
The JWS Compact Serialization is mandatory to implement.
Implementation of the JWS JSON Serialization is OPTIONAL.
10. IANA Considerations
The following registration procedure is used for all the registries The following registration procedure is used for all the registries
established by this specification. established by this specification.
Values are registered with a Specification Required [RFC5226] after a Values are registered with a Specification Required [RFC5226] after a
two-week review period on the [TBD]@ietf.org mailing list, on the two-week review period on the [TBD]@ietf.org mailing list, on the
advice of one or more Designated Experts. However, to allow for the advice of one or more Designated Experts. However, to allow for the
allocation of values prior to publication, the Designated Expert(s) allocation of values prior to publication, the Designated Expert(s)
may approve registration once they are satisfied that such a may approve registration once they are satisfied that such a
specification will be published. specification will be published.
skipping to change at page 18, line 39 skipping to change at page 19, line 9
Within the review period, the Designated Expert(s) will either Within the review period, the Designated Expert(s) will either
approve or deny the registration request, communicating this decision approve or deny the registration request, communicating this decision
to the review list and IANA. Denials should include an explanation to the review list and IANA. Denials should include an explanation
and, if applicable, suggestions as to how to make the request and, if applicable, suggestions as to how to make the request
successful. successful.
IANA must only accept registry updates from the Designated Expert(s) IANA must only accept registry updates from the Designated Expert(s)
and should direct all requests for registration to the review mailing and should direct all requests for registration to the review mailing
list. list.
10.1. JSON Web Signature and Encryption Header Parameters Registry 8.1. JSON Web Signature and Encryption Header Parameters Registry
This specification establishes the IANA JSON Web Signature and This specification establishes the IANA JSON Web Signature and
Encryption Header Parameters registry for reserved JWS and JWE Header Encryption Header Parameters registry for reserved JWS and JWE Header
Parameter Names. The registry records the reserved Header Parameter Parameter Names. The registry records the reserved Header Parameter
Name and a reference to the specification that defines it. The same Name and a reference to the specification that defines it. The same
Header Parameter Name MAY be registered multiple times, provided that Header Parameter Name MAY be registered multiple times, provided that
the parameter usage is compatible between the specifications. the parameter usage is compatible between the specifications.
Different registrations of the same Header Parameter Name will Different registrations of the same Header Parameter Name will
typically use different Header Parameter Usage Location(s) values. typically use different Header Parameter Usage Location(s) values.
10.1.1. Registration Template 8.1.1. Registration Template
Header Parameter Name: Header Parameter Name:
The name requested (e.g., "example"). This name is case The name requested (e.g., "example"). This name is case
sensitive. Names that match other registered names in a case sensitive. Names that match other registered names in a case
insensitive manner SHOULD NOT be accepted. insensitive manner SHOULD NOT be accepted.
Header Parameter Usage Location(s): Header Parameter Usage Location(s):
The header parameter usage locations, which should be one or more The header parameter usage locations, which should be one or more
of the values "JWS" or "JWE". of the values "JWS" or "JWE".
skipping to change at page 19, line 27 skipping to change at page 19, line 42
For Standards Track RFCs, state "IETF". For others, give the name For Standards Track RFCs, state "IETF". For others, give the name
of the responsible party. Other details (e.g., postal address, of the responsible party. Other details (e.g., postal address,
email address, home page URI) may also be included. email address, home page URI) may also be included.
Specification Document(s): Specification Document(s):
Reference to the document(s) that specify the parameter, Reference to the document(s) that specify the parameter,
preferably including URI(s) that can be used to retrieve copies of preferably including URI(s) that can be used to retrieve copies of
the document(s). An indication of the relevant sections may also the document(s). An indication of the relevant sections may also
be included but is not required. be included but is not required.
10.1.2. Initial Registry Contents 8.1.2. Initial Registry Contents
This specification registers the Header Parameter Names defined in This specification registers the Header Parameter Names defined in
Section 4.1 in this registry. Section 4.1 in this registry.
o Header Parameter Name: "alg" o Header Parameter Name: "alg"
o Header Parameter Usage Location(s): JWS o Header Parameter Usage Location(s): JWS
o Change Controller: IETF o Change Controller: IETF
o Specification Document(s): Section 4.1.1 of [[ this document ]] o Specification Document(s): Section 4.1.1 of [[ this document ]]
o Header Parameter Name: "jku" o Header Parameter Name: "jku"
o Header Parameter Usage Location(s): JWS o Header Parameter Usage Location(s): JWS
o Change Controller: IETF o Change Controller: IETF
o Specification Document(s): Section 4.1.2 of [[ this document ]] o Specification Document(s): Section 4.1.2 of [[ this document ]]
o Header Parameter Name: "jwk" o Header Parameter Name: "jwk"
o Header Parameter Usage Location(s): JWS o Header Parameter Usage Location(s): JWS
o Change Controller: IETF o Change Controller: IETF
o Specification document(s): Section 4.1.3 of [[ this document ]] o Specification document(s): Section 4.1.3 of [[ this document ]]
skipping to change at page 20, line 34 skipping to change at page 21, line 5
o Header Parameter Name: "cty" o Header Parameter Name: "cty"
o Header Parameter Usage Location(s): JWS o Header Parameter Usage Location(s): JWS
o Change Controller: IETF o Change Controller: IETF
o Specification Document(s): Section 4.1.9 of [[ this document ]] o Specification Document(s): Section 4.1.9 of [[ this document ]]
o Header Parameter Name: "crit" o Header Parameter Name: "crit"
o Header Parameter Usage Location(s): JWS o Header Parameter Usage Location(s): JWS
o Change Controller: IETF o Change Controller: IETF
o Specification Document(s): Section 4.1.10 of [[ this document ]] o Specification Document(s): Section 4.1.10 of [[ this document ]]
10.2. JSON Web Signature and Encryption Type Values Registry 8.2. JSON Web Signature and Encryption Type Values Registry
This specification establishes the IANA JSON Web Signature and This specification establishes the IANA JSON Web Signature and
Encryption Type Values registry for values of the JWS and JWE "typ" Encryption Type Values registry for values of the JWS and JWE "typ"
(type) header parameter. It is RECOMMENDED that all registered "typ" (type) header parameter. It is RECOMMENDED that all registered "typ"
values also include a MIME Media Type [RFC2046] value that the values also include a MIME Media Type [RFC2046] value that the
registered value is a short name for. The registry records the "typ" registered value is a short name for. The registry records the "typ"
value, the MIME type value that it is an abbreviation for (if any), value, the MIME type value that it is an abbreviation for (if any),
and a reference to the specification that defines it. and a reference to the specification that defines it.
MIME Media Type [RFC2046] values MUST NOT be directly registered as MIME Media Type [RFC2046] values MUST NOT be directly registered as
new "typ" values; rather, new "typ" values MAY be registered as short new "typ" values; rather, new "typ" values MAY be registered as short
names for MIME types. names for MIME types.
10.2.1. Registration Template 8.2.1. Registration Template
"typ" Header Parameter Value: "typ" Header Parameter Value:
The name requested (e.g., "example"). This name is case The name requested (e.g., "example"). This name is case
sensitive. Names that match other registered names in a case sensitive. Names that match other registered names in a case
insensitive manner SHOULD NOT be accepted. insensitive manner SHOULD NOT be accepted.
Abbreviation for MIME Type: Abbreviation for MIME Type:
The MIME type that this name is an abbreviation for (e.g., The MIME type that this name is an abbreviation for (e.g.,
"application/example"). "application/example").
Change Controller: Change Controller:
For Standards Track RFCs, state "IETF". For others, give the name For Standards Track RFCs, state "IETF". For others, give the name
of the responsible party. Other details (e.g., postal address, of the responsible party. Other details (e.g., postal address,
email address, home page URI) may also be included. email address, home page URI) may also be included.
Specification Document(s): Specification Document(s):
Reference to the document(s) that specify the parameter, Reference to the document(s) that specify the parameter,
preferably including URI(s) that can be used to retrieve copies of preferably including URI(s) that can be used to retrieve copies of
the document(s). An indication of the relevant sections may also the document(s). An indication of the relevant sections may also
be included but is not required. be included but is not required.
10.2.2. Initial Registry Contents 8.2.2. Initial Registry Contents
This specification registers the "JWS" and "JWS+JSON" type values in This specification registers the "JOSE" and "JOSE+JSON" type values
this registry: in this registry:
o "typ" Header Parameter Value: "JWS" o "typ" Header Parameter Value: "JOSE"
o Abbreviation for MIME type: application/jws o Abbreviation for MIME type: application/jose
o Change Controller: IETF o Change Controller: IETF
o Specification Document(s): Section 4.1.8 of [[ this document ]] o Specification Document(s): Section 4.1.8 of [[ this document ]]
o "typ" Header Parameter Value: "JOSE+JSON"
o "typ" Header Parameter Value: "JWS+JSON" o Abbreviation for MIME type: application/jose+json
o Abbreviation for MIME type: application/jws+json
o Change Controller: IETF o Change Controller: IETF
o Specification Document(s): Section 4.1.8 of [[ this document ]] o Specification Document(s): Section 4.1.8 of [[ this document ]]
10.3. Media Type Registration 8.3. Media Type Registration
10.3.1. Registry Contents 8.3.1. Registry Contents
This specification registers the "application/jws" and This specification registers the "application/jose" Media Type
"application/jws+json" Media Types [RFC2046] in the MIME Media Type [RFC2046] in the MIME Media Type registry [RFC4288], which can be
registry [RFC4288] to indicate, respectively, that the content is a used to indicate that the content is a JWS or JWE object using the
JWS using the JWS Compact Serialization or a JWS using the JWS JSON JWS Compact Serialization or the JWE Compact Serialization and the
Serialization. "application/jose+json" Media Type in the MIME Media Type registry,
which can be used to indicate that the content is a JWS or JWE object
using the JWS JSON Serialization or the JWE JSON Serialization.
o Type name: application o Type name: application
o Subtype name: jws o Subtype name: jose
o Required parameters: n/a o Required parameters: n/a
o Optional parameters: n/a o Optional parameters: n/a
o Encoding considerations: JWS values are encoded as a series of o Encoding considerations: application/jose values are encoded as a
base64url encoded values (some of which may be the empty string) series of base64url encoded values (some of which may be the empty
separated by period ('.') characters string) separated by period ('.') characters.
o Security considerations: See the Security Considerations section o Security considerations: See the Security Considerations section
of [[ this document ]] of [[ this document ]]
o Interoperability considerations: n/a o Interoperability considerations: n/a
o Published specification: [[ this document ]] o Published specification: [[ this document ]]
o Applications that use this media type: OpenID Connect, Mozilla o Applications that use this media type: OpenID Connect, Mozilla
Persona, Salesforce, Google, numerous others that use signed JWTs Persona, Salesforce, Google, numerous others that use signed JWTs
o Additional information: Magic number(s): n/a, File extension(s): o Additional information: Magic number(s): n/a, File extension(s):
n/a, Macintosh file type code(s): n/a n/a, Macintosh file type code(s): n/a
o Person & email address to contact for further information: Michael o Person & email address to contact for further information: Michael
B. Jones, mbj@microsoft.com B. Jones, mbj@microsoft.com
o Intended usage: COMMON o Intended usage: COMMON
o Restrictions on usage: none o Restrictions on usage: none
o Author: Michael B. Jones, mbj@microsoft.com o Author: Michael B. Jones, mbj@microsoft.com
o Change Controller: IETF o Change Controller: IETF
o Type name: application o Type name: application
o Subtype name: jws+json o Subtype name: jose+json
o Required parameters: n/a o Required parameters: n/a
o Optional parameters: n/a o Optional parameters: n/a
o Encoding considerations: application/jws+json values are o Encoding considerations: application/jose+json values are
represented as a JSON Object; UTF-8 encoding SHOULD be employed represented as a JSON Object; UTF-8 encoding SHOULD be employed
for the JSON object. for the JSON object.
o Security considerations: See the Security Considerations section o Security considerations: See the Security Considerations section
of [[ this document ]] of [[ this document ]]
o Interoperability considerations: n/a o Interoperability considerations: n/a
o Published specification: [[ this document ]] o Published specification: [[ this document ]]
o Applications that use this media type: TBD o Applications that use this media type: TBD
o Additional information: Magic number(s): n/a, File extension(s): o Additional information: Magic number(s): n/a, File extension(s):
n/a, Macintosh file type code(s): n/a n/a, Macintosh file type code(s): n/a
o Person & email address to contact for further information: Michael o Person & email address to contact for further information: Michael
B. Jones, mbj@microsoft.com B. Jones, mbj@microsoft.com
o Intended usage: COMMON o Intended usage: COMMON
skipping to change at page 22, line 46 skipping to change at page 23, line 19
o Applications that use this media type: TBD o Applications that use this media type: TBD
o Additional information: Magic number(s): n/a, File extension(s): o Additional information: Magic number(s): n/a, File extension(s):
n/a, Macintosh file type code(s): n/a n/a, Macintosh file type code(s): n/a
o Person & email address to contact for further information: Michael o Person & email address to contact for further information: Michael
B. Jones, mbj@microsoft.com B. Jones, mbj@microsoft.com
o Intended usage: COMMON o Intended usage: COMMON
o Restrictions on usage: none o Restrictions on usage: none
o Author: Michael B. Jones, mbj@microsoft.com o Author: Michael B. Jones, mbj@microsoft.com
o Change Controller: IETF o Change Controller: IETF
11. Security Considerations 9. Security Considerations
11.1. Cryptographic Security Considerations
9.1. Cryptographic Security Considerations
All of the security issues faced by any cryptographic application All of the security issues faced by any cryptographic application
must be faced by a JWS/JWE/JWK agent. Among these issues are must be faced by a JWS/JWE/JWK agent. Among these issues are
protecting the user's private and symmetric keys, preventing various protecting the user's private and symmetric keys, preventing various
attacks, and helping the user avoid mistakes such as inadvertently attacks, and helping the user avoid mistakes such as inadvertently
encrypting a message for the wrong recipient. The entire list of encrypting a message for the wrong recipient. The entire list of
security considerations is beyond the scope of this document, but security considerations is beyond the scope of this document, but
some significant concerns are listed here. some significant concerns are listed here.
All the security considerations in XML DSIG 2.0 All the security considerations in XML DSIG 2.0
skipping to change at page 24, line 9 skipping to change at page 24, line 27
certificate store used by the intended victim. A prerequisite to certificate store used by the intended victim. A prerequisite to
this attack succeeding is the attacker having write access to the this attack succeeding is the attacker having write access to the
intended victim's certificate store. intended victim's certificate store.
If, in the future, certificate thumbprints need to be computed using If, in the future, certificate thumbprints need to be computed using
hash functions other than SHA-1, it is suggested that additional hash functions other than SHA-1, it is suggested that additional
related header parameters be defined for that purpose. For example, related header parameters be defined for that purpose. For example,
it is suggested that a new "x5t#S256" (X.509 Certificate Thumbprint it is suggested that a new "x5t#S256" (X.509 Certificate Thumbprint
using SHA-256) header parameter could be defined and used. using SHA-256) header parameter could be defined and used.
11.2. JSON Security Considerations 9.2. JSON Security Considerations
Strict JSON validation is a security requirement. If malformed JSON Strict JSON validation is a security requirement. If malformed JSON
is received, then the intent of the sender is impossible to reliably is received, then the intent of the sender is impossible to reliably
discern. Ambiguous and potentially exploitable situations could discern. Ambiguous and potentially exploitable situations could
arise if the JSON parser used does not reject malformed JSON syntax. arise if the JSON parser used does not reject malformed JSON syntax.
Section 2.2 of the JavaScript Object Notation (JSON) specification Section 2.2 of the JavaScript Object Notation (JSON) specification
[RFC4627] states "The names within an object SHOULD be unique", [RFC4627] states "The names within an object SHOULD be unique",
whereas this specification states that "Header Parameter Names within whereas this specification states that "Header Parameter Names within
this object MUST be unique; JWSs with duplicate Header Parameter this object MUST be unique; receipients MUST either reject JWSs with
Names MUST be rejected". Thus, this specification requires that the duplicate Header Parameter Names or use a JSON parser that returns
Section 2.2 "SHOULD" be treated as a "MUST". Ambiguous and only the lexically last duplicate member name, as specified in
potentially exploitable situations could arise if the JSON parser Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAScript]".
used does not enforce the uniqueness of member names. Thus, this specification requires that the Section 2.2 "SHOULD" be
treated as a "MUST" by senders and that it be either treated as a
"MUST" or in the manner specfied in ECMAScript 5.1 by receivers.
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.
Some JSON parsers might not reject input that contains extra Some JSON parsers might not reject input that contains extra
significant characters after a valid input. For instance, the input significant characters after a valid input. For instance, the input
"{"tag":"value"}ABCD" contains a valid JSON object followed by the "{"tag":"value"}ABCD" contains a valid JSON object followed by the
extra characters "ABCD". Such input MUST be rejected in its extra characters "ABCD". Such input MUST be rejected in its
entirety. entirety.
11.3. Unicode Comparison Security Considerations 9.3. Unicode Comparison Security Considerations
Header Parameter Names and algorithm names are Unicode strings. For Header Parameter Names and algorithm names are Unicode strings. For
security reasons, the representations of these names must be compared security reasons, the representations of these names must be compared
verbatim after performing any escape processing (as per RFC 4627 verbatim after performing any escape processing (as per RFC 4627
[RFC4627], Section 2.5). This means, for instance, that these JSON [RFC4627], Section 2.5). This means, for instance, that these JSON
strings must compare as being equal ("sig", "\u0073ig"), whereas strings must compare as being equal ("sig", "\u0073ig"), whereas
these must all compare as being not equal to the first set or to each these must all compare as being not equal to the first set or to each
other ("SIG", "Sig", "si\u0047"). other ("SIG", "Sig", "si\u0047").
JSON strings can contain characters outside the Unicode Basic JSON strings can contain characters outside the Unicode Basic
Multilingual Plane. For instance, the G clef character (U+1D11E) may Multilingual Plane. For instance, the G clef character (U+1D11E) may
be represented in a JSON string as "\uD834\uDD1E". Ideally, JWS be represented in a JSON string as "\uD834\uDD1E". Ideally, JWS
implementations SHOULD ensure that characters outside the Basic implementations SHOULD ensure that characters outside the Basic
Multilingual Plane are preserved and compared correctly; Multilingual Plane are preserved and compared correctly;
alternatively, if this is not possible due to these characters alternatively, if this is not possible due to these characters
exercising limitations present in the underlying JSON implementation, exercising limitations present in the underlying JSON implementation,
then input containing them MUST be rejected. then input containing them MUST be rejected.
12. References 9.4. TLS Requirements
12.1. Normative References
Implementations MUST support TLS. Which 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, but has very limited actual
deployment, and might not be readily available in implementation
toolkits. TLS version 1.0 [RFC2246] is the most widely deployed
version, and will give the broadest interoperability.
To protect against information disclosure and tampering,
confidentiality protection MUST be applied using TLS with a
ciphersuite that provides confidentiality and integrity protection.
Whenever TLS is used, a TLS server certificate check MUST be
performed, per RFC 6125 [RFC6125].
10. References
10.1. Normative References
[ECMAScript]
Ecma International, "ECMAScript Language Specification,
5.1 Edition", ECMA 262, June 2011.
[ITU.X690.1994] [ITU.X690.1994]
International Telecommunications Union, "Information International Telecommunications Union, "Information
Technology - ASN.1 encoding rules: Specification of Basic Technology - ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)", ITU-T Recommendation Distinguished Encoding Rules (DER)", ITU-T Recommendation
X.690, 1994. X.690, 1994.
[JWA] Jones, M., "JSON Web Algorithms (JWA)", [JWA] Jones, M., "JSON Web Algorithms (JWA)",
draft-ietf-jose-json-web-algorithms (work in progress), draft-ietf-jose-json-web-algorithms (work in progress),
May 2013. July 2013.
[JWK] Jones, M., "JSON Web Key (JWK)", [JWK] Jones, M., "JSON Web Key (JWK)",
draft-ietf-jose-json-web-key (work in progress), May 2013. draft-ietf-jose-json-web-key (work in progress),
July 2013.
[RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic
Mail: Part I: Message Encryption and Authentication Mail: Part I: Message Encryption and Authentication
Procedures", RFC 1421, February 1993. Procedures", RFC 1421, February 1993.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996. November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
skipping to change at page 26, line 13 skipping to change at page 27, line 13
May 2008. May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[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, March 2011.
[USA15] Davis, M., Whistler, K., and M. Deurst, "Unicode [USA15] Davis, M., Whistler, K., and M. Deurst, "Unicode
Normalization Forms", Unicode Standard Annex 15, 09 2009. Normalization Forms", Unicode Standard Annex 15, 09 2009.
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
[W3C.WD-xmldsig-bestpractices-20110809] [W3C.WD-xmldsig-bestpractices-20110809]
Datta, P. and F. Hirsch, "XML Signature Best Practices", Datta, P. and F. Hirsch, "XML Signature Best Practices",
World Wide Web Consortium WD WD-xmldsig-bestpractices- World Wide Web Consortium WD WD-xmldsig-bestpractices-
20110809, August 2011, <http://www.w3.org/TR/2011/ 20110809, August 2011, <http://www.w3.org/TR/2011/
WD-xmldsig-bestpractices-20110809>. WD-xmldsig-bestpractices-20110809>.
12.2. Informative References 10.2. Informative References
[CanvasApp] [CanvasApp]
Facebook, "Canvas Applications", 2010. Facebook, "Canvas Applications", 2010.
[JSS] Bradley, J. and N. Sakimura (editor), "JSON Simple Sign", [JSS] Bradley, J. and N. Sakimura (editor), "JSON Simple Sign",
September 2010. September 2010.
[JWE] Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web [JWE] Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web
Encryption (JWE)", draft-ietf-jose-json-web-encryption Encryption (JWE)", draft-ietf-jose-json-web-encryption
(work in progress), May 2013. (work in progress), July 2013.
[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", draft-ietf-oauth-json-web-token (work in (JWT)", draft-ietf-oauth-json-web-token (work in
progress), May 2013. progress), July 2013.
[MagicSignatures] [MagicSignatures]
Panzer (editor), J., Laurie, B., and D. Balfanz, "Magic Panzer (editor), J., Laurie, B., and D. Balfanz, "Magic
Signatures", January 2011. Signatures", January 2011.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
July 2005. July 2005.
[W3C.CR-xmldsig-core2-20120124] [W3C.CR-xmldsig-core2-20120124]
skipping to change at page 28, line 6 skipping to change at page 29, line 12
The following octet sequence, which is the UTF-8 representation of The following octet sequence, which is the UTF-8 representation of
the JSON object above, is the JWS Payload: the JSON object above, is the JWS Payload:
[123, 34, 105, 115, 115, 34, 58, 34, 106, 111, 101, 34, 44, 13, 10, [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, 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, 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, 109, 112, 108, 101, 46, 99, 111, 109, 47, 105, 115, 95, 114, 111,
111, 116, 34, 58, 116, 114, 117, 101, 125] 111, 116, 34, 58, 116, 114, 117, 101, 125]
Base64url encoding the above yields the Encoded JWS Payload value Base64url encoding the JWS Payload yields this Encoded JWS Payload
(with line breaks for display purposes only): value (with line breaks for display purposes only):
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
Concatenating the Encoded JWS Header, a period ('.') character, and Concatenating the Encoded JWS Header, a period ('.') character, and
the Encoded JWS Payload yields this JWS Signing Input value (with the Encoded JWS Payload yields this JWS Signing Input value (with
line breaks for display purposes only): line breaks for display purposes only):
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
. .
skipping to change at page 28, line 34 skipping to change at page 29, line 40
[101, 121, 74, 48, 101, 88, 65, 105, 79, 105, 74, 75, 86, 49, 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, 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, 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, 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, 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, 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, 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, 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] 106, 112, 48, 99, 110, 86, 108, 102, 81]
HMACs are generated using keys. This example uses the key HMACs are generated using keys. This example uses the symmetric key
represented by the following octet sequence: represented in JSON Web Key [JWK] format below (with line breaks for
display purposes only):
[3, 35, 53, 75, 43, 15, 165, 188, 131, 126, 6, 101, 119, 123, 166, {"kty":"oct",
143, 90, 179, 40, 230, 240, 84, 201, 40, 169, 15, 132, 178, 210, 80, "k":"AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75
46, 191, 211, 251, 90, 146, 210, 6, 71, 239, 150, 138, 180, 195, 119, aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow"
98, 61, 34, 61, 46, 33, 114, 5, 46, 79, 8, 192, 205, 154, 245, 103, }
208, 128, 163]
Running the HMAC SHA-256 algorithm on the octets of the ASCII Running the HMAC SHA-256 algorithm on the octets of the ASCII
representation of the JWS Signing Input with this key yields the representation of the JWS Signing Input with this key yields this
following octet sequence: octet sequence:
[116, 24, 223, 180, 151, 153, 224, 37, 79, 250, 96, 125, 216, 173, [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, 187, 186, 22, 212, 37, 77, 105, 214, 191, 240, 91, 88, 5, 88, 83,
132, 141, 121] 132, 141, 121]
Base64url encoding the above HMAC output yields the Encoded JWS Base64url encoding the above HMAC output yields this Encoded JWS
Signature value: Signature value:
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
Concatenating these values in the order Header.Payload.Signature with Concatenating these values in the order Header.Payload.Signature with
period ('.') characters between the parts yields this complete JWS period ('.') characters between the parts yields this complete JWS
representation using the JWS Compact Serialization (with line breaks representation using the JWS Compact Serialization (with line breaks
for display purposes only): for display purposes only):
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
skipping to change at page 30, line 44 skipping to change at page 32, line 4
octet sequence: octet sequence:
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 122, 73, [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, 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, 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, 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, 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, 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, 98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48,
99, 110, 86, 108, 102, 81] 99, 110, 86, 108, 102, 81]
This example uses the RSA key represented in JSON Web Key [JWK]
format below (with line breaks for display purposes only):
The RSA key consists of a public part (Modulus, Exponent), and a {"kty":"RSA",
Private Exponent. The values of the RSA key used in this example, "n":"ofgWCuLjybRlzo0tZWJjNiuSfb4p4fAkd_wWJcyQoTbji9k0l8W26mPddx
presented as the octet sequences representing big endian integers HmfHQp-Vaw-4qPCJrcS2mJPMEzP1Pt0Bm4d4QlL-yRT-SFd2lZS-pCgNMs
are: D1W_YpRPEwOWvG6b32690r2jZ47soMZo9wGzjb_7OMg0LOL-bSf63kpaSH
SXndS5z5rexMdbBYUsLA9e-KXBdQOS-UTo7WTBEMa2R2CapHg665xsmtdV
+-----------+-------------------------------------------------------+ MTBQY4uDZlxvb3qCo5ZwKh9kG4LT6_I5IhlJH7aGhyxXFvUK-DWNmoudF8
| Parameter | Value | NAco9_h9iaGNj8q2ethFkMLs91kzk2PAcDTW9gb54h4FRWyuXpoQ",
| Name | | "e":"AQAB",
+-----------+-------------------------------------------------------+ "d":"Eq5xpGnNCivDflJsRQBXHx1hdR1k6Ulwe2JZD50LpXyWPEAeP88vLNO97I
| Modulus | [161, 248, 22, 10, 226, 227, 201, 180, 101, 206, 141, | jlA7_GQ5sLKMgvfTeXZx9SE-7YwVol2NXOoAJe46sui395IW_GO-pWJ1O0
| | 45, 101, 98, 99, 54, 43, 146, 125, 190, 41, 225, 240, | BkTGoVEn2bKVRUCgu-GjBVaYLU6f3l9kJfFNS3E0QbVdxzubSu3Mkqzjkn
| | 36, 119, 252, 22, 37, 204, 144, 161, 54, 227, 139, | 439X0M_V51gfpRLI9JYanrC4D4qAdGcopV_0ZHHzQlBjudU2QvXt4ehNYT
| | 217, 52, 151, 197, 182, 234, 99, 221, 119, 17, 230, | CBr6XCLQUShb1juUO1ZdiYoFaFQT5Tw8bGUl_x_jTj3ccPDVZFD9pIuhLh
| | 124, 116, 41, 249, 86, 176, 251, 138, 143, 8, 154, | BOneufuBiB4cS98l2SR_RQyGWSeWjnczT0QU91p1DhOVRuOopznQ"
| | 220, 75, 105, 137, 60, 193, 51, 63, 83, 237, 208, 25, | }
| | 184, 119, 132, 37, 47, 236, 145, 79, 228, 133, 119, |
| | 105, 89, 75, 234, 66, 128, 211, 44, 15, 85, 191, 98, |
| | 148, 79, 19, 3, 150, 188, 110, 155, 223, 110, 189, |
| | 210, 189, 163, 103, 142, 236, 160, 198, 104, 247, 1, |
| | 179, 141, 191, 251, 56, 200, 52, 44, 226, 254, 109, |
| | 39, 250, 222, 74, 90, 72, 116, 151, 157, 212, 185, |
| | 207, 154, 222, 196, 199, 91, 5, 133, 44, 44, 15, 94, |
| | 248, 165, 193, 117, 3, 146, 249, 68, 232, 237, 100, |
| | 193, 16, 198, 182, 71, 96, 154, 164, 120, 58, 235, |
| | 156, 108, 154, 215, 85, 49, 48, 80, 99, 139, 131, |
| | 102, 92, 111, 111, 122, 130, 163, 150, 112, 42, 31, |
| | 100, 27, 130, 211, 235, 242, 57, 34, 25, 73, 31, 182, |
| | 134, 135, 44, 87, 22, 245, 10, 248, 53, 141, 154, |
| | 139, 157, 23, 195, 64, 114, 143, 127, 135, 216, 154, |
| | 24, 216, 252, 171, 103, 173, 132, 89, 12, 46, 207, |
| | 117, 147, 57, 54, 60, 7, 3, 77, 111, 96, 111, 158, |
| | 33, 224, 84, 86, 202, 229, 233, 161] |
| Exponent | [1, 0, 1] |
| Private | [18, 174, 113, 164, 105, 205, 10, 43, 195, 126, 82, |
| Exponent | 108, 69, 0, 87, 31, 29, 97, 117, 29, 100, 233, 73, |
| | 112, 123, 98, 89, 15, 157, 11, 165, 124, 150, 60, 64, |
| | 30, 63, 207, 47, 44, 211, 189, 236, 136, 229, 3, 191, |
| | 198, 67, 155, 11, 40, 200, 47, 125, 55, 151, 103, 31, |
| | 82, 19, 238, 216, 193, 90, 37, 216, 213, 206, 160, 2, |
| | 94, 227, 171, 46, 139, 127, 121, 33, 111, 198, 59, |
| | 234, 86, 39, 83, 180, 6, 68, 198, 161, 81, 39, 217, |
| | 178, 149, 69, 64, 160, 187, 225, 163, 5, 86, 152, 45, |
| | 78, 159, 222, 95, 100, 37, 241, 77, 75, 113, 52, 65, |
| | 181, 93, 199, 59, 155, 74, 237, 204, 146, 172, 227, |
| | 146, 126, 55, 245, 125, 12, 253, 94, 117, 129, 250, |
| | 81, 44, 143, 73, 97, 169, 235, 11, 128, 248, 168, 7, |
| | 70, 114, 138, 85, 255, 70, 71, 31, 52, 37, 6, 59, |
| | 157, 83, 100, 47, 94, 222, 30, 132, 214, 19, 8, 26, |
| | 250, 92, 34, 208, 81, 40, 91, 214, 59, 148, 59, 86, |
| | 93, 137, 138, 5, 104, 84, 19, 229, 60, 60, 108, 101, |
| | 37, 255, 31, 227, 78, 61, 220, 112, 240, 213, 100, |
| | 80, 253, 164, 139, 161, 46, 16, 78, 157, 235, 159, |
| | 184, 24, 129, 225, 196, 189, 242, 93, 146, 71, 244, |
| | 80, 200, 101, 146, 121, 104, 231, 115, 52, 244, 65, |
| | 79, 117, 167, 80, 225, 57, 84, 110, 58, 138, 115, |
| | 157] |
+-----------+-------------------------------------------------------+
The RSA private key (Modulus, Private Exponent) is then passed to the The RSA private key is then passed to the RSA signing function, which
RSA signing function, which also takes the hash type, SHA-256, and also takes the hash type, SHA-256, and the octets of the ASCII
the octets of the ASCII representation of the JWS Signing Input as representation of the JWS Signing Input as inputs. The result of the
inputs. The result of the digital signature is an octet sequence, digital signature is an octet sequence, which represents a big endian
which represents a big endian integer. In this example, it is: integer. In this example, it is:
[112, 46, 33, 137, 67, 232, 143, 209, 30, 181, 216, 45, 191, 120, 69, [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, 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, 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, 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, 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, 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, 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, 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, 74, 230, 30, 177, 4, 10, 203, 32, 4, 77, 62, 249, 18, 142, 212, 1,
skipping to change at page 35, line 8 skipping to change at page 34, line 52
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 70, 85, 122, 73, [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, 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, 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, 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, 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, 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, 98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48,
99, 110, 86, 108, 102, 81] 99, 110, 86, 108, 102, 81]
The ECDSA key consists of a public part, the EC point (x, y), and a This example uses the elliptic curve key represented in JSON Web Key
private part d. The values of the ECDSA key used in this example,
presented as the octet sequences representing three 256 bit big
endian integers are:
+-----------+-------------------------------------------------------+ [JWK] format below:
| Parameter | Value |
| Name | | {"kty":"EC",
+-----------+-------------------------------------------------------+ "crv":"P-256",
| x | [127, 205, 206, 39, 112, 246, 196, 93, 65, 131, 203, | "x":"f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
| | 238, 111, 219, 75, 123, 88, 7, 51, 53, 123, 233, 239, | "y":"x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0",
| | 19, 186, 207, 110, 60, 123, 209, 84, 69] | "d":"jpsQnnGQmL-YBIffH1136cspYG6-0iY7X1fCE9-E9LI"
| y | [199, 241, 68, 205, 27, 189, 155, 126, 135, 44, 223, | }
| | 237, 185, 238, 185, 244, 179, 105, 93, 110, 169, 11, |
| | 36, 173, 138, 70, 35, 40, 133, 136, 229, 173] |
| d | [142, 155, 16, 158, 113, 144, 152, 191, 152, 4, 135, |
| | 223, 31, 93, 119, 233, 203, 41, 96, 110, 190, 210, |
| | 38, 59, 95, 87, 194, 19, 223, 132, 244, 178] |
+-----------+-------------------------------------------------------+
The ECDSA private part d is then passed to an ECDSA signing function, The 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 which also takes the curve type, P-256, the hash type, SHA-256, and
the octets of the ASCII representation of the JWS Signing Input as the octets of the ASCII representation of the JWS Signing Input as
inputs. The result of the digital signature is the EC point (R, S), 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 where R and S are unsigned integers. In this example, the R and S
values, given as octet sequences representing big endian integers values, given as octet sequences representing big endian integers
are: are:
+--------+----------------------------------------------------------+ +--------+----------------------------------------------------------+
skipping to change at page 37, line 29 skipping to change at page 37, line 12
Base64url encoding these octets yields this Encoded JWS Header value: Base64url encoding these octets yields this Encoded JWS Header value:
eyJhbGciOiJFUzUxMiJ9 eyJhbGciOiJFUzUxMiJ9
The JWS Payload used in this example, is the ASCII string "Payload". The JWS Payload used in this example, is the ASCII string "Payload".
The representation of this string is the octet sequence: The representation of this string is the octet sequence:
[80, 97, 121, 108, 111, 97, 100] [80, 97, 121, 108, 111, 97, 100]
Base64url encoding these octets yields the Encoded JWS Payload value: Base64url encoding these octets yields this Encoded JWS Payload
value:
UGF5bG9hZA UGF5bG9hZA
Concatenating the Encoded JWS Header, a period ('.') character, and Concatenating the Encoded JWS Header, a period ('.') character, and
the Encoded JWS Payload yields this JWS Signing Input value: the Encoded JWS Payload yields this JWS Signing Input value:
eyJhbGciOiJFUzUxMiJ9.UGF5bG9hZA eyJhbGciOiJFUzUxMiJ9.UGF5bG9hZA
The ASCII representation of the JWS Signing Input is the following The ASCII representation of the JWS Signing Input is the following
octet sequence: octet sequence:
[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 70, 85, 122, 85, [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] 120, 77, 105, 74, 57, 46, 85, 71, 70, 53, 98, 71, 57, 104, 90, 65]
The ECDSA key consists of a public part, the EC point (x, y), and a This example uses the elliptic curve key represented in JSON Web Key
private part d. The values of the ECDSA key used in this example, [JWK] format below (with line breaks for display purposes only):
presented as the octet sequences representing three 521 bit big
endian integers are:
+-----------+-------------------------------------------------------+ {"kty":"EC",
| Parameter | Value | "crv":"P-521",
| Name | | "x":"AekpBQ8ST8a8VcfVOTNl353vSrDCLLJXmPk06wTjxrrjcBpXp5EOnYG_
+-----------+-------------------------------------------------------+ NjFZ6OvLFV1jSfS9tsz4qUxcWceqwQGk",
| x | [1, 233, 41, 5, 15, 18, 79, 198, 188, 85, 199, 213, | "y":"ADSmRA43Z1DSNx_RvcLI87cdL07l6jQyyBXMoxVg_l2Th-x3S1WDhjDl
| | 57, 51, 101, 223, 157, 239, 74, 176, 194, 44, 178, | y79ajL4Kkd0AZMaZmh9ubmf63e3kyMj2",
| | 87, 152, 249, 52, 235, 4, 227, 198, 186, 227, 112, | "d":"AY5pb7A0UFiB3RELSD64fTLOSV_jazdF7fLYyuTw8lOfRhWg6Y6rUrPA
| | 26, 87, 167, 145, 14, 157, 129, 191, 54, 49, 89, 232, | xerEzgdRhajnu0ferB0d53vM9mE15j2C"
| | 235, 203, 21, 93, 99, 73, 244, 189, 182, 204, 248, | }
| | 169, 76, 92, 89, 199, 170, 193, 1, 164] |
| y | [0, 52, 166, 68, 14, 55, 103, 80, 210, 55, 31, 209, |
| | 189, 194, 200, 243, 183, 29, 47, 78, 229, 234, 52, |
| | 50, 200, 21, 204, 163, 21, 96, 254, 93, 147, 135, |
| | 236, 119, 75, 85, 131, 134, 48, 229, 203, 191, 90, |
| | 140, 190, 10, 145, 221, 0, 100, 198, 153, 154, 31, |
| | 110, 110, 103, 250, 221, 237, 228, 200, 200, 246] |
| d | [1, 142, 105, 111, 176, 52, 80, 88, 129, 221, 17, 11, |
| | 72, 62, 184, 125, 50, 206, 73, 95, 227, 107, 55, 69, |
| | 237, 242, 216, 202, 228, 240, 242, 83, 159, 70, 21, |
| | 160, 233, 142, 171, 82, 179, 192, 197, 234, 196, 206, |
| | 7, 81, 133, 168, 231, 187, 71, 222, 172, 29, 29, 231, |
| | 123, 204, 246, 97, 53, 230, 61, 130] |
+-----------+-------------------------------------------------------+
The ECDSA private part d is then passed to an ECDSA signing function, 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 which also takes the curve type, P-521, the hash type, SHA-512, and
the octets of the ASCII representation of the JWS Signing Input as the octets of the ASCII representation of the JWS Signing Input as
inputs. The result of the digital signature is the EC point (R, S), 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 where R and S are unsigned integers. In this example, the R and S
values, given as octet sequences representing big endian integers values, given as octet sequences representing big endian integers
are: are:
+--------+----------------------------------------------------------+ +--------+----------------------------------------------------------+
skipping to change at page 42, line 45 skipping to change at page 42, line 7
"m2nhGPQGjPEDIotJnzcnlhUZnXeg0xzLVbh6NZzthY8yU3klJYaENE1aLAUtL "m2nhGPQGjPEDIotJnzcnlhUZnXeg0xzLVbh6NZzthY8yU3klJYaENE1aLAUtL
cq-TmEeYIr30ruGH2kNFqW4-oc7LcTQu9-7ItRhfi0kKeN1zNAAUemfNYXaXA cq-TmEeYIr30ruGH2kNFqW4-oc7LcTQu9-7ItRhfi0kKeN1zNAAUemfNYXaXA
1JayiiCl7m9ylhLKIsvdXhFvV7XDSbUMnVoO9Yu5_ROKOJMkeU6ywR8DDcHmu 1JayiiCl7m9ylhLKIsvdXhFvV7XDSbUMnVoO9Yu5_ROKOJMkeU6ywR8DDcHmu
B2KcLMfpHn1FqnUnojxwfOg1Eqyb_ppeDTm9t_h8FoQgHqRpNgsTTvxI9vSPE B2KcLMfpHn1FqnUnojxwfOg1Eqyb_ppeDTm9t_h8FoQgHqRpNgsTTvxI9vSPE
ZrWTkSf_D4ci6p06DM_nE6FbptYF3ENHF8NpGgncv_D_h9AIrZU5-6ee2HB24 ZrWTkSf_D4ci6p06DM_nE6FbptYF3ENHF8NpGgncv_D_h9AIrZU5-6ee2HB24
jtN9qOHw2pkVrvhtxdsSJdeG6uJqiFs0ArwQQ"}] jtN9qOHw2pkVrvhtxdsSJdeG6uJqiFs0ArwQQ"}]
} }
A.6.5. RSA Key Used for Second Signature A.6.5. RSA Key Used for Second Signature
The values of the RSA key used for the second signature in this this The second signature in this example uses the RSA key represented in
example, presented as the octet sequences representing big endian JSON Web Key [JWK] format below (with line breaks for display
integers are: purposes only):
+-----------+-------------------------------------------------------+ {"kty":"RSA",
| Parameter | Value | "n":"oHiJbb8NGB0P2UQjpJghsz4WM4Y85HCsCz45EBqi1frHtzhnZawUsuJ8dI
| Name | | fDw3xbrkHaxHFShKGRRwh18G10KMQarocrryim350FvFwHNNsLnWBjGUGX
+-----------+-------------------------------------------------------+ bBlozpM_AZ2aOm_I-zbKYNwqxBX8wTrNLFnZOqRjA0zDtEwTZ24aAnqt0y
| Modulus | [160, 120, 137, 109, 191, 13, 24, 29, 15, 217, 68, | 3ahtQaxpxu1Ysfh-MrAC3AJ86wwprZCrnjj46zdavuu1gMuSRuZEwiJxSR
| | 35, 164, 152, 33, 179, 62, 22, 51, 134, 60, 228, 112, | uCwOZBVND1KWNZwuxOecmJhVkbjD1YZrSwp16UzXPs1fqgbq3YsE8e_LHC
| | 172, 11, 62, 57, 16, 26, 162, 213, 250, 199, 183, 56, | BfwBikrIQKwe8tjJnGjHUR3wwaBS_f05d4D-Y8KjNody4p8rFMIQ",
| | 103, 101, 172, 20, 178, 226, 124, 116, 135, 195, 195, | "e":"AQAB",
| | 124, 91, 174, 65, 218, 196, 113, 82, 132, 161, 145, | "d":"djLy_3x3V6iocN-o5WcNg6qazc718Uow34MwovULtlOnYgTQ3GoZQP5kr6
| | 71, 8, 117, 240, 109, 116, 40, 196, 26, 174, 135, 43, | 0E_GwQV9W4H3RdVMZxbQIFZVgp9JEmGiIEgluONy3A-NJMmJkz__Lsa8EN
| | 175, 40, 166, 223, 157, 5, 188, 92, 7, 52, 219, 11, | mRlKQsbg5P7CiIKoZqof_aKOeaq8Z1Q5po5z3KcTK24SxS44KLpHvESYK5
| | 157, 96, 99, 25, 65, 151, 108, 25, 104, 206, 147, 63, | 9Re4Bnp_OLvFokjpfZ1fSVtwkQlXfpoclrl7mdfO6TMjOqvL6aXO8uJbIx
| | 1, 157, 154, 58, 111, 200, 251, 54, 202, 96, 220, 42, | StHcOBO6IjSYglY47QG64fQd-DkVAQo3sG6RlQSJDXnsV7ow2gNO2gL0X6
| | 196, 21, 252, 193, 58, 205, 44, 89, 217, 58, 164, 99, | ja2ff8UQ0W0tsalSDZ05DnaPBFSe0BDhyhyt7RnGwbz34oTWZdAQ"
| | 3, 76, 195, 180, 76, 19, 103, 110, 26, 2, 122, 173, | }
| | 211, 45, 218, 134, 212, 26, 198, 156, 110, 213, 139, |
| | 31, 135, 227, 43, 0, 45, 192, 39, 206, 176, 194, 154, |
| | 217, 10, 185, 227, 143, 142, 179, 117, 171, 238, 187, |
| | 88, 12, 185, 36, 110, 100, 76, 34, 39, 20, 145, 184, |
| | 44, 14, 100, 21, 77, 15, 82, 150, 53, 156, 46, 196, |
| | 231, 156, 152, 152, 85, 145, 184, 195, 213, 134, 107, |
| | 75, 10, 117, 233, 76, 215, 62, 205, 95, 170, 6, 234, |
| | 221, 139, 4, 241, 239, 203, 28, 32, 95, 192, 24, 164, |
| | 172, 132, 10, 193, 239, 45, 140, 153, 198, 140, 117, |
| | 17, 223, 12, 26, 5, 47, 223, 211, 151, 120, 15, 230, |
| | 60, 42, 51, 104, 119, 46, 41, 242, 177, 76, 33] |
| Exponent | [1, 0, 1] |
| Private | [118, 50, 242, 255, 124, 119, 87, 168, 168, 112, 223, |
| Exponent | 168, 229, 103, 13, 131, 170, 154, 205, 206, 245, 241, |
| | 74, 48, 223, 131, 48, 162, 245, 11, 182, 83, 167, 98, |
| | 4, 208, 220, 106, 25, 64, 254, 100, 175, 173, 4, 252, |
| | 108, 16, 87, 213, 184, 31, 116, 93, 84, 198, 113, |
| | 109, 2, 5, 101, 88, 41, 244, 145, 38, 26, 34, 4, 130, |
| | 91, 142, 55, 45, 192, 248, 210, 76, 152, 153, 51, |
| | 255, 242, 236, 107, 193, 13, 153, 25, 74, 66, 198, |
| | 224, 228, 254, 194, 136, 130, 168, 102, 170, 31, 253, |
| | 162, 142, 121, 170, 188, 103, 84, 57, 166, 142, 115, |
| | 220, 167, 19, 43, 110, 18, 197, 46, 56, 40, 186, 71, |
| | 188, 68, 152, 43, 159, 81, 123, 128, 103, 167, 243, |
| | 139, 188, 90, 36, 142, 151, 217, 213, 244, 149, 183, |
| | 9, 16, 149, 119, 233, 161, 201, 107, 151, 185, 157, |
| | 124, 238, 147, 50, 51, 170, 188, 190, 154, 92, 239, |
| | 46, 37, 178, 49, 74, 209, 220, 56, 19, 186, 34, 52, |
| | 152, 130, 86, 56, 237, 1, 186, 225, 244, 29, 248, 57, |
| | 21, 1, 10, 55, 176, 110, 145, 149, 4, 137, 13, 121, |
| | 236, 87, 186, 48, 218, 3, 78, 218, 2, 244, 95, 168, |
| | 218, 217, 247, 252, 81, 13, 22, 210, 219, 26, 149, |
| | 32, 217, 211, 144, 231, 104, 240, 69, 73, 237, 1, 14, |
| | 28, 161, 202, 222, 209, 156, 108, 27, 207, 126, 40, |
| | 77, 102, 93, 1] |
+-----------+-------------------------------------------------------+
Appendix B. "x5c" (X.509 Certificate Chain) Example Appendix B. "x5c" (X.509 Certificate Chain) Example
The JSON array below is an example of a certificate chain that could 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 be used as the value of an "x5c" (X.509 Certificate Chain) header
parameter, per Section 4.1.6. Note that since these strings contain parameter, per Section 4.1.6. Note that since these strings contain
base64 encoded (not base64url encoded) values, they are allowed to base64 encoded (not base64url encoded) values, they are allowed to
contain white space and line breaks. contain white space and line breaks.
["MIIE3jCCA8agAwIBAgICAwEwDQYJKoZIhvcNAQEFBQAwYzELMAkGA1UEBhMCVVM ["MIIE3jCCA8agAwIBAgICAwEwDQYJKoZIhvcNAQEFBQAwYzELMAkGA1UEBhMCVVM
skipping to change at page 47, line 22 skipping to change at page 45, line 19
which when decoded, reproduces the octet sequence. which when decoded, reproduces the octet sequence.
3 236 255 224 193 3 236 255 224 193
A-z_4ME A-z_4ME
Appendix D. Negative Test Case for "crit" Header Parameter Appendix D. Negative Test Case for "crit" Header Parameter
Conforming implementations must reject input containing critical Conforming implementations must reject input containing critical
extensions that are not understood or cannot be processed. The extensions that are not understood or cannot be processed. The
following JWS must be rejected by all implementations, because it following JWS must be rejected by all implementations, because it
uses an extension header parameter name uses an extension header parameter name
"http://example.com/UNDEFINED" that they do not understand. Any "http://example.invalid/UNDEFINED" that they do not understand. Any
other similar input, in which the use of the value other similar input, in which the use of the value
"http://example.com/UNDEFINED" is substituted for any other header "http://example.invalid/UNDEFINED" is substituted for any other
parameter name not understood by the implementation, must also be header parameter name not understood by the implementation, must also
rejected. be rejected.
The JWS Header value for this JWS is: The JWS Header value for this JWS is:
{"alg":"none", {"alg":"none",
"crit":["http://example.com/UNDEFINED"], "crit":["http://example.invalid/UNDEFINED"],
"http://example.com/UNDEFINED":true "http://example.invalid/UNDEFINED":true
} }
The complete JWS that must be rejected is as follows (with line The complete JWS that must be rejected is as follows (with line
breaks for display purposes only): breaks for display purposes only):
eyJhbGciOiJub25lIiwNCiAiY3JpdCI6WyJodHRwOi8vZXhhbXBsZS5jb20vVU5ERU eyJhbGciOiJub25lIiwNCiAiY3JpdCI6WyJodHRwOi8vZXhhbXBsZS5jb20vVU5ERU
ZJTkVEIl0sDQogImh0dHA6Ly9leGFtcGxlLmNvbS9VTkRFRklORUQiOnRydWUNCn0. ZJTkVEIl0sDQogImh0dHA6Ly9leGFtcGxlLmNvbS9VTkRFRklORUQiOnRydWUNCn0.
RkFJTA. RkFJTA.
Appendix E. Acknowledgements Appendix E. Acknowledgements
skipping to change at page 48, line 24 skipping to change at page 46, line 21
Hannes Tschofenig, and Sean Turner. Hannes Tschofenig, and Sean Turner.
Jim Schaad and Karen O'Donoghue chaired the JOSE working group and Jim Schaad and Karen O'Donoghue chaired the JOSE working group and
Sean Turner and Stephen Farrell served as Security area directors Sean Turner and Stephen Farrell served as Security area directors
during the creation of this specification. during the creation of this specification.
Appendix F. Document History Appendix F. Document History
[[ to be removed by the RFC editor before publication as an RFC ]] [[ to be removed by the RFC editor before publication as an RFC ]]
-12
o Clarified that the "typ" and "cty" header parameters are used in
an application-specific manner and have no effect upon the JWS
processing.
o Replaced the MIME types "application/jws+json" and
"application/jws" with "application/jose+json" and
"application/jose".
o Stated that receipients MUST either reject JWSs with duplicate
Header Parameter Names or use a JSON parser that returns only the
lexically last duplicate member name.
o Added a Serializations section with parallel treatment of the JWS
Compact Serialization and the JWS JSON Serialization and also
moved the former Implementation Considerations content there.
-11 -11
o Added Key Identification section. o Added Key Identification section.
o For the JWS JSON Serialization, enable header parameter values to o For the JWS JSON Serialization, enable header parameter values to
be specified in any of three parameters: the "protected" member be specified in any of three parameters: the "protected" member
that is integrity protected and shared among all recipients, the that is integrity protected and shared among all recipients, the
"unprotected" member that is not integrity protected and shared "unprotected" member that is not integrity protected and shared
among all recipients, and the "header" member that is not among all recipients, and the "header" member that is not
integrity protected and specific to a particular recipient. (This integrity protected and specific to a particular recipient. (This
 End of changes. 84 change blocks. 
344 lines changed or deleted 320 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/