draft-ietf-jose-json-web-signature-16.txt   draft-ietf-jose-json-web-signature-17.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: March 19, 2014 Ping Identity Expires: April 10, 2014 Ping Identity
N. Sakimura N. Sakimura
NRI NRI
September 15, 2013 October 7, 2013
JSON Web Signature (JWS) JSON Web Signature (JWS)
draft-ietf-jose-json-web-signature-16 draft-ietf-jose-json-web-signature-17
Abstract Abstract
JSON Web Signature (JWS) represents content secured with digital JSON Web Signature (JWS) represents content secured with digital
signatures or Message Authentication Codes (MACs) using JavaScript signatures or Message Authentication Codes (MACs) using JavaScript
Object Notation (JSON) based data structures. Cryptographic Object Notation (JSON) based data structures. Cryptographic
algorithms and identifiers for use with this specification are algorithms and identifiers for use with this specification are
described in the separate JSON Web Algorithms (JWA) specification and described in the separate JSON Web Algorithms (JWA) specification and
an IANA registry defined by that specification. Related encryption an IANA registry defined by that specification. Related encryption
capabilities are described in the separate JSON Web Encryption (JWE) capabilities are described in the separate JSON Web Encryption (JWE)
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 March 19, 2014. This Internet-Draft will expire on April 10, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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 . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. JSON Web Signature (JWS) Overview . . . . . . . . . . . . . . 6 3. JSON Web Signature (JWS) Overview . . . . . . . . . . . . . . 6
3.1. Example JWS . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Example JWS . . . . . . . . . . . . . . . . . . . . . . . 7
4. JWS Header . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. JWS Header . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Registered Header Parameter Names . . . . . . . . . . . . 8 4.1. Registered Header Parameter Names . . . . . . . . . . . . 9
4.1.1. "alg" (Algorithm) Header Parameter . . . . . . . . . . 8 4.1.1. "alg" (Algorithm) Header Parameter . . . . . . . . . . 9
4.1.2. "jku" (JWK Set URL) Header Parameter . . . . . . . . . 9 4.1.2. "jku" (JWK Set URL) Header Parameter . . . . . . . . . 10
4.1.3. "jwk" (JSON Web Key) Header Parameter . . . . . . . . 9 4.1.3. "jwk" (JSON Web Key) Header Parameter . . . . . . . . 10
4.1.4. "x5u" (X.509 URL) Header Parameter . . . . . . . . . . 9 4.1.4. "x5u" (X.509 URL) Header Parameter . . . . . . . . . . 10
4.1.5. "x5t" (X.509 Certificate SHA-1 Thumbprint) Header 4.1.5. "x5t" (X.509 Certificate SHA-1 Thumbprint) Header
Parameter . . . . . . . . . . . . . . . . . . . . . . 9 Parameter . . . . . . . . . . . . . . . . . . . . . . 11
4.1.6. "x5c" (X.509 Certificate Chain) Header Parameter . . . 10 4.1.6. "x5c" (X.509 Certificate Chain) Header Parameter . . . 11
4.1.7. "kid" (Key ID) Header Parameter . . . . . . . . . . . 10 4.1.7. "kid" (Key ID) Header Parameter . . . . . . . . . . . 11
4.1.8. "typ" (Type) Header Parameter . . . . . . . . . . . . 10 4.1.8. "typ" (Type) Header Parameter . . . . . . . . . . . . 12
4.1.9. "cty" (Content Type) Header Parameter . . . . . . . . 11 4.1.9. "cty" (Content Type) Header Parameter . . . . . . . . 12
4.1.10. "crit" (Critical) Header Parameter . . . . . . . . . . 11 4.1.10. "crit" (Critical) Header Parameter . . . . . . . . . . 13
4.2. Public Header Parameter Names . . . . . . . . . . . . . . 12 4.2. Public Header Parameter Names . . . . . . . . . . . . . . 13
4.3. Private Header Parameter Names . . . . . . . . . . . . . . 12 4.3. Private Header Parameter Names . . . . . . . . . . . . . . 13
5. Producing and Consuming JWSs . . . . . . . . . . . . . . . . . 12 5. Producing and Consuming JWSs . . . . . . . . . . . . . . . . . 14
5.1. Message Signing or MACing . . . . . . . . . . . . . . . . 12 5.1. Message Signing or MACing . . . . . . . . . . . . . . . . 14
5.2. Message Signature or MAC Validation . . . . . . . . . . . 13 5.2. Message Signature or MAC Validation . . . . . . . . . . . 14
5.3. String Comparison Rules . . . . . . . . . . . . . . . . . 15 5.3. String Comparison Rules . . . . . . . . . . . . . . . . . 16
6. Key Identification . . . . . . . . . . . . . . . . . . . . . . 15 6. Key Identification . . . . . . . . . . . . . . . . . . . . . . 16
7. Serializations . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Serializations . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. JWS Compact Serialization . . . . . . . . . . . . . . . . 16 7.1. JWS Compact Serialization . . . . . . . . . . . . . . . . 17
7.2. JWS JSON Serialization . . . . . . . . . . . . . . . . . . 16 7.2. JWS JSON Serialization . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8.1. JSON Web Signature and Encryption Header Parameters 8.1. JSON Web Signature and Encryption Header Parameters
Registry . . . . . . . . . . . . . . . . . . . . . . . . . 19 Registry . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1.1. Registration Template . . . . . . . . . . . . . . . . 19 8.1.1. Registration Template . . . . . . . . . . . . . . . . 20
8.1.2. Initial Registry Contents . . . . . . . . . . . . . . 20 8.1.2. Initial Registry Contents . . . . . . . . . . . . . . 20
8.2. JSON Web Signature and Encryption Type Values Registry . . 21 8.2. Media Type Registration . . . . . . . . . . . . . . . . . 22
8.2.1. Registration Template . . . . . . . . . . . . . . . . 21 8.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 22
8.2.2. Initial Registry Contents . . . . . . . . . . . . . . 22
8.3. Media Type Registration . . . . . . . . . . . . . . . . . 22
8.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9.1. Cryptographic Security Considerations . . . . . . . . . . 23 9.1. Cryptographic Security Considerations . . . . . . . . . . 23
9.2. JSON Security Considerations . . . . . . . . . . . . . . . 25 9.2. JSON Security Considerations . . . . . . . . . . . . . . . 24
9.3. Unicode Comparison Security Considerations . . . . . . . . 25 9.3. Unicode Comparison Security Considerations . . . . . . . . 25
9.4. TLS Requirements . . . . . . . . . . . . . . . . . . . . . 26 9.4. TLS Requirements . . . . . . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 10.1. Normative References . . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . . 28 10.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. JWS Examples . . . . . . . . . . . . . . . . . . . . 28 Appendix A. JWS Examples . . . . . . . . . . . . . . . . . . . . 28
A.1. Example JWS using HMAC SHA-256 . . . . . . . . . . . . . . 29 A.1. Example JWS using HMAC SHA-256 . . . . . . . . . . . . . . 28
A.1.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 29 A.1.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 28
A.1.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 31 A.1.2. Validating . . . . . . . . . . . . . . . . . . . . . . 30
A.1.3. Validating . . . . . . . . . . . . . . . . . . . . . . 31 A.2. Example JWS using RSASSA-PKCS-v1_5 SHA-256 . . . . . . . . 30
A.2. Example JWS using RSASSA-PKCS-v1_5 SHA-256 . . . . . . . . 31 A.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 30
A.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 31 A.2.2. Validating . . . . . . . . . . . . . . . . . . . . . . 33
A.2.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 34 A.3. Example JWS using ECDSA P-256 SHA-256 . . . . . . . . . . 33
A.2.3. Validating . . . . . . . . . . . . . . . . . . . . . . 34 A.3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 33
A.3. Example JWS using ECDSA P-256 SHA-256 . . . . . . . . . . 34 A.3.2. Validating . . . . . . . . . . . . . . . . . . . . . . 35
A.3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 34 A.4. Example JWS using ECDSA P-521 SHA-512 . . . . . . . . . . 35
A.3.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 36 A.4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 36
A.3.3. Validating . . . . . . . . . . . . . . . . . . . . . . 36 A.4.2. Validating . . . . . . . . . . . . . . . . . . . . . . 38
A.4. Example JWS using ECDSA P-521 SHA-512 . . . . . . . . . . 37 A.5. Example Plaintext JWS . . . . . . . . . . . . . . . . . . 38
A.4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 37 A.6. Example JWS Using JWS JSON Serialization . . . . . . . . . 39
A.4.2. Decoding . . . . . . . . . . . . . . . . . . . . . . . 39 A.6.1. JWS Per-Signature Protected Headers . . . . . . . . . 39
A.4.3. Validating . . . . . . . . . . . . . . . . . . . . . . 39 A.6.2. JWS Per-Signature Unprotected Headers . . . . . . . . 40
A.5. Example Plaintext JWS . . . . . . . . . . . . . . . . . . 39 A.6.3. Complete JWS Header Values . . . . . . . . . . . . . . 40
A.6. Example JWS Using JWS JSON Serialization . . . . . . . . . 40 A.6.4. Complete JWS JSON Serialization Representation . . . . 40
A.6.1. JWS Per-Signature Protected Headers . . . . . . . . . 40 Appendix B. "x5c" (X.509 Certificate Chain) Example . . . . . . . 41
A.6.2. JWS Per-Signature Unprotected Headers . . . . . . . . 41
A.6.3. Complete JWS Header Values . . . . . . . . . . . . . . 41
A.6.4. Complete JWS JSON Serialization Representation . . . . 41
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 . . . . . . . . . . . . . . . . . . . . . . . 44 padding . . . . . . . . . . . . . . . . . . . . . . . 43
Appendix D. Negative Test Case for "crit" Header Parameter . . . 45 Appendix D. Negative Test Case for "crit" Header Parameter . . . 44
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 45 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 44
Appendix F. Document History . . . . . . . . . . . . . . . . . . 46 Appendix F. Document History . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction 1. Introduction
JSON Web Signature (JWS) represents content secured with digital JSON Web Signature (JWS) represents content secured with digital
signatures or Message Authentication Codes (MACs) using JavaScript signatures or Message Authentication Codes (MACs) using JavaScript
Object Notation (JSON) [RFC4627] based data structures. The JWS Object Notation (JSON) [RFC4627] based data structures. The JWS
cryptographic mechanisms provide integrity protection for an cryptographic mechanisms provide integrity protection for an
arbitrary sequence of octets. arbitrary sequence of octets.
Two closely related serializations for JWS objects are defined. The Two closely related serializations for JWS objects are defined. The
skipping to change at page 4, line 39 skipping to change at page 4, line 39
1.1. Notational Conventions 1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in Key words for use in document are to be interpreted as described in Key words for use in
RFCs to Indicate Requirement Levels [RFC2119]. If these words are RFCs to Indicate Requirement Levels [RFC2119]. If these words are
used without being spelled in uppercase then they are to be used without being spelled in uppercase then they are to be
interpreted with their normal natural language meanings. interpreted with their normal natural language meanings.
BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per
Section 2.
UTF8(STRING) denotes the octets of the UTF-8 [RFC3629] representation
of STRING.
ASCII(STRING) denotes the octets of the ASCII [USASCII]
representation of STRING.
The concatenation of two values A and B is denoted as A || B.
2. Terminology 2. Terminology
JSON Web Signature (JWS) A data structure representing a digitally JSON Web Signature (JWS) A data structure representing a digitally
signed or MACed message. The structure represents three values: signed or MACed message.
the JWS Header, the JWS Payload, and the JWS Signature.
JSON Text Object A UTF-8 [RFC3629] encoded text string representing JSON Text Object A UTF-8 [RFC3629] encoded text string representing
a JSON object; the syntax of JSON objects is defined in Section a JSON object; the syntax of JSON objects is defined in Section
2.2 of [RFC4627]. 2.2 of [RFC4627].
JWS Header A JSON Text Object (or JSON Text Objects, when using the JWS Header A JSON Text Object (or JSON Text Objects, when using the
JWS JSON Serialization) that describes the digital signature or JWS JSON Serialization) that describes the digital signature or
MAC operation applied to create the JWS Signature value. The MAC operation applied to create the JWS Signature value. The
members of the JWS Header object(s) are Header Parameters. members of the JWS Header object(s) are Header Parameters.
skipping to change at page 5, line 26 skipping to change at page 5, line 35
signature or MAC value calculated over the JWS Signing Input using signature or MAC value calculated over the JWS Signing Input using
the parameters specified in the JWS Header. the parameters specified in the JWS Header.
JWS Protected Header A JSON Text Object that contains the portion of JWS Protected Header A JSON Text Object that contains the portion of
the JWS Header that is integrity protected. For the JWS Compact the JWS Header that is integrity protected. For the JWS Compact
Serialization, this comprises the entire JWS Header. For the JWS Serialization, this comprises the entire JWS Header. For the JWS
JSON Serialization, this is one component of the JWS Header. JSON Serialization, this is one component of the JWS Header.
Header Parameter A name/value pair that is member of the JWS Header. Header Parameter A name/value pair that is member of the JWS Header.
Header Parameter Name The name of a member of the JWS Header.
Header Parameter Value The value of a member of the JWS Header.
Base64url Encoding Base64 encoding using the URL- and filename-safe Base64url Encoding Base64 encoding using the URL- and filename-safe
character set defined in Section 5 of RFC 4648 [RFC4648], with all character set defined in Section 5 of RFC 4648 [RFC4648], with all
trailing '=' characters omitted (as permitted by Section 3.2). trailing '=' characters omitted (as permitted by Section 3.2).
(See Appendix C for notes on implementing base64url encoding (See Appendix C for notes on implementing base64url encoding
without padding.) without padding.)
Encoded JWS Header Base64url encoding of the JWS Protected Header. JWS Signing Input The input to the digital signature or MAC
computation. Its value is ASCII(BASE64URL(UTF8(JWS Protected
Encoded JWS Payload Base64url encoding of the JWS Payload. Header)) || '.' || BASE64URL(JWS Payload)).
Encoded JWS Signature Base64url encoding of the JWS Signature.
JWS Signing Input The concatenation of the Encoded JWS Header, a
period ('.') character, and the Encoded JWS Payload.
JWS Compact Serialization A representation of the JWS as the JWS Compact Serialization A representation of the JWS as the string
concatenation of the Encoded JWS Header, the Encoded JWS Payload, BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS
and the Encoded JWS Signature in that order, with the three Payload) || '.' || BASE64URL(JWS Signature). This representation
strings being separated by two period ('.') characters. This is compact and URL-safe.
representation is compact and URL-safe.
JWS JSON Serialization A representation of the JWS as a JSON JWS JSON Serialization A representation of the JWS as a JSON
structure containing JWS Header, Encoded JWS Payload, and Encoded structure. Unlike the JWS Compact Serialization, the JWS JSON
JWS Signature values. Unlike the JWS Compact Serialization, the Serialization enables multiple digital signatures and/or MACs to
JWS JSON Serialization enables multiple digital signatures and/or be applied to the same content. This representation is neither
MACs to be applied to the same content. This representation is compact nor URL-safe.
neither compact nor URL-safe.
Collision Resistant Name A name in a namespace that enables names to Collision Resistant Name A name in a namespace that enables names to
be allocated in a manner such that they are highly unlikely to be allocated in a manner such that they are highly unlikely to
collide with other names. Examples of collision resistant collide with other names. Examples of collision resistant
namespaces include: Domain Names, Object Identifiers (OIDs) as namespaces include: Domain Names, Object Identifiers (OIDs) as
defined in the ITU-T X.660 and X.670 Recommendation series, and defined in the ITU-T X.660 and X.670 Recommendation series, and
Universally Unique IDentifiers (UUIDs) [RFC4122]. When using an Universally Unique IDentifiers (UUIDs) [RFC4122]. When using an
administratively delegated namespace, the definer of a name needs administratively delegated namespace, the definer of a name needs
to take reasonable precautions to ensure they are in control of to take reasonable precautions to ensure they are in control of
the portion of the namespace they use to define the name. the portion of the namespace they use to define the name.
StringOrURI A JSON string value, with the additional requirement StringOrURI A JSON string value, with the additional requirement
that while arbitrary string values MAY be used, any value that while arbitrary string values MAY be used, any value
containing a ":" character MUST be a URI [RFC3986]. StringOrURI containing a ":" character MUST be a URI [RFC3986]. StringOrURI
values are compared as case-sensitive strings with no values are compared as case-sensitive strings with no
transformations or canonicalizations applied. transformations or canonicalizations applied.
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. A JWS represents these logical
JWS: the JWS Header, the JWS Payload, and the JWS Signature. In the values:
Compact Serialization, the three values are base64url-encoded for
transmission, and represented as the concatenation of the encoded
strings in that order, with the three strings being separated by two
period ('.') characters. A JSON Serialization for this information
is also defined in Section 7.2.
The JWS Header describes the signature or MAC method and parameters JWS Header JSON object containing the parameters describing the
employed. The JWS Payload is the message content to be secured. The cryptographic operations and parameters employed. The JWE Header
JWS Signature ensures the integrity of both the JWS Protected Header members are the union of the members of the JWS Protected Header
and the JWS Payload. and the JWS Unprotected Header, as described below.
JWS Payload Message content to be secured.
JWS Signature Digital signature or MAC over the JWS Protected Header
and the JWS Payload.
The JWS Header represents the combination of these logical values:
JWS Protected Header JSON object containing some of the parameters
describing the cryptographic operations and parameters employed.
This value is integrity protected in the digital signature or MAC
calculation of the JWS Signature.
JWS Unprotected Header JSON object containing some of the parameters
describing the cryptographic operations and parameters employed.
This value is not integrity protected in the digital signature or
MAC calculation of the JWS Signature.
This document defines two serializations for JWS objects: a compact,
URL-safe serialization called the JWS Compact Serialization and a
JSON serialization called the JWS JSON Serialization. In both
serializations, the JWS Protected Header, JWS Payload, and JWS
Signature are base64url encoded for transmission, since JSON lacks a
way to directly represent octet sequences.
In the JWS Compact Serialization, no JWS Unprotected Header is used.
In this case, the JWS Header and the JWS Protected Header are the
same.
In the JWS Compact Serialization, a JWS object is represented as the
combination of these three string values,
BASE64URL(UTF8(JWS Protected Header)),
BASE64URL(JWS Payload), and
BASE64URL(JWS Signature),
concatenated in that order, with the three strings being separated by
two period ('.') characters.
In the JWS JSON Serialization, one or both of the JWS Protected
Header and JWS Unprotected Header MUST be present. In this case, the
members of the JWS Header are the combination of the members of the
JWS Protected Header and the JWS Unprotected Header values that are
present.
In the JWS JSON Serialization, a JWS object is represented as the
combination of these four values,
BASE64URL(UTF8(JWS Protected Header)),
JWS Unprotected Header,
BASE64URL(JWS Payload), and
BASE64URL(JWS Signature),
with the three base64url encoding result strings and the JWS
Unprotected Header value being represented as members within a JSON
object. The inclusion of some of these values is OPTIONAL. The JWS
JSON Serialization can also represent multiple signature and/or MAC
values, rather than just one. See Section 7.2 for more information
about the JWS JSON Serialization.
3.1. Example JWS 3.1. Example JWS
This section provides an example of a JWS. Its computation is This section provides an example of a JWS. Its computation is
described in more detail in Appendix A.1, including specifying the described in more detail in Appendix A.1, including specifying the
exact octet sequences representing the JSON values used and the key exact octet sequences representing the JSON values used and the key
value used. value used.
The following example JWS Header declares that the encoded object is The following example JWS Protected Header declares that the encoded
a JSON Web Token (JWT) [JWT] and the JWS Header and the JWS Payload object is a JSON Web Token (JWT) [JWT] and the JWS Protected Header
are secured using the HMAC SHA-256 algorithm: and the JWS Payload are secured using the HMAC SHA-256 algorithm:
{"typ":"JWT", {"typ":"JWT",
"alg":"HS256"} "alg":"HS256"}
Base64url encoding the octets of the UTF-8 representation of the JWS Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected
Header yields this Encoded JWS Header value: Header)) gives this value:
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
The UTF-8 representation of following JSON object is used as the JWS The UTF-8 representation of following JSON object is used as the JWS
Payload. (Note that the payload can be any content, and need not be Payload. (Note that the payload can be any content, and need not be
a representation of a JSON object.) 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 JWS Payload yields this Encoded JWS Payload Encoding this JWS Payload as BASE64URL(JWS Payload) gives this value
(with line breaks for display purposes only): (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 JWS Signing Input ASCII(BASE64URL(UTF8(JWS
representation of the JWS Signing Input (the concatenation of the Protected Header)) || '.' || BASE64URL(JWS Payload)) with the HMAC
Encoded JWS Header, a period ('.') character, and the Encoded JWS SHA-256 algorithm using the key specified in Appendix A.1 and
Payload) with the HMAC SHA-256 algorithm using the key specified in base64url encoding the result yields this BASE64URL(JWS Signature)
Appendix A.1 and base64url encoding the result yields this Encoded value:
JWS 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
. .
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
. .
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
See Appendix A for additional examples. See Appendix A for additional examples.
4. JWS Header 4. JWS Header
The members of the JSON object(s) representing 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 JWS Protected
Header and the Encoded JWS Payload and optionally additional Header and the JWS Payload and optionally additional properties of
properties of the JWS. The Header Parameter Names within the JWS the JWS. The Header Parameter names within the JWS Header MUST be
Header MUST be unique; recipients MUST either reject JWSs with unique; recipients MUST either reject JWSs with duplicate Header
duplicate Header Parameter Names or use a JSON parser that returns Parameter names or use a JSON parser that returns only the lexically
only the lexically last duplicate member name, as specified in last duplicate member name, as specified in Section 15.12 (The JSON
Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAScript]. 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 header parameters not defined by this Section 4.1.10, all Header Parameters not defined by this
specification MUST be ignored when not understood. specification MUST be ignored when not understood.
There are three classes of Header Parameter Names: Registered Header There are three classes of Header Parameter names: Registered 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. Registered Header Parameter Names 4.1. Registered Header Parameter Names
The following Header Parameter Names are registered in the IANA JSON The following Header Parameter names are registered in the IANA JSON
Web Signature and Encryption Header Parameters registry defined in Web Signature and Encryption Header Parameters registry defined in
Section 8.1, with meanings as defined below. Section 8.1, with meanings as defined below.
As indicated by the common registry, JWSs and JWEs share a common As indicated by the common registry, JWSs and JWEs share a common
header parameter space; when a parameter is used by both Header Parameter space; when a parameter is used by both
specifications, its usage must be compatible between the 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 the cryptographic
algorithm used to secure the JWS. The signature, MAC, or plaintext algorithm used to secure the JWS. The signature, MAC, or plaintext
value is not valid if the "alg" value does not represent a supported value is not valid if the "alg" value does not represent a supported
algorithm, or if there is not a key for use with that algorithm algorithm, or if there is not a key for use with that algorithm
associated with the party that digitally signed or MACed the content. associated with the party that digitally signed or MACed the content.
"alg" values SHOULD either be registered in the IANA JSON Web "alg" values SHOULD either be registered in the IANA JSON Web
Signature and Encryption Algorithms registry defined in [JWA] or be a Signature and Encryption Algorithms registry defined in [JWA] or be a
value that contains a Collision Resistant Name. The "alg" value is a value that contains a Collision Resistant Name. The "alg" value is a
case sensitive string containing a StringOrURI value. Use of this case sensitive string containing a StringOrURI value. Use of this
header parameter is REQUIRED. This header parameter MUST be Header Parameter is REQUIRED. This Header Parameter MUST be
understood and processed by implementations. understood and processed by implementations.
A list of defined "alg" values can be found in the IANA JSON Web A list of defined "alg" values for this use can be found in the IANA
Signature and Encryption Algorithms registry defined in [JWA]; the JSON Web Signature and Encryption Algorithms registry defined in
initial contents of this registry are the values defined in Section [JWA]; the initial contents of this registry are the values defined
3.1 of the JSON Web Algorithms (JWA) [JWA] specification. in Section 3.1 of 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 JWK Set MUST use TLS protection; an HTTP GET request to retrieve the JWK Set MUST use TLS
[RFC2818] [RFC5246]; the identity of the server MUST be validated, as [RFC2818] [RFC5246]; the identity of the server MUST be validated, as
per Section 3.1 of HTTP Over TLS [RFC2818]. Use of this header per Section 3.1 of HTTP Over TLS [RFC2818]. Use of 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
The "x5u" (X.509 URL) header parameter is a URI [RFC3986] that refers The "x5u" (X.509 URL) Header Parameter is a URI [RFC3986] that refers
to a resource for the X.509 public key certificate or certificate to a resource for the X.509 public key certificate or certificate
chain [RFC5280] corresponding to the key used to digitally sign the chain [RFC5280] corresponding to the key used to digitally sign the
JWS. The identified resource MUST provide a representation of the JWS. The identified resource MUST provide a representation of the
certificate or certificate chain that conforms to RFC 5280 [RFC5280] certificate or certificate chain that conforms to RFC 5280 [RFC5280]
in PEM encoded form [RFC1421]. The certificate containing the public in PEM encoded form [RFC1421]. The certificate containing the public
key corresponding to the key used to digitally sign the JWS MUST be key corresponding to the key used to digitally sign the JWS MUST be
the first certificate. This MAY be followed by additional the first certificate. This MAY be followed by additional
certificates, with each subsequent certificate being the one used to certificates, with each subsequent certificate being the one used to
certify the previous one. The protocol used to acquire the resource certify the previous one. The protocol used to acquire the resource
MUST provide integrity protection; an HTTP GET request to retrieve MUST provide integrity protection; an HTTP GET request to retrieve
the certificate MUST use TLS [RFC2818] [RFC5246]; the identity of the the certificate MUST use TLS [RFC2818] [RFC5246]; the identity of the
server MUST be validated, as per Section 3.1 of HTTP Over TLS server MUST be validated, as per Section 3.1 of HTTP Over TLS
[RFC2818]. Use of this header parameter is OPTIONAL. [RFC2818]. Use of this Header Parameter is OPTIONAL.
4.1.5. "x5t" (X.509 Certificate SHA-1 Thumbprint) Header Parameter 4.1.5. "x5t" (X.509 Certificate SHA-1 Thumbprint) Header Parameter
The "x5t" (X.509 Certificate SHA-1 Thumbprint) header parameter is a The "x5t" (X.509 Certificate SHA-1 Thumbprint) Header Parameter is a
base64url encoded SHA-1 thumbprint (a.k.a. digest) of the DER base64url encoded SHA-1 thumbprint (a.k.a. digest) of the DER
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
defined in Section 8.1. defined in 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
the public key corresponding to the key used to digitally sign the the public key corresponding to the key used to digitally sign the
JWS MUST be the first certificate. This MAY be followed by JWS MUST be the first certificate. This MAY be followed by
additional certificates, with each subsequent certificate being the additional certificates, with each subsequent certificate being the
one used to certify the previous one. The recipient MUST verify the one used to certify the previous one. The recipient MUST verify the
certificate chain according to [RFC5280] and reject the signature if certificate chain according to [RFC5280] and reject the signature if
any validation failure occurs. Use of this header parameter is any validation failure occurs. Use of this Header Parameter is
OPTIONAL. OPTIONAL.
See Appendix B for an example "x5c" value. See Appendix B for an example "x5c" value.
4.1.7. "kid" (Key ID) Header Parameter 4.1.7. "kid" (Key ID) Header Parameter
The "kid" (key ID) header parameter is a hint indicating which key The "kid" (key ID) Header Parameter is a hint indicating which key
was used to secure the JWS. This parameter allows originators to was used to secure the JWS. This parameter allows originators to
explicitly signal a change of key to recipients. Should the explicitly signal a change of key to recipients. Should the
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 is used to declare the MIME Media
complete JWS object in an application-specific manner in contexts Type [IANA.MediaTypes] of this complete JWS object in contexts where
where this is useful to the application. This parameter has no this is useful to the application. This parameter has no effect upon
effect upon the JWS processing. The type value "JOSE" can be used by the JWS processing. Use of this Header Parameter is OPTIONAL.
applications to indicate that this object is a JWS or JWE using the
JWS Compact Serialization or the JWE Compact Serialization. The type
value "JOSE+JSON" can be used by applications to indicate that this
object is a JWS or JWE using the JWS JSON Serialization or the JWE
JSON Serialization. Other type values can also be used by
applications. 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. When Per [RFC2045], all media type values, subtype values, and parameter
MIME Media Type values are used, it is RECOMMENDED that they be names are case-insensitive. However, parameter values are case-
spelled using the exact character case used in the MIME Media Types sensitive unless otherwise specified for the specific parameter.
registry [IANA.MediaTypes], since this field is case sensitive,
whereas MIME Media Type values are case insensitive.
"typ" values SHOULD either be registered in the IANA JSON Web To keep messages compact in common situations, it is RECOMMENDED that
Signature and Encryption Type Values registry defined in Section 8.2 senders omit an "application/" prefix of a media type value in a
or be a value that contains a Collision Resistant Name. "typ" Header Parameter when no other '/' appears in the media type
value. A recipient using the media type value MUST treat it as if
"application/" were prepended to any "typ" value not containing a
'/'. For instance, a "typ" value of "example" SHOULD be used to
represent the "application/example" media type.
The "typ" value "JOSE" can be used by applications to indicate that
this object is a JWS or JWE using the JWS Compact Serialization or
the JWE Compact Serialization. The "typ" value "JOSE+JSON" can be
used by applications to indicate that this object is a JWS or JWE
using the JWS JSON Serialization or the JWE JSON Serialization.
Other type values can also be used by applications.
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 is used to declare the MIME
of the secured content (the payload) in an application-specific Media Type [IANA.MediaTypes] of the secured content (the payload) in
manner in contexts where this is useful to the application. This contexts where this is useful to the application. This parameter has
parameter has no effect upon the JWS processing. The "cty" value is no effect upon the JWS processing. Use of this Header Parameter is
a case sensitive string. Use of this header parameter is OPTIONAL. OPTIONAL.
The values used for the "cty" header parameter come from the same Per [RFC2045], all media type values, subtype values, and parameter
value space as the "typ" header parameter, with the same rules names are case-insensitive. However, parameter values are case-
applying. sensitive unless otherwise specified for the specific parameter.
To keep messages compact in common situations, it is RECOMMENDED that
senders omit an "application/" prefix of a media type value in a
"cty" Header Parameter when no other '/' appears in the media type
value. A recipient using the media type value MUST treat it as if
"application/" were prepended to any "cty" value not containing a
'/'. For instance, a "cty" value of "example" SHOULD be used to
represent the "application/example" media type.
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 ]] or include Header Parameter names defined by [[ this specification ]] or
by [JWA] for use with JWS, duplicate names, or names that do not by [JWA] for use with JWS, duplicate names, or names that do not
occur as header parameter names within the JWS Header in the "crit" occur as Header Parameter names within the JWS Header in the "crit"
list. Senders MUST not use the empty list "[]" as the "crit" value. list. Senders MUST not use the empty list "[]" as the "crit" value.
Recipients MAY reject the JWS if the critical list contains any Recipients MAY reject the JWS if the critical list contains any
header parameter names defined by [[ this specification ]] or by Header Parameter names defined by [[ this specification ]] or by
[JWA] for use with JWS, or any other constraints on its use are [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 and processed by implementations. be understood and processed 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 defined in Section 8.1 or be a Encryption Header Parameters registry defined in Section 8.1 or be a
Public Name: a value that contains a Collision Resistant Name. In Public Name: a value that contains a Collision Resistant Name. In
each case, the definer of the name or value needs to take reasonable each case, the definer of the name or value needs to take reasonable
precautions to make sure they are in control of the part of the 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
A producer and consumer of a JWS may agree to use Header Parameter A producer and consumer of a JWS may agree to use Header Parameter
Names that are Private Names: names that are not Registered Header names that are Private Names: names that are not Registered Header
Parameter Names Section 4.1 or Public Header Parameter Names Parameter names Section 4.1 or Public Header Parameter names
Section 4.2. Unlike Public Header Parameter Names, Private Header Section 4.2. Unlike Public Header Parameter names, Private Header
Parameter Names are subject to collision and should be used with Parameter names are subject to collision and should be used with
caution. caution.
5. Producing and Consuming JWSs 5. Producing and Consuming JWSs
5.1. Message Signing or MACing 5.1. Message Signing or MACing
To create a JWS, one MUST perform these steps. The order of the To create a JWS, one MUST perform these steps. The order of the
steps is not significant in cases where there are no dependencies steps is not significant in cases where there are no dependencies
between the inputs and outputs of the steps. between the inputs and outputs of the steps.
1. Create the content to be used as the JWS Payload. 1. Create the content to be used as the JWS Payload.
2. Compute the encoded payload value BASE64URL(JWS Payload).
2. Base64url encode the octets of the JWS Payload. This encoding 3. Create a JWS Header containing the desired set of Header
becomes the Encoded JWS Payload. Parameters. Note that white space is explicitly allowed in the
3. Create a JWS Header containing the desired set of header
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. Compute the encoded header value BASE64URL(UTF8(JWS Protected
4. Base64url encode the octets of the UTF-8 representation of the Header)). If the JWS Protected Header is not present (which can
JWS Protected Header to create the Encoded JWS Header. If the only happen when using the JWS JSON Serialization and no
JWS Protected Header is not present (which can only happen when "protected" member is present), let this value be the empty
using the JWS JSON Serialization and no "protected" member is 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
concatenation of the Encoded JWS Header, a period ('.') ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' ||
character, and the Encoded JWS Payload). The "alg" (algorithm) BASE64URL(JWS Payload)). The "alg" (algorithm) Header Parameter
header parameter MUST be present in the JWS Header, with the MUST be present in the JWS Header, with the algorithm value
algorithm value accurately representing the algorithm used to accurately representing the algorithm used to construct the JWS
construct the JWS Signature. Signature.
6. Compute the encoded signature value BASE64URL(JWS Signature).
6. Base64url encode the representation of the JWS Signature to 7. These three encoded values are used in both the JWS Compact
create the Encoded JWS Signature. Serialization and the JWS JSON Serialization representations.
7. The three encoded parts are result values used in both the JWS
Compact Serialization and the JWS JSON Serialization
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 BASE64URL(UTF8(JWS Protected
JWS Header, the Encoded JWS Payload, and the Encoded JWS Header)) || '.' || BASE64URL(JWS Payload) || '.' || BASE64URL(JWS
Signature in that order, with the three strings being separated Signature). The JWS JSON Serialization is described in
by two period ('.') characters. The JWS JSON Serialization is Section 7.2.
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 signature or MAC cannot be the listed steps fails, then the signature or MAC cannot be
validated. validated.
It is an application decision which signatures, MACs, or plaintext It is an application decision which signatures, MACs, or plaintext
values must successfully validate for the JWS to be accepted. In values must successfully validate for the JWS to be accepted. In
some cases, all must successfully validate or the JWS will be some cases, all must successfully validate or the JWS will be
rejected. In other cases, only a specific signature, MAC, or rejected. In other cases, only a specific signature, MAC, or
plaintext value needs to be successfully validated. However, in all plaintext value needs to be successfully validated. However, in all
cases, at least one signature, MAC, or plaintext value MUST cases, at least one signature, MAC, or plaintext value MUST
successfully validate or the JWS MUST be rejected. successfully validate or the JWS MUST be rejected.
1. Parse the serialized input to determine the values of the JWS 1. Parse the JWS representation to extract the serialized values
Header, the Encoded JWS Payload, and the Encoded JWS Signature. for the components of the JWS -- when using the JWS Compact
When using the JWS Compact Serialization, the Encoded JWS Serialization, the base64url encoded representations of the JWS
Header, the Encoded JWS Payload, and the Encoded JWS Signature Protected Header, the JWS Payload, and the JWS Signature, and
are represented as text strings in that order, separated by two when using the JWS JSON Serialization, also the unencoded JWS
period ('.') characters. The JWS JSON Serialization is Unprotected Header value. When using the JWS Compact
described in Section 7.2. Serialization, the JWS Protected Header, the JWS Payload, and
the JWS Signature are represented as base64url encoded values in
2. The Encoded JWS Header MUST be successfully base64url decoded that order, separated by two period ('.') characters. The JWS
following the restriction given in this specification that no JSON Serialization is described in Section 7.2.
2. The encoded representation of the JWS Protected Header MUST be
successfully base64url decoded following the restriction that no
padding characters have been used. padding characters have been used.
3. The resulting UTF8 encoded JWS Protected Header MUST be a
3. Let the JWS Protected Header value be the result of base64url completely valid JSON object conforming to RFC 4627 [RFC4627].
decoding the Encoded JWS Header. 4. If using the JWS Compact Serialization, let the JWS Header be
4. The resulting JWS Protected Header MUST be a completely valid
JSON object conforming to RFC 4627 [RFC4627].
5. If using the JWS Compact Serialization, let the JWS Header be
the JWS Protected Header; otherwise, when using the JWS JSON the JWS Protected Header; otherwise, when using the JWS JSON
Serialization, let the JWS Header be the union of the members of Serialization, let the JWS Header be the union of the members of
the corresponding "protected" and "header" header parameter the corresponding JWS Protected Header and JWS Unprotected
values, all of which must be completely valid JSON objects. Header, all of which must be completely valid JSON objects.
5. The resulting JWS Header MUST NOT contain duplicate Header
6. The resulting JWS Header MUST NOT contain duplicate Header Parameter names. When using the JWS JSON Serialization, this
Parameter Names. When using the JWS JSON Serialization, this restriction includes that the same Header Parameter name also
restriction includes that the same Header Parameter Name also
MUST NOT occur in distinct JSON Text Object values that together MUST NOT occur in distinct JSON Text Object values that together
comprise the JWS Header. comprise the JWS Header.
6. The resulting JWS Header MUST be validated to only include
7. The resulting JWS Header MUST be validated to only include
parameters and values whose syntax and semantics are both parameters and values whose syntax and semantics are both
understood and supported or that are specified as being ignored understood and supported or that are specified as being ignored
when not understood. when not understood.
7. The encoded representation of the JWS Payload MUST be
8. The Encoded JWS Payload MUST be successfully base64url decoded successfully base64url decoded following the restriction that no
following the restriction given in this specification that no
padding characters have been used. padding characters have been used.
8. The encoded representation of the JWS Signature MUST be
9. The Encoded JWS Signature MUST be successfully base64url decoded successfully base64url decoded following the restriction that no
following the restriction given in this specification that no
padding characters have been used. padding characters have been used.
9. The JWS Signature MUST be successfully validated against the JWS
10. The JWS Signature MUST be successfully validated against the JWS Signing Input ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.'
Signing Input (the concatenation of the Encoded JWS Header, a || BASE64URL(JWS Payload)) in the manner defined for the
period ('.') character, and the Encoded JWS Payload) in the algorithm being used, which MUST be accurately represented by
manner defined for the algorithm being used, which MUST be the value of the "alg" (algorithm) Header Parameter, which MUST
accurately represented by the value of the "alg" (algorithm) be present.
header parameter, which MUST be present. 10. If the JWS JSON Serialization is being used, repeat this process
11. If the JWS JSON Serialization is being used, repeat this process
for each digital signature or MAC value contained in the for each digital signature or MAC value contained in the
representation. representation.
5.3. String Comparison Rules 5.3. String Comparison Rules
Processing a JWS inevitably requires comparing known strings to Processing a JWS inevitably requires comparing known strings to
values in JSON objects. For example, in checking what the algorithm values in JSON objects. For example, in checking what the algorithm
is, the Unicode string encoding "alg" will be checked against the is, the Unicode string encoding "alg" will be checked against the
member names in the JWS Header to see if there is a matching Header member names in the JWS Header to see if there is a matching Header
Parameter Name. A similar process occurs when determining if the Parameter name. A similar process occurs when determining if the
value of the "alg" header parameter represents a supported algorithm. value of the "alg" Header Parameter represents a supported algorithm.
Comparisons between JSON strings and other Unicode strings MUST be Comparisons between JSON strings and other Unicode strings MUST be
performed as specified below: performed as specified below:
1. Remove any JSON escaping from the input JSON string and convert 1. Remove any JSON escaping from the input JSON string and convert
the string into a sequence of Unicode code points. the string into a sequence of Unicode code points.
2. Likewise, convert the string to be compared against into a 2. Likewise, convert the string to be compared against into a
sequence of Unicode code points. sequence of Unicode code points.
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 9.2 and the Also, see the JSON security considerations in Section 9.2 and the
Unicode security considerations in Section 9.3. Unicode security considerations in Section 9.3.
6. Key Identification 6. Key Identification
skipping to change at page 15, line 48 skipping to change at page 16, line 43
Unicode security considerations in Section 9.3. Unicode security considerations in Section 9.3.
6. 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. These header parameters MUST be integrity to identify the key used. These Header Parameters MUST be integrity
protected if the information that they convey is to be utilized in a protected if the information that they convey is to be utilized in a
trust decision. trust decision.
The sender SHOULD include sufficient information in the Header The sender SHOULD include sufficient information in the Header
Parameters to identify the key used, unless the application uses Parameters to identify the key used, unless the application uses
another means or convention to determine the key used. Validation of another means or convention to determine the key used. Validation of
the signature or MAC fails when the algorithm used requires a key the signature or MAC fails when the algorithm used requires a key
(which is true of all algorithms except for "none") and the key used (which is true of all algorithms except for "none") and the key used
cannot be determined. cannot be determined.
The means of exchanging any shared symmetric keys used is outside the The means of exchanging any shared symmetric keys used is outside the
scope of this specification. scope of this specification.
7. Serializations 7. Serializations
JWS objects use one of two serializations, the JWS Compact JWS objects use one of two serializations, the JWS Compact
Serialization or the JWS JSON Serialization. The JWS Compact Serialization or the JWS JSON Serialization. For general-purpose
Serialization is mandatory to implement. Implementation of the JWS implementations, both the JWS Compact Serialization and JWS JSON
JSON Serialization is OPTIONAL. Serialization support for the single signature or MAC value case are
mandatory to implement; support for multiple signatures and/or MAC
values is OPTIONAL. Special-purpose implementations are permitted to
implement only a single serialization, if that meets the needs of the
targeted use cases.
7.1. JWS Compact Serialization 7.1. JWS Compact Serialization
The JWS Compact Serialization represents digitally signed or MACed The JWS Compact Serialization represents digitally signed or MACed
content as a compact URL-safe string. This string is the content as a compact URL-safe string. This string is
concatenation of the Encoded JWS Header, the Encoded JWS Payload, and BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS
the Encoded JWS Signature in that order, with the three strings being Payload) || '.' || BASE64URL(JWS Signature). Only one signature/MAC
separated by two period ('.') characters. Only one signature/MAC is is supported by the JWS Compact Serialization.
supported by the JWS Compact Serialization.
7.2. JWS JSON 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
skipping to change at page 16, line 41 skipping to change at page 17, line 39
7.2. JWS JSON 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:
o Values in the JWS JSON Serialization are represented as members of o Values in the JWS JSON Serialization are represented as members of
a JSON object, rather than as base64url encoded strings separated a JSON object, rather than as base64url encoded strings separated
by period ('.') characters. (However binary values and values by period ('.') characters. (However binary values and values
that are integrity protected are still base64url encoded.) that are integrity protected are still base64url encoded.)
o The value BASE64URL(JWS Payload) is stored in the "payload"
o The Encoded JWS Payload value is stored in the "payload" member. member.
o There can be multiple signature and/or MAC values, rather than o There can be multiple signature and/or MAC values, rather than
just one. A JSON array in the "signatures" member is used to hold just one. A JSON array in the "signatures" member is used to hold
values that are specific to a particular signature or MAC values that are specific to a particular signature or MAC
computation, with one array element per signature/MAC represented. computation, with one array element per signature/MAC represented.
These array elements are JSON objects. These array elements are JSON objects.
o Each Encoded JWS Signature value, if non-empty, is stored in the o Each value BASE64URL(JWS Signature), if non-empty, is stored in
"signature" member of a JSON object that is an element of the the "signature" member of a JSON object that is an element of the
"signatures" array. "signatures" array.
o Each value BASE64URL(UTF8(JWS Protected Header)), if non-empty, is
o Each Encoded JWS Header value, which is a base64url encoded set of stored in the "protected" member of the corresponding element of
header parameter values that are included in the signature/MAC the "signatures" array.
computation, if non-empty, is stored in the "protected" member of o Each JWS Unprotected Header value, if non-empty, is stored in the
the corresponding element of the "signatures" array. "header" member of the corresponding element of the "signatures"
array. If present, a JWS Unprotected Header value is represented
o Unlike the JWS Compact Serialization, in the JWS JSON as an unencoded JSON Text Object, rather than as a string.
Serialization there can also be header parameter values that are o The Header Parameter values used when creating or validating
not included in the signature/MAC computation. If present,
unprotected header parameter values are represented as an
unencoded JSON Text Object in the "header" member of the
corresponding element of the "signatures" array.
o The header parameter values used when creating or validating
individual signature or MAC values are the union of the two sets individual signature or MAC values are the union of the two sets
of header parameter values that may be present: (1) the integrity- of Header Parameter values that may be present: (1) the JWS
protected per-signature/MAC values represented in the "protected" Protected Header values represented in the "protected" member of
member of the signature/MAC's array element, and (2) the non- the signature/MAC's array element, and (2) the JWS Unprotected
integrity-protected per-signature/MAC values in the "header" Header values in the "header" member of the signature/MAC's array
member of the signature/MAC's array element. The union of these element. The union of these sets of Header Parameters comprises
sets of header parameters comprises the JWS Header. The header the JWS Header. The Header Parameter names in the two locations
parameter names in the two locations MUST be disjoint. MUST be disjoint.
The syntax of a JWS using the JWS JSON Serialization is as follows: The syntax of a JWS using the JWS JSON Serialization is as follows:
{ {
"payload":"<payload contents>" "payload":"<payload contents>"
"signatures":[ "signatures":[
{"protected":<integrity-protected header 1 contents>", {"protected":<integrity-protected header 1 contents>",
"header":"<non-integrity-protected header 1 contents>", "header":"<non-integrity-protected header 1 contents>",
"signature":"<signature 1 contents>"}, "signature":"<signature 1 contents>"},
... ...
{"protected":<integrity-protected header N contents>", {"protected":<integrity-protected header N contents>",
"header":"<non-integrity-protected header N contents>", "header":"<non-integrity-protected header N contents>",
"signature":"<signature N contents>"}], "signature":"<signature N contents>"}],
} }
Of these members, only the "payload", "signatures", and "signature" Of these members, only the "payload", "signatures", and "signature"
members MUST be present. At least one of the "protected" and members MUST be present. At least one of the "protected" and
"header" members MUST be present for each signature/MAC computation "header" members MUST be present for each signature/MAC computation
so that an "alg" header parameter value is conveyed. so that an "alg" Header Parameter value is conveyed.
The contents of the Encoded JWS Payload and Encoded JWS Signature The contents of the JWS Payload and JWS Signature values are exactly
values are exactly as defined in the rest of this specification. as defined in the rest of this specification. They are interpreted
They are interpreted and validated in the same manner, with each and validated in the same manner, with each corresponding JWS
corresponding Encoded JWS Signature and set of header parameter Signature and set of Header Parameter values being created and
values being created and validated together. The JWS Header values validated together. The JWS Header values used are the union of the
used are the union of the header parameters in the corresponding Header Parameters in the corresponding JWS Protected Header and JWS
"protected" and "header" members, as described earlier. Unprotected Header values, as described earlier.
Each JWS Signature value is computed on the JWS Signing Input using Each JWS Signature value is computed on the JWS Signing Input using
the parameters of the corresponding JWS Header value in the same the parameters of the corresponding JWS Header value in the same
manner as for the JWS Compact Serialization. This has the desirable manner as for the JWS Compact Serialization. This has the desirable
property that each Encoded JWS Signature value in the "signatures" property that each JWS Signature value represented in the
array is identical to the value that would have been computed for the "signatures" array is identical to the value that would have been
same parameter in the JWS Compact Serialization, provided that the computed for the same parameter in the JWS Compact Serialization,
Encoded JWS Header value for that signature/MAC computation (which provided that the JWS Protected Header value for that signature/MAC
represents the integrity-protected header parameter values) matches computation (which represents the integrity-protected Header
that used in the JWS Compact Serialization. Parameter values) matches that used in the JWS Compact 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.
8. IANA Considerations 8. 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
skipping to change at page 19, line 27 skipping to change at page 20, line 17
this specification, in order to enable broadly-informed review of this specification, in order to enable broadly-informed review of
registration decisions. In cases where a registration decision could registration decisions. In cases where a registration decision could
be perceived as creating a conflict of interest for a particular be perceived as creating a conflict of interest for a particular
Expert, that Expert should defer to the judgment of the other Expert, that Expert should defer to the judgment of the other
Expert(s). Expert(s).
8.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 JWS and JWE Header Encryption Header Parameters registry for JWS and JWE Header
Parameter Names. The registry records the Header Parameter Name and Parameter names. The registry records the Header Parameter name and
a reference to the specification that defines it. The same Header a reference to the specification that defines it. The same Header
Parameter Name MAY be registered multiple times, provided that the Parameter name MAY be registered multiple times, provided that the
parameter usage is compatible between the specifications. Different parameter usage is compatible between the specifications. Different
registrations of the same Header Parameter Name will typically use registrations of the same Header Parameter name will typically use
different Header Parameter Usage Location(s) values. different Header Parameter Usage Location(s) values.
8.1.1. Registration Template 8.1.1. Registration Template
Header Parameter Name: Header Parameter Name:
The name requested (e.g., "example"). Because a core goal of this The name requested (e.g., "example"). Because a core goal of this
specification is for the resulting representations to be compact, specification is for the resulting representations to be compact,
it is RECOMMENDED that the name be short -- not to exceed 8 it is RECOMMENDED that the name be short -- not to exceed 8
characters without a compelling reason to do so. This name is characters without a compelling reason to do so. This name is
case sensitive. Names may not match other registered names in a case sensitive. Names may not match other registered names in a
skipping to change at page 19, line 45 skipping to change at page 20, line 35
Header Parameter Name: Header Parameter Name:
The name requested (e.g., "example"). Because a core goal of this The name requested (e.g., "example"). Because a core goal of this
specification is for the resulting representations to be compact, specification is for the resulting representations to be compact,
it is RECOMMENDED that the name be short -- not to exceed 8 it is RECOMMENDED that the name be short -- not to exceed 8
characters without a compelling reason to do so. This name is characters without a compelling reason to do so. This name is
case sensitive. Names may not match other registered names in a case sensitive. Names may not match other registered names in a
case insensitive manner unless the Designated Expert(s) state that case insensitive manner unless the Designated Expert(s) state that
there is a compelling reason to allow an exception in this there is a compelling reason to allow an exception in this
particular case. particular case.
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".
Change Controller: Change Controller:
For Standards Track RFCs, state "IESG". For others, give the name For Standards Track RFCs, state "IESG". 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.
8.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: IESG o Change Controller: IESG
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: IESG o Change Controller: IESG
skipping to change at page 21, line 24 skipping to change at page 22, line 8
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: IESG o Change Controller: IESG
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: IESG o Change Controller: IESG
o Specification Document(s): Section 4.1.10 of [[ this document ]] o Specification Document(s): Section 4.1.10 of [[ this document ]]
8.2. JSON Web Signature and Encryption Type Values Registry 8.2. Media Type Registration
This specification establishes the IANA JSON Web Signature and
Encryption Type Values registry for values of the JWS and JWE "typ"
(type) header parameter. It is RECOMMENDED that all registered "typ"
values also include a MIME Media Type [RFC2046] value that the
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),
and a reference to the specification that defines it.
MIME Media Type [RFC2046] values MUST NOT be directly registered as
"typ" values; rather, "typ" values MAY be registered as short names
for MIME types.
8.2.1. Registration Template
"typ" Header Parameter Value:
The name requested (e.g., "example"). Because a core goal of this
specification is for the resulting representations to be compact,
it is RECOMMENDED that the name be short -- not to exceed 8
characters without a compelling reason to do so. This name is
case sensitive. Names may not match other registered names in a
case insensitive manner unless the Designated Expert(s) state that
there is a compelling reason to allow an exception in this
particular case.
Abbreviation for MIME Type:
The MIME type that this name is an abbreviation for (e.g.,
"application/example").
Change Controller:
For Standards Track RFCs, state "IESG". For others, give the name
of the responsible party. Other details (e.g., postal address,
email address, home page URI) may also be included.
Specification Document(s):
Reference to the document(s) that specify the parameter,
preferably including URI(s) that can be used to retrieve copies of
the document(s). An indication of the relevant sections may also
be included but is not required.
8.2.2. Initial Registry Contents
This specification registers the "JOSE" and "JOSE+JSON" type values
in this registry:
o "typ" Header Parameter Value: "JOSE"
o Abbreviation for MIME type: application/jose
o Change Controller: IESG
o Specification Document(s): Section 4.1.8 of [[ this document ]]
o "typ" Header Parameter Value: "JOSE+JSON"
o Abbreviation for MIME type: application/jose+json
o Change Controller: IESG
o Specification Document(s): Section 4.1.8 of [[ this document ]]
8.3. Media Type Registration
8.3.1. Registry Contents 8.2.1. Registry Contents
This specification registers the "application/jose" Media Type This specification registers the "application/jose" Media Type
[RFC2046] in the MIME Media Types registry [IANA.MediaTypes], which [RFC2046] in the MIME Media Types registry [IANA.MediaTypes], which
can be used to indicate that the content is a JWS or JWE object using can be used to indicate that the content is a JWS or JWE object using
the JWS Compact Serialization or the JWE Compact Serialization and the JWS Compact Serialization or the JWE Compact Serialization and
the "application/jose+json" Media Type in the MIME Media Types the "application/jose+json" Media Type in the MIME Media Types
registry, which can be used to indicate that the content is a JWS or 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 JWE object using the JWS JSON Serialization or the JWE JSON
Serialization. Serialization.
skipping to change at page 24, line 48 skipping to change at page 24, line 23
means of producing SHA-1 hash collisions be developed, and should an means of producing SHA-1 hash collisions be developed, and should an
attacker wish to interfere with the use of a known certificate on a attacker wish to interfere with the use of a known certificate on a
given system, this could be accomplished by creating another given system, this could be accomplished by creating another
certificate whose SHA-1 hash value is the same and adding it to the certificate whose SHA-1 hash value is the same and adding it to the
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.
9.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; recipients MUST either reject JWSs with this object MUST be unique; recipients MUST either reject JWSs with
duplicate Header Parameter Names or use a JSON parser that returns duplicate Header Parameter names or use a JSON parser that returns
only the lexically last duplicate member name, as specified in only the lexically last duplicate member name, as specified in
Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAScript]". Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAScript]".
Thus, this specification requires that the Section 2.2 "SHOULD" be 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 treated as a "MUST" by senders and that it be either treated as a
"MUST" or in the manner specified in ECMAScript 5.1 by receivers. "MUST" or in the manner specified in ECMAScript 5.1 by receivers.
Ambiguous and potentially exploitable situations could arise if the Ambiguous and potentially exploitable situations could arise if the
JSON parser used does not enforce the uniqueness of member names or JSON parser used does not enforce the uniqueness of member names or
returns an unpredictable value for duplicate member names. 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.
9.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
skipping to change at page 26, line 44 skipping to change at page 26, line 15
[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),
September 2013. October 2013.
[JWK] Jones, M., "JSON Web Key (JWK)", [JWK] Jones, M., "JSON Web Key (JWK)",
draft-ietf-jose-json-web-key (work in progress), draft-ietf-jose-json-web-key (work in progress),
September 2013. October 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.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[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", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
skipping to change at page 28, line 25 skipping to change at page 27, line 47
10.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), September 2013. (work in progress), October 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), July 2013. progress), October 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 29, line 9 skipping to change at page 28, line 30
Appendix A. JWS Examples Appendix A. JWS Examples
This section provides several examples of JWSs. While the first This section provides several examples of JWSs. While the first
three examples all represent JSON Web Tokens (JWTs) [JWT], the three examples all represent JSON Web Tokens (JWTs) [JWT], the
payload can be any octet sequence, as shown in Appendix A.4. payload can be any octet sequence, as shown in Appendix A.4.
A.1. Example JWS using HMAC SHA-256 A.1. Example JWS using HMAC SHA-256
A.1.1. Encoding A.1.1. Encoding
The following example JWS Header declares that the data structure is The following example JWS Protected Header declares that the data
a JSON Web Token (JWT) [JWT] and the JWS Signing Input is secured structure is a JSON Web Token (JWT) [JWT] and the JWS Signing Input
using the HMAC SHA-256 algorithm. is secured using the HMAC SHA-256 algorithm.
{"typ":"JWT", {"typ":"JWT",
"alg":"HS256"} "alg":"HS256"}
The following octet sequence contains the UTF-8 representation of the The octets representing UTF8(JWS Protected Header) in this case are:
JWS Header:
[123, 34, 116, 121, 112, 34, 58, 34, 74, 87, 84, 34, 44, 13, 10, 32, [123, 34, 116, 121, 112, 34, 58, 34, 74, 87, 84, 34, 44, 13, 10, 32,
34, 97, 108, 103, 34, 58, 34, 72, 83, 50, 53, 54, 34, 125] 34, 97, 108, 103, 34, 58, 34, 72, 83, 50, 53, 54, 34, 125]
Base64url encoding these octets yields this Encoded JWS Header value: Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected
Header)) gives this value:
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
The JWS Payload used in this example is the octets of the UTF-8 The JWS Payload used in this example is the octets of the UTF-8
representation of the JSON object below. (Note that the payload can representation of the JSON object below. (Note that the payload can
be any base64url encoded octet sequence, and need not be a base64url be any base64url encoded octet sequence, and need not be a base64url
encoded JSON object.) encoded JSON object.)
{"iss":"joe", {"iss":"joe",
"exp":1300819380, "exp":1300819380,
"http://example.com/is_root":true} "http://example.com/is_root":true}
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,
skipping to change at page 29, line 44 skipping to change at page 29, line 17
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 JWS Payload yields this Encoded JWS Payload Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected
value (with line breaks for display purposes only): Header)) gives this value (with line breaks for display purposes
only):
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
Concatenating the Encoded JWS Header, a period ('.') character, and Combining these as BASE64URL(UTF8(JWS Protected Header)) || '.' ||
the Encoded JWS Payload yields this JWS Signing Input value (with BASE64URL(JWS Payload) gives this string (with line breaks for
line breaks for display purposes only): display purposes only):
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
. .
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
The ASCII representation of the JWS Signing Input is the following The resulting JWS Signing Input value, which is the ASCII
octet sequence: representation of above string, is the following octet sequence:
[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 symmetric key HMACs are generated using keys. This example uses the symmetric key
represented in JSON Web Key [JWK] format below (with line breaks for represented in JSON Web Key [JWK] format below (with line breaks for
display purposes only): display purposes only):
{"kty":"oct", {"kty":"oct",
"k":"AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75 "k":"AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75
aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow" aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow"
} }
Running the HMAC SHA-256 algorithm on the octets of the ASCII Running the HMAC SHA-256 algorithm on the JWS Signing Input with this
representation of the JWS Signing Input with this key yields this key yields this JWS Signature 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 this Encoded JWS Encoding this JWS Signature as BASE64URL(JWS Signature) gives this
Signature value: 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
. .
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
. .
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
A.1.2. Decoding A.1.2. Validating
Decoding the JWS requires base64url decoding the Encoded JWS Header,
Encoded JWS Payload, and Encoded JWS Signature to produce the JWS
Header, JWS Payload, and JWS Signature octet sequences. The octet
sequence containing the UTF-8 representation of the JWS Header is
decoded into the JWS Header string.
A.1.3. Validating
Next we validate the decoded results. Since the "alg" parameter in
the header is "HS256", we validate the HMAC SHA-256 value contained
in the JWS Signature.
First, we validate that the JWS Header string is legal JSON. Since the "alg" Header Parameter is "HS256", we validate the HMAC
SHA-256 value contained in the JWS Signature.
To validate the HMAC value, we repeat the previous process of using To validate the HMAC value, we repeat the previous process of using
the correct key and the ASCII representation of the JWS Signing Input the correct key and the JWS Signing Input as input to the HMAC SHA-
as input to the HMAC SHA-256 function and then taking the output and 256 function and then taking the output and determining if it matches
determining if it matches the JWS Signature. If it matches exactly, the JWS Signature. If it matches exactly, the HMAC has been
the HMAC has been validated. validated.
A.2. Example JWS using RSASSA-PKCS-v1_5 SHA-256 A.2. Example JWS using RSASSA-PKCS-v1_5 SHA-256
A.2.1. Encoding A.2.1. Encoding
The JWS Header in this example is different from the previous example The JWS Protected Header in this example is different from the
in two ways: First, because a different algorithm is being used, the previous example in two ways: First, because a different algorithm is
"alg" value is different. Second, for illustration purposes only, being used, the "alg" value is different. Second, for illustration
the optional "typ" parameter is not used. (This difference is not purposes only, the optional "typ" parameter is not used. (This
related to the algorithm employed.) The JWS Header used is: difference is not related to the algorithm employed.) The JWS
Protected Header used is:
{"alg":"RS256"} {"alg":"RS256"}
The following octet sequence contains the UTF-8 representation of the The octets representing UTF8(JWS Protected Header) in this case are:
JWS Header:
[123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 50, 53, 54, 34, 125] [123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 50, 53, 54, 34, 125]
Base64url encoding these octets yields this Encoded JWS Header value: Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected
Header)) gives this value:
eyJhbGciOiJSUzI1NiJ9 eyJhbGciOiJSUzI1NiJ9
The JWS Payload used in this example, which follows, is the same as The JWS Payload used in this example, which follows, is the same as
in the previous example. Since the Encoded JWS Payload will in the previous example. Since the BASE64URL(JWS Payload) value will
therefore be the same, its computation is not repeated here. therefore be the same, its computation is not repeated here.
{"iss":"joe", {"iss":"joe",
"exp":1300819380, "exp":1300819380,
"http://example.com/is_root":true} "http://example.com/is_root":true}
Concatenating the Encoded JWS Header, a period ('.') character, and Combining these as BASE64URL(UTF8(JWS Protected Header)) || '.' ||
the Encoded JWS Payload yields this JWS Signing Input value (with BASE64URL(JWS Payload) gives this string (with line breaks for
line breaks for display purposes only): display purposes only):
eyJhbGciOiJSUzI1NiJ9 eyJhbGciOiJSUzI1NiJ9
. .
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
The ASCII representation of the JWS Signing Input is the following The resulting JWS Signing Input value, which is the ASCII
octet sequence: representation of above string, is the following 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]
skipping to change at page 33, line 4 skipping to change at page 32, line 19
SXndS5z5rexMdbBYUsLA9e-KXBdQOS-UTo7WTBEMa2R2CapHg665xsmtdV SXndS5z5rexMdbBYUsLA9e-KXBdQOS-UTo7WTBEMa2R2CapHg665xsmtdV
MTBQY4uDZlxvb3qCo5ZwKh9kG4LT6_I5IhlJH7aGhyxXFvUK-DWNmoudF8 MTBQY4uDZlxvb3qCo5ZwKh9kG4LT6_I5IhlJH7aGhyxXFvUK-DWNmoudF8
NAco9_h9iaGNj8q2ethFkMLs91kzk2PAcDTW9gb54h4FRWyuXpoQ", NAco9_h9iaGNj8q2ethFkMLs91kzk2PAcDTW9gb54h4FRWyuXpoQ",
"e":"AQAB", "e":"AQAB",
"d":"Eq5xpGnNCivDflJsRQBXHx1hdR1k6Ulwe2JZD50LpXyWPEAeP88vLNO97I "d":"Eq5xpGnNCivDflJsRQBXHx1hdR1k6Ulwe2JZD50LpXyWPEAeP88vLNO97I
jlA7_GQ5sLKMgvfTeXZx9SE-7YwVol2NXOoAJe46sui395IW_GO-pWJ1O0 jlA7_GQ5sLKMgvfTeXZx9SE-7YwVol2NXOoAJe46sui395IW_GO-pWJ1O0
BkTGoVEn2bKVRUCgu-GjBVaYLU6f3l9kJfFNS3E0QbVdxzubSu3Mkqzjkn BkTGoVEn2bKVRUCgu-GjBVaYLU6f3l9kJfFNS3E0QbVdxzubSu3Mkqzjkn
439X0M_V51gfpRLI9JYanrC4D4qAdGcopV_0ZHHzQlBjudU2QvXt4ehNYT 439X0M_V51gfpRLI9JYanrC4D4qAdGcopV_0ZHHzQlBjudU2QvXt4ehNYT
CBr6XCLQUShb1juUO1ZdiYoFaFQT5Tw8bGUl_x_jTj3ccPDVZFD9pIuhLh CBr6XCLQUShb1juUO1ZdiYoFaFQT5Tw8bGUl_x_jTj3ccPDVZFD9pIuhLh
BOneufuBiB4cS98l2SR_RQyGWSeWjnczT0QU91p1DhOVRuOopznQ" BOneufuBiB4cS98l2SR_RQyGWSeWjnczT0QU91p1DhOVRuOopznQ"
} }
The RSA private key is then passed to the RSA signing function, which The RSA private key is then passed to the RSA signing function, which
also takes the hash type, SHA-256, and the octets of the ASCII also takes the hash type, SHA-256, and 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,
48, 121, 91, 212, 189, 59, 65, 238, 202, 208, 102, 171, 101, 25, 129, 48, 121, 91, 212, 189, 59, 65, 238, 202, 208, 102, 171, 101, 25, 129,
253, 228, 141, 247, 127, 55, 45, 195, 139, 159, 175, 221, 59, 239, 253, 228, 141, 247, 127, 55, 45, 195, 139, 159, 175, 221, 59, 239,
177, 139, 93, 163, 204, 60, 46, 176, 47, 158, 58, 65, 214, 18, 202, 177, 139, 93, 163, 204, 60, 46, 176, 47, 158, 58, 65, 214, 18, 202,
173, 21, 145, 18, 115, 160, 95, 35, 185, 232, 56, 250, 175, 132, 157, 173, 21, 145, 18, 115, 160, 95, 35, 185, 232, 56, 250, 175, 132, 157,
105, 132, 41, 239, 90, 30, 136, 121, 130, 54, 195, 212, 14, 96, 69, 105, 132, 41, 239, 90, 30, 136, 121, 130, 54, 195, 212, 14, 96, 69,
34, 165, 68, 200, 242, 122, 122, 45, 184, 6, 99, 209, 108, 247, 202, 34, 165, 68, 200, 242, 122, 122, 45, 184, 6, 99, 209, 108, 247, 202,
234, 86, 222, 64, 92, 178, 33, 90, 69, 178, 194, 85, 102, 181, 90, 234, 86, 222, 64, 92, 178, 33, 90, 69, 178, 194, 85, 102, 181, 90,
193, 167, 72, 160, 112, 223, 200, 163, 42, 70, 149, 67, 208, 25, 238, 193, 167, 72, 160, 112, 223, 200, 163, 42, 70, 149, 67, 208, 25, 238,
251, 71] 251, 71]
Base64url encoding the digital signature produces this value for the Encoding the signature as BASE64URL(JWS Signature) produces this
Encoded JWS Signature (with line breaks for display purposes only): value (with line breaks for display purposes only):
cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZmh7 cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZmh7
AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjbKBYNX4 AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjbKBYNX4
BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHlb1L07Qe7K BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHlb1L07Qe7K
0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZESc6BfI7noOPqv 0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZESc6BfI7noOPqv
hJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AXLIhWkWywlVmtVrB hJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AXLIhWkWywlVmtVrB
p0igcN_IoypGlUPQGe77Rw p0igcN_IoypGlUPQGe77Rw
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
skipping to change at page 34, line 17 skipping to change at page 33, line 23
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
. .
cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZmh7 cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZmh7
AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjbKBYNX4 AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjbKBYNX4
BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHlb1L07Qe7K BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHlb1L07Qe7K
0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZESc6BfI7noOPqv 0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZESc6BfI7noOPqv
hJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AXLIhWkWywlVmtVrB hJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AXLIhWkWywlVmtVrB
p0igcN_IoypGlUPQGe77Rw p0igcN_IoypGlUPQGe77Rw
A.2.2. Decoding A.2.2. Validating
Decoding the JWS requires base64url decoding the Encoded JWS Header,
Encoded JWS Payload, and Encoded JWS Signature to produce the JWS
Header, JWS Payload, and JWS Signature octet sequences. The octet
sequence containing the UTF-8 representation of the JWS Header is
decoded into the JWS Header string.
A.2.3. Validating
Since the "alg" parameter in the header is "RS256", we validate the
RSASSA-PKCS-v1_5 SHA-256 digital signature contained in the JWS
Signature.
First, we validate that the JWS Header string is legal JSON. Since the "alg" Header Parameter is "RS256", we validate the RSASSA-
PKCS-v1_5 SHA-256 digital signature contained in the JWS Signature.
Validating the JWS Signature is a little different from the previous Validating the JWS Signature is a little different from the previous
example. First, we base64url decode the Encoded JWS Signature to example. We pass (n, e), JWS Signature, and the JWS Signing Input to
produce a digital signature S to check. We then pass (n, e), S and an RSASSA-PKCS-v1_5 signature verifier that has been configured to
the octets of the ASCII representation of the JWS Signing Input to an use the SHA-256 hash function.
RSASSA-PKCS-v1_5 signature verifier that has been configured to use
the SHA-256 hash function.
A.3. Example JWS using ECDSA P-256 SHA-256 A.3. Example JWS using ECDSA P-256 SHA-256
A.3.1. Encoding A.3.1. Encoding
The JWS Header for this example differs from the previous example The JWS Protected Header for this example differs from the previous
because a different algorithm is being used. The JWS Header used is: example because a different algorithm is being used. The JWS
Protected Header used is:
{"alg":"ES256"} {"alg":"ES256"}
The following octet sequence contains the UTF-8 representation of the The octets representing UTF8(JWS Protected Header) in this case are:
JWS Header:
[123, 34, 97, 108, 103, 34, 58, 34, 69, 83, 50, 53, 54, 34, 125] [123, 34, 97, 108, 103, 34, 58, 34, 69, 83, 50, 53, 54, 34, 125]
Base64url encoding these octets yields this Encoded JWS Header value:
Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected
Header)) gives this value:
eyJhbGciOiJFUzI1NiJ9 eyJhbGciOiJFUzI1NiJ9
The JWS Payload used in this example, which follows, is the same as The JWS Payload used in this example, which follows, is the same as
in the previous examples. Since the Encoded JWS Payload will in the previous examples. Since the BASE64URL(JWS Payload) value
therefore be the same, its computation is not repeated here. will therefore be the same, its computation is not repeated here.
{"iss":"joe", {"iss":"joe",
"exp":1300819380, "exp":1300819380,
"http://example.com/is_root":true} "http://example.com/is_root":true}
Concatenating the Encoded JWS Header, a period ('.') character, and Combining these as BASE64URL(UTF8(JWS Protected Header)) || '.' ||
the Encoded JWS Payload yields this JWS Signing Input value (with BASE64URL(JWS Payload) gives this string (with line breaks for
line breaks for display purposes only): display purposes only):
eyJhbGciOiJFUzI1NiJ9 eyJhbGciOiJFUzI1NiJ9
. .
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
The ASCII representation of the JWS Signing Input is the following The resulting JWS Signing Input value, which is the ASCII
octet sequence: representation of above string, is the following octet sequence:
[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]
skipping to change at page 35, line 49 skipping to change at page 34, line 46
{"kty":"EC", {"kty":"EC",
"crv":"P-256", "crv":"P-256",
"x":"f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU", "x":"f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
"y":"x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0", "y":"x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0",
"d":"jpsQnnGQmL-YBIffH1136cspYG6-0iY7X1fCE9-E9LI" "d":"jpsQnnGQmL-YBIffH1136cspYG6-0iY7X1fCE9-E9LI"
} }
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 JWS Signing Input as inputs. The result of the digital signature
inputs. The result of the digital signature is the EC point (R, S), is the EC point (R, S), where R and S are unsigned integers. In this
where R and S are unsigned integers. In this example, the R and S example, the R and S values, given as octet sequences representing
values, given as octet sequences representing big endian integers big endian integers are:
are:
+--------+----------------------------------------------------------+ +--------+----------------------------------------------------------+
| Result | Value | | Result | Value |
| Name | | | Name | |
+--------+----------------------------------------------------------+ +--------+----------------------------------------------------------+
| R | [14, 209, 33, 83, 121, 99, 108, 72, 60, 47, 127, 21, 88, | | R | [14, 209, 33, 83, 121, 99, 108, 72, 60, 47, 127, 21, 88, |
| | 7, 212, 2, 163, 178, 40, 3, 58, 249, 124, 126, 23, 129, | | | 7, 212, 2, 163, 178, 40, 3, 58, 249, 124, 126, 23, 129, |
| | 154, 195, 22, 158, 166, 101] | | | 154, 195, 22, 158, 166, 101] |
| S | [197, 10, 7, 211, 140, 60, 112, 229, 216, 241, 45, 175, | | S | [197, 10, 7, 211, 140, 60, 112, 229, 216, 241, 45, 175, |
| | 8, 74, 84, 128, 166, 101, 144, 197, 242, 147, 80, 154, | | | 8, 74, 84, 128, 166, 101, 144, 197, 242, 147, 80, 154, |
| | 143, 63, 127, 138, 131, 163, 84, 213] | | | 143, 63, 127, 138, 131, 163, 84, 213] |
+--------+----------------------------------------------------------+ +--------+----------------------------------------------------------+
Concatenating the S array to the end of the R array and base64url The JWS Signature is the value R || S. Encoding the signature as
encoding the result produces this value for the Encoded JWS Signature BASE64URL(JWS Signature) produces this value (with line breaks for
(with line breaks for display purposes only): display purposes only):
DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSA DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSA
pmWQxfKTUJqPP3-Kg6NU1Q pmWQxfKTUJqPP3-Kg6NU1Q
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):
eyJhbGciOiJFUzI1NiJ9 eyJhbGciOiJFUzI1NiJ9
. .
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
. .
DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSA DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSA
pmWQxfKTUJqPP3-Kg6NU1Q pmWQxfKTUJqPP3-Kg6NU1Q
A.3.2. Decoding A.3.2. Validating
Decoding the JWS requires base64url decoding the Encoded JWS Header,
Encoded JWS Payload, and Encoded JWS Signature to produce the JWS
Header, JWS Payload, and JWS Signature octet sequences. The octet
sequence containing the UTF-8 representation of the JWS Header is
decoded into the JWS Header string.
A.3.3. Validating
Since the "alg" parameter in the header is "ES256", we validate the
ECDSA P-256 SHA-256 digital signature contained in the JWS Signature.
First, we validate that the JWS Header string is legal JSON. Since the "alg" Header Parameter is "ES256", we validate the ECDSA
P-256 SHA-256 digital signature contained in the JWS Signature.
Validating the JWS Signature is a little different from the first Validating the JWS Signature is a little different from the first
example. First, we base64url decode the Encoded JWS Signature as in example. We need to split the 64 member octet sequence of the JWS
the previous examples but we then need to split the 64 member octet Signature into two 32 octet sequences, the first R and the second S.
sequence that must result into two 32 octet sequences, the first R We then pass (x, y), (R, S) and the JWS Signing Input to an ECDSA
and the second S. We then pass (x, y), (R, S) and the octets of the signature verifier that has been configured to use the P-256 curve
ASCII representation of the JWS Signing Input to an ECDSA signature with the SHA-256 hash function.
verifier that has been configured to use the P-256 curve with the
SHA-256 hash function.
A.4. Example JWS using ECDSA P-521 SHA-512 A.4. Example JWS using ECDSA P-521 SHA-512
A.4.1. Encoding A.4.1. Encoding
The JWS Header for this example differs from the previous example The JWS Protected Header for this example differs from the previous
because different ECDSA curves and hash functions are used. The JWS example because different ECDSA curves and hash functions are used.
Header used is: The JWS Protected Header used is:
{"alg":"ES512"} {"alg":"ES512"}
The following octet sequence contains the UTF-8 representation of the The octets representing UTF8(JWS Protected Header) in this case are:
JWS Header:
[123, 34, 97, 108, 103, 34, 58, 34, 69, 83, 53, 49, 50, 34, 125] [123, 34, 97, 108, 103, 34, 58, 34, 69, 83, 53, 49, 50, 34, 125]
Base64url encoding these octets yields this Encoded JWS Header value: Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected
Header)) gives this 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 this Encoded JWS Payload Encoding this JWS Payload as BASE64URL(JWS Payload) gives this value:
value:
UGF5bG9hZA UGF5bG9hZA
Concatenating the Encoded JWS Header, a period ('.') character, and Combining these as BASE64URL(UTF8(JWS Protected Header)) || '.' ||
the Encoded JWS Payload yields this JWS Signing Input value: BASE64URL(JWS Payload) gives this string (with line breaks for
display purposes only):
eyJhbGciOiJFUzUxMiJ9.UGF5bG9hZA eyJhbGciOiJFUzUxMiJ9.UGF5bG9hZA
The ASCII representation of the JWS Signing Input is the following The resulting JWS Signing Input value, which is the ASCII
octet sequence: representation of above string, is the following 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]
This example uses the elliptic curve key represented in JSON Web Key This example uses the elliptic curve key represented in JSON Web Key
[JWK] format below (with line breaks for display purposes only): [JWK] format below (with line breaks for display purposes only):
{"kty":"EC", {"kty":"EC",
"crv":"P-521", "crv":"P-521",
"x":"AekpBQ8ST8a8VcfVOTNl353vSrDCLLJXmPk06wTjxrrjcBpXp5EOnYG_ "x":"AekpBQ8ST8a8VcfVOTNl353vSrDCLLJXmPk06wTjxrrjcBpXp5EOnYG_
NjFZ6OvLFV1jSfS9tsz4qUxcWceqwQGk", NjFZ6OvLFV1jSfS9tsz4qUxcWceqwQGk",
"y":"ADSmRA43Z1DSNx_RvcLI87cdL07l6jQyyBXMoxVg_l2Th-x3S1WDhjDl "y":"ADSmRA43Z1DSNx_RvcLI87cdL07l6jQyyBXMoxVg_l2Th-x3S1WDhjDl
y79ajL4Kkd0AZMaZmh9ubmf63e3kyMj2", y79ajL4Kkd0AZMaZmh9ubmf63e3kyMj2",
"d":"AY5pb7A0UFiB3RELSD64fTLOSV_jazdF7fLYyuTw8lOfRhWg6Y6rUrPA "d":"AY5pb7A0UFiB3RELSD64fTLOSV_jazdF7fLYyuTw8lOfRhWg6Y6rUrPA
xerEzgdRhajnu0ferB0d53vM9mE15j2C" xerEzgdRhajnu0ferB0d53vM9mE15j2C"
} }
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 JWS Signing Input as inputs. The result of the digital signature
inputs. The result of the digital signature is the EC point (R, S), is the EC point (R, S), where R and S are unsigned integers. In this
where R and S are unsigned integers. In this example, the R and S example, the R and S values, given as octet sequences representing
values, given as octet sequences representing big endian integers big endian integers are:
are:
+--------+----------------------------------------------------------+ +--------+----------------------------------------------------------+
| Result | Value | | Result | Value |
| Name | | | Name | |
+--------+----------------------------------------------------------+ +--------+----------------------------------------------------------+
| R | [1, 220, 12, 129, 231, 171, 194, 209, 232, 135, 233, | | R | [1, 220, 12, 129, 231, 171, 194, 209, 232, 135, 233, |
| | 117, 247, 105, 122, 210, 26, 125, 192, 1, 217, 21, 82, | | | 117, 247, 105, 122, 210, 26, 125, 192, 1, 217, 21, 82, |
| | 91, 45, 240, 255, 83, 19, 34, 239, 71, 48, 157, 147, | | | 91, 45, 240, 255, 83, 19, 34, 239, 71, 48, 157, 147, |
| | 152, 105, 18, 53, 108, 163, 214, 68, 231, 62, 153, 150, | | | 152, 105, 18, 53, 108, 163, 214, 68, 231, 62, 153, 150, |
| | 106, 194, 164, 246, 72, 143, 138, 24, 50, 129, 223, 133, | | | 106, 194, 164, 246, 72, 143, 138, 24, 50, 129, 223, 133, |
| | 206, 209, 172, 63, 237, 119, 109] | | | 206, 209, 172, 63, 237, 119, 109] |
| S | [0, 111, 6, 105, 44, 5, 41, 208, 128, 61, 152, 40, 92, | | S | [0, 111, 6, 105, 44, 5, 41, 208, 128, 61, 152, 40, 92, |
| | 61, 152, 4, 150, 66, 60, 69, 247, 196, 170, 81, 193, | | | 61, 152, 4, 150, 66, 60, 69, 247, 196, 170, 81, 193, |
| | 199, 78, 59, 194, 169, 16, 124, 9, 143, 42, 142, 131, | | | 199, 78, 59, 194, 169, 16, 124, 9, 143, 42, 142, 131, |
| | 48, 206, 238, 34, 175, 83, 203, 220, 159, 3, 107, 155, | | | 48, 206, 238, 34, 175, 83, 203, 220, 159, 3, 107, 155, |
| | 22, 27, 73, 111, 68, 68, 21, 238, 144, 229, 232, 148, | | | 22, 27, 73, 111, 68, 68, 21, 238, 144, 229, 232, 148, |
| | 188, 222, 59, 242, 103] | | | 188, 222, 59, 242, 103] |
+--------+----------------------------------------------------------+ +--------+----------------------------------------------------------+
Concatenating the S array to the end of the R array and base64url The JWS Signature is the value R || S. Encoding the signature as
encoding the result produces this value for the Encoded JWS Signature BASE64URL(JWS Signature) produces this value (with line breaks for
(with line breaks for display purposes only): display purposes only):
AdwMgeerwtHoh-l192l60hp9wAHZFVJbLfD_UxMi70cwnZOYaRI1bKPWROc-mZZq AdwMgeerwtHoh-l192l60hp9wAHZFVJbLfD_UxMi70cwnZOYaRI1bKPWROc-mZZq
wqT2SI-KGDKB34XO0aw_7XdtAG8GaSwFKdCAPZgoXD2YBJZCPEX3xKpRwcdOO8Kp wqT2SI-KGDKB34XO0aw_7XdtAG8GaSwFKdCAPZgoXD2YBJZCPEX3xKpRwcdOO8Kp
EHwJjyqOgzDO7iKvU8vcnwNrmxYbSW9ERBXukOXolLzeO_Jn EHwJjyqOgzDO7iKvU8vcnwNrmxYbSW9ERBXukOXolLzeO_Jn
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):
eyJhbGciOiJFUzUxMiJ9 eyJhbGciOiJFUzUxMiJ9
. .
UGF5bG9hZA UGF5bG9hZA
. .
AdwMgeerwtHoh-l192l60hp9wAHZFVJbLfD_UxMi70cwnZOYaRI1bKPWROc-mZZq AdwMgeerwtHoh-l192l60hp9wAHZFVJbLfD_UxMi70cwnZOYaRI1bKPWROc-mZZq
wqT2SI-KGDKB34XO0aw_7XdtAG8GaSwFKdCAPZgoXD2YBJZCPEX3xKpRwcdOO8Kp wqT2SI-KGDKB34XO0aw_7XdtAG8GaSwFKdCAPZgoXD2YBJZCPEX3xKpRwcdOO8Kp
EHwJjyqOgzDO7iKvU8vcnwNrmxYbSW9ERBXukOXolLzeO_Jn EHwJjyqOgzDO7iKvU8vcnwNrmxYbSW9ERBXukOXolLzeO_Jn
A.4.2. Decoding A.4.2. Validating
Decoding the JWS requires base64url decoding the Encoded JWS Header,
Encoded JWS Payload, and Encoded JWS Signature to produce the JWS
Header, JWS Payload, and JWS Signature octet sequences. The octet
sequence containing the UTF-8 representation of the JWS Header is
decoded into the JWS Header string.
A.4.3. Validating
Since the "alg" parameter in the header is "ES512", we validate the
ECDSA P-521 SHA-512 digital signature contained in the JWS Signature.
First, we validate that the JWS Header string is legal JSON. Since the "alg" Header Parameter is "ES512", we validate the ECDSA
P-521 SHA-512 digital signature contained in the JWS Signature.
Validating the JWS Signature is similar to the previous example. Validating the JWS Signature is similar to the previous example. We
First, we base64url decode the Encoded JWS Signature as in the need to split the 132 member octet sequence of the JWS Signature into
previous examples but we then need to split the 132 member octet two 66 octet sequences, the first R and the second S. We then pass
sequence that must result into two 66 octet sequences, the first R (x, y), (R, S) and the JWS Signing Input to an ECDSA signature
and the second S. We then pass (x, y), (R, S) and the octets of the
ASCII representation of the JWS Signing Input to an ECDSA signature
verifier that has been configured to use the P-521 curve with the verifier that has been configured to use the P-521 curve with the
SHA-512 hash function. SHA-512 hash function.
A.5. Example Plaintext JWS A.5. Example Plaintext JWS
The following example JWS Header declares that the encoded object is The following example JWS Protected Header declares that the encoded
a Plaintext JWS: object is a Plaintext JWS:
{"alg":"none"} {"alg":"none"}
Base64url encoding the octets of the UTF-8 representation of the JWS Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected
Header yields this Encoded JWS Header: Header)) gives this value:
eyJhbGciOiJub25lIn0 eyJhbGciOiJub25lIn0
The JWS Payload used in this example, which follows, is the same as The JWS Payload used in this example, which follows, is the same as
in the previous examples. Since the Encoded JWS Payload will in the previous examples. Since the BASE64URL(JWS Payload) value
therefore be the same, its computation is not repeated here. will therefore be the same, its computation is not repeated here.
{"iss":"joe", {"iss":"joe",
"exp":1300819380, "exp":1300819380,
"http://example.com/is_root":true} "http://example.com/is_root":true}
The Encoded JWS Signature is the empty string. The JWS Signature is the empty octet string and BASE64URL(JWS
Signature) is the empty string.
Concatenating these parts in the order Header.Payload.Signature with Concatenating these parts 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
(with line breaks for display purposes only): (with line breaks for display purposes only):
eyJhbGciOiJub25lIn0 eyJhbGciOiJub25lIn0
. .
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
. .
A.6. Example JWS Using JWS JSON Serialization A.6. Example JWS Using JWS JSON Serialization
This section contains an example using the JWS JSON Serialization. This section contains an example using the JWS JSON Serialization.
This example demonstrates the capability for conveying multiple This example demonstrates the capability for conveying multiple
digital signatures and/or MACs for the same payload. digital signatures and/or MACs for the same payload.
The Encoded JWS Payload used in this example is the same as that used The JWS Payload used in this example is the same as that used in the
in the examples in Appendix A.2 and Appendix A.3 (with line breaks examples in Appendix A.2 and Appendix A.3 (with line breaks for
for display purposes only): display purposes only):
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
Two digital signatures are used in this example: the first using Two digital signatures are used in this example: the first using
RSASSA-PKCS-v1_5 SHA-256 and the second using ECDSA P-256 SHA-256. RSASSA-PKCS-v1_5 SHA-256 and the second using ECDSA P-256 SHA-256.
For the first, the JWS Protected Header and key are the same as in For the first, the JWS Protected Header and key are the same as in
Appendix A.2, resulting in the same JWS Signature value; therefore, Appendix A.2, resulting in the same JWS Signature value; therefore,
its computation is not repeated here. For the second, the JWS its computation is not repeated here. For the second, the JWS
Protected Header and key are the same as in Appendix A.3, resulting Protected Header and key are the same as in Appendix A.3, resulting
in the same JWS Signature value; therefore, its computation is not in the same JWS Signature value; therefore, its computation is not
repeated here. repeated here.
A.6.1. JWS Per-Signature Protected Headers A.6.1. JWS Per-Signature Protected Headers
The JWS Protected Header value used for the first signature is: The JWS Protected Header value used for the first signature is:
{"alg":"RS256"} {"alg":"RS256"}
Base64url encoding these octets yields this Encoded JWS Header value: Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected
Header)) gives this value:
eyJhbGciOiJSUzI1NiJ9 eyJhbGciOiJSUzI1NiJ9
The JWS Protected Header value used for the second signature is: The JWS Protected Header value used for the second signature is:
{"alg":"ES256"} {"alg":"ES256"}
Base64url encoding these octets yields this Encoded JWS Header value: Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected
Header)) gives this value:
eyJhbGciOiJFUzI1NiJ9 eyJhbGciOiJFUzI1NiJ9
A.6.2. JWS Per-Signature Unprotected Headers A.6.2. JWS Per-Signature Unprotected Headers
Key ID values are supplied for both keys using per-signature header Key ID values are supplied for both keys using per-signature Header
parameters. The two values used to represent these Key IDs are: Parameters. The two values used to represent these Key IDs are:
{"kid":"2010-12-29"} {"kid":"2010-12-29"}
and and
{"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"} {"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"}
A.6.3. Complete JWS Header Values A.6.3. Complete JWS Header Values
Combining the protected and unprotected header values supplied, the Combining the protected and unprotected header values supplied, the
skipping to change at page 42, line 30 skipping to change at page 41, line 30
"header": "header":
{"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"}, {"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"},
"signature": "signature":
"DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8IS "DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8IS
lSApmWQxfKTUJqPP3-Kg6NU1Q"}] lSApmWQxfKTUJqPP3-Kg6NU1Q"}]
} }
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
xITAfBgNVBAoTGFRoZSBHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR2 xITAfBgNVBAoTGFRoZSBHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR2
8gRGFkZHkgQ2xhc3MgMiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNjExM 8gRGFkZHkgQ2xhc3MgMiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNjExM
TYwMTU0MzdaFw0yNjExMTYwMTU0MzdaMIHKMQswCQYDVQQGEwJVUzEQMA4GA1UE TYwMTU0MzdaFw0yNjExMTYwMTU0MzdaMIHKMQswCQYDVQQGEwJVUzEQMA4GA1UE
CBMHQXJpem9uYTETMBEGA1UEBxMKU2NvdHRzZGFsZTEaMBgGA1UEChMRR29EYWR CBMHQXJpem9uYTETMBEGA1UEBxMKU2NvdHRzZGFsZTEaMBgGA1UEChMRR29EYWR
keS5jb20sIEluYy4xMzAxBgNVBAsTKmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYW keS5jb20sIEluYy4xMzAxBgNVBAsTKmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYW
RkeS5jb20vcmVwb3NpdG9yeTEwMC4GA1UEAxMnR28gRGFkZHkgU2VjdXJlIENlc RkeS5jb20vcmVwb3NpdG9yeTEwMC4GA1UEAxMnR28gRGFkZHkgU2VjdXJlIENlc
skipping to change at page 45, line 18 skipping to change at page 44, line 18
follows. The octet sequence below encodes into the string below, follows. The octet sequence below encodes into the string below,
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.invalid/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.invalid/UNDEFINED" is substituted for any other "http://example.invalid/UNDEFINED" is substituted for any other
header parameter name not understood by the implementation, must also Header Parameter name not understood by the implementation, must also
be rejected. be rejected.
The JWS Header value for this JWS is: The JWS Protected Header value for this JWS is:
{"alg":"none", {"alg":"none",
"crit":["http://example.invalid/UNDEFINED"], "crit":["http://example.invalid/UNDEFINED"],
"http://example.invalid/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
skipping to change at page 46, line 21 skipping to change at page 45, 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 ]]
-17
o Refined the "typ" and "cty" definitions to always be MIME Media
Types, with the omission of "application/" prefixes recommended
for brevity, addressing issue #50.
o Updated the mandatory-to-implement (MTI) language to say that
general-purpose implementations must implement the single
signature/MAC value case for both serializations whereas special-
purpose implementations can implement just one serialization if
that meets the needs of the use cases the implementation is
designed for, addressing issue #119.
o Explicitly named all the logical components of a JWS and defined
the processing rules and serializations in terms of those
components, addressing issues #60, #61, and #62.
o Replaced verbose repetitive phases such as "base64url encode the
octets of the UTF-8 representation of X" with mathematical
notation such as "BASE64URL(UTF8(X))".
o Terms used in multiple documents are now defined in one place and
incorporated by reference. Some lightly used or obvious terms
were also removed. This addresses issue #58.
-16 -16
o Changes to address editorial and minor issues #50, #98, #99, #102, o Changes to address editorial and minor issues #50, #98, #99, #102,
#104, #106, #107, #111, and #112. #104, #106, #107, #111, and #112.
-15 -15
o Clarified that it is an application decision which signatures, o Clarified that it is an application decision which signatures,
MACs, or plaintext values must successfully validate for the JWS MACs, or plaintext values must successfully validate for the JWS
to be accepted, addressing issue #35. to be accepted, addressing issue #35.
 End of changes. 176 change blocks. 
580 lines changed or deleted 521 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/