draft-ietf-jose-json-web-signature-34.txt   draft-ietf-jose-json-web-signature-35.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: April 17, 2015 Ping Identity Expires: April 20, 2015 Ping Identity
N. Sakimura N. Sakimura
NRI NRI
October 14, 2014 October 17, 2014
JSON Web Signature (JWS) JSON Web Signature (JWS)
draft-ietf-jose-json-web-signature-34 draft-ietf-jose-json-web-signature-35
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 April 17, 2015. This Internet-Draft will expire on April 20, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 41 skipping to change at page 2, line 41
Header Parameter . . . . . . . . . . . . . . . . . . . 12 Header Parameter . . . . . . . . . . . . . . . . . . . 12
4.1.9. "typ" (Type) Header Parameter . . . . . . . . . . . . 12 4.1.9. "typ" (Type) Header Parameter . . . . . . . . . . . . 12
4.1.10. "cty" (Content Type) Header Parameter . . . . . . . . 13 4.1.10. "cty" (Content Type) Header Parameter . . . . . . . . 13
4.1.11. "crit" (Critical) Header Parameter . . . . . . . . . . 13 4.1.11. "crit" (Critical) Header Parameter . . . . . . . . . . 13
4.2. Public Header Parameter Names . . . . . . . . . . . . . . 14 4.2. Public Header Parameter Names . . . . . . . . . . . . . . 14
4.3. Private Header Parameter Names . . . . . . . . . . . . . 14 4.3. Private Header Parameter Names . . . . . . . . . . . . . 14
5. Producing and Consuming JWSs . . . . . . . . . . . . . . . . . 14 5. Producing and Consuming JWSs . . . . . . . . . . . . . . . . . 14
5.1. Message Signature or MAC Computation . . . . . . . . . . 14 5.1. Message Signature or MAC Computation . . . . . . . . . . 14
5.2. Message Signature or MAC Validation . . . . . . . . . . . 15 5.2. Message Signature or MAC Validation . . . . . . . . . . . 15
5.3. String Comparison Rules . . . . . . . . . . . . . . . . . 17 5.3. String Comparison Rules . . . . . . . . . . . . . . . . . 17
6. Key Identification . . . . . . . . . . . . . . . . . . . . . . 17 6. Key Identification . . . . . . . . . . . . . . . . . . . . . . 18
7. Serializations . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Serializations . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. JWS Compact Serialization . . . . . . . . . . . . . . . . 18 7.1. JWS Compact Serialization . . . . . . . . . . . . . . . . 19
7.2. JWS JSON Serialization . . . . . . . . . . . . . . . . . 18 7.2. JWS JSON Serialization . . . . . . . . . . . . . . . . . 19
8. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . . 20 8. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9.1. JSON Web Signature and Encryption Header Parameters 9.1. JSON Web Signature and Encryption Header Parameters
Registry . . . . . . . . . . . . . . . . . . . . . . . . 22 Registry . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1.1. Registration Template . . . . . . . . . . . . . . . . 22 9.1.1. Registration Template . . . . . . . . . . . . . . . . 23
9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 23 9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 23
9.2. Media Type Registration . . . . . . . . . . . . . . . . . 24 9.2. Media Type Registration . . . . . . . . . . . . . . . . . 25
9.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 24 9.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10.1. Key Entropy and Random Values . . . . . . . . . . . . . . 26 10.1. Key Entropy and Random Values . . . . . . . . . . . . . . 26
10.2. Key Protection . . . . . . . . . . . . . . . . . . . . . 26 10.2. Key Protection . . . . . . . . . . . . . . . . . . . . . 27
10.3. Key Origin Authentication . . . . . . . . . . . . . . . . 27 10.3. Key Origin Authentication . . . . . . . . . . . . . . . . 27
10.4. Cryptographic Agility . . . . . . . . . . . . . . . . . . 27 10.4. Cryptographic Agility . . . . . . . . . . . . . . . . . . 27
10.5. Differences between Digital Signatures and MACs . . . . . 27 10.5. Differences between Digital Signatures and MACs . . . . . 27
10.6. Algorithm Validation . . . . . . . . . . . . . . . . . . 27 10.6. Algorithm Validation . . . . . . . . . . . . . . . . . . 28
10.7. Algorithm Protection . . . . . . . . . . . . . . . . . . 28 10.7. Algorithm Protection . . . . . . . . . . . . . . . . . . 28
10.8. Chosen Plaintext Attacks . . . . . . . . . . . . . . . . 28 10.8. Chosen Plaintext Attacks . . . . . . . . . . . . . . . . 29
10.9. Timing Attacks . . . . . . . . . . . . . . . . . . . . . 29 10.9. Timing Attacks . . . . . . . . . . . . . . . . . . . . . 29
10.10. Replay Protection . . . . . . . . . . . . . . . . . . . . 29 10.10. Replay Protection . . . . . . . . . . . . . . . . . . . . 29
10.11. SHA-1 Certificate Thumbprints . . . . . . . . . . . . . . 29 10.11. SHA-1 Certificate Thumbprints . . . . . . . . . . . . . . 29
10.12. JSON Security Considerations . . . . . . . . . . . . . . 29 10.12. JSON Security Considerations . . . . . . . . . . . . . . 30
10.13. Unicode Comparison Security Considerations . . . . . . . 30 10.13. Unicode Comparison Security Considerations . . . . . . . 30
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . 30 11.1. Normative References . . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . 32 11.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. JWS Examples . . . . . . . . . . . . . . . . . . . . 33 Appendix A. JWS Examples . . . . . . . . . . . . . . . . . . . . 34
A.1. Example JWS using HMAC SHA-256 . . . . . . . . . . . . . 33 A.1. Example JWS using HMAC SHA-256 . . . . . . . . . . . . . 34
A.1.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 34 A.1.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 34
A.1.2. Validating . . . . . . . . . . . . . . . . . . . . . . 36 A.1.2. Validating . . . . . . . . . . . . . . . . . . . . . . 36
A.2. Example JWS using RSASSA-PKCS-v1_5 SHA-256 . . . . . . . 36 A.2. Example JWS using RSASSA-PKCS-v1_5 SHA-256 . . . . . . . 36
A.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 36 A.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 37
A.2.2. Validating . . . . . . . . . . . . . . . . . . . . . . 39 A.2.2. Validating . . . . . . . . . . . . . . . . . . . . . . 39
A.3. Example JWS using ECDSA P-256 SHA-256 . . . . . . . . . . 39 A.3. Example JWS using ECDSA P-256 SHA-256 . . . . . . . . . . 39
A.3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 39 A.3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 39
A.3.2. Validating . . . . . . . . . . . . . . . . . . . . . . 41 A.3.2. Validating . . . . . . . . . . . . . . . . . . . . . . 41
A.4. Example JWS using ECDSA P-521 SHA-512 . . . . . . . . . . 42 A.4. Example JWS using ECDSA P-521 SHA-512 . . . . . . . . . . 42
A.4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 42 A.4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 42
A.4.2. Validating . . . . . . . . . . . . . . . . . . . . . . 44 A.4.2. Validating . . . . . . . . . . . . . . . . . . . . . . 44
A.5. Example Unsecured JWS . . . . . . . . . . . . . . . . . . 44 A.5. Example Unsecured JWS . . . . . . . . . . . . . . . . . . 44
A.6. Example JWS Using JWS JSON Serialization . . . . . . . . 45 A.6. Example JWS Using JWS JSON Serialization . . . . . . . . 45
A.6.1. JWS Per-Signature Protected Headers . . . . . . . . . 45 A.6.1. JWS Per-Signature Protected Headers . . . . . . . . . 45
skipping to change at page 4, line 46 skipping to change at page 4, line 46
words for use in RFCs to Indicate Requirement Levels [RFC2119]. If words for use in RFCs to Indicate Requirement Levels [RFC2119]. If
these words are used without being spelled in uppercase then they are these words are used without being spelled in uppercase then they are
to be interpreted with their normal natural language meanings. to be interpreted with their normal natural language meanings.
BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per
Section 2. Section 2.
UTF8(STRING) denotes the octets of the UTF-8 [RFC3629] representation UTF8(STRING) denotes the octets of the UTF-8 [RFC3629] representation
of STRING. of STRING.
ASCII(STRING) denotes the octets of the ASCII [USASCII] ASCII(STRING) denotes the octets of the ASCII [RFC20] representation
representation of STRING. of STRING.
The concatenation of two values A and B is denoted as A || B. The concatenation of two values A and B is denoted as A || B.
2. Terminology 2. Terminology
These terms are defined by this specification: These terms are defined by this specification:
JSON Web Signature (JWS) JSON Web Signature (JWS)
A data structure representing a digitally signed or MACed message. A data structure representing a digitally signed or MACed message.
skipping to change at page 6, line 42 skipping to change at page 6, line 42
arbitrary string values MAY be used, any value containing a ":" arbitrary string values MAY be used, any value containing a ":"
character MUST be a URI [RFC3986]. StringOrURI values are character MUST be a URI [RFC3986]. StringOrURI values are
compared as case-sensitive strings with no transformations or compared as case-sensitive strings with no transformations or
canonicalizations applied. canonicalizations applied.
These terms defined by the JSON Web Encryption (JWE) [JWE] These terms defined by the JSON Web Encryption (JWE) [JWE]
specification are incorporated into this specification: "JSON Web specification are incorporated into this specification: "JSON Web
Encryption (JWE)", "JWE Compact Serialization", and "JWE JSON Encryption (JWE)", "JWE Compact Serialization", and "JWE JSON
Serialization". Serialization".
These terms defined by the Internet Security Glossary, Version 2
[RFC4949] are incorporated into this specification: "Digital
Signature" and "Message Authentication Code (MAC)".
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. These JSON data structures MAY structures and base64url encoding. These JSON data structures MAY
contain white space and/or line breaks. A JWS represents these contain white space and/or line breaks. A JWS represents these
logical values (each of which is defined in Section 2): logical values (each of which is defined in Section 2):
o JOSE Header o JOSE Header
o JWS Payload o JWS Payload
o JWS Signature o JWS Signature
skipping to change at page 7, line 45 skipping to change at page 7, line 47
3.2. JWS JSON Serialization Overview 3.2. JWS JSON Serialization Overview
In the JWS JSON Serialization, one or both of the JWS Protected In the JWS JSON Serialization, one or both of the JWS Protected
Header and JWS Unprotected Header MUST be present. In this case, the Header and JWS Unprotected Header MUST be present. In this case, the
members of the JOSE Header are the union of the members of the JWS members of the JOSE Header are the union of the members of the JWS
Protected Header and the JWS Unprotected Header values that are Protected Header and the JWS Unprotected Header values that are
present. present.
In the JWS JSON Serialization, a JWS object is represented as the In the JWS JSON Serialization, a JWS object is represented as the
combination of these four values, combination of these four values:
BASE64URL(UTF8(JWS Protected Header)), BASE64URL(UTF8(JWS Protected Header))
JWS Unprotected Header, JWS Unprotected Header
BASE64URL(JWS Payload), and BASE64URL(JWS Payload)
BASE64URL(JWS Signature), BASE64URL(JWS Signature)
with the three base64url encoding result strings and the JWS
Unprotected Header value being represented as members within a JSON The three base64url encoded result strings and the JWS Unprotected
object. The inclusion of some of these values is OPTIONAL. The JWS Header value are represented as members within a JSON object. The
JSON Serialization can also represent multiple signature and/or MAC 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 values, rather than just one. See Section 7.2 for more information
about the JWS JSON Serialization. about the JWS JSON Serialization.
3.3. Example JWS 3.3. 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.
skipping to change at page 13, line 48 skipping to change at page 13, line 48
that use those extensions. If any of the listed extension Header that use those extensions. If any of the listed extension Header
Parameters are not understood and supported by the recipient, it MUST Parameters are not understood and supported by the recipient, it MUST
reject the JWS. Producers MUST NOT include Header Parameter names reject the JWS. Producers MUST NOT include Header Parameter names
defined by the initial RFC versions of [[ this specification ]] or defined by the initial RFC versions of [[ this specification ]] or
[JWA] for use with JWS, duplicate names, or names that do not occur [JWA] for use with JWS, duplicate names, or names that do not occur
as Header Parameter names within the JOSE Header in the "crit" list. as Header Parameter names within the JOSE Header in the "crit" list.
Producers MUST NOT use the empty list "[]" as the "crit" value. Producers 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 the initial RFC versions of [[ this Header Parameter names defined by the initial RFC versions of [[ this
specification ]] or [JWA] for use with JWS, or any other constraints specification ]] or [JWA] for use with JWS, or any other constraints
on its use are violated. This Header Parameter MUST be integrity on its use are violated. When used, this Header Parameter MUST be
protected, and therefore MUST occur only within the JWS Protected integrity protected; therefore, it MUST occur only within the JWS
Header, when used. Use of this Header Parameter is OPTIONAL. This Protected Header. Use of this Header Parameter is OPTIONAL. This
Header Parameter MUST be understood and processed by implementations. Header Parameter MUST 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
} }
skipping to change at page 15, line 52 skipping to change at page 16, line 9
1. Parse the JWS representation to extract the serialized values 1. Parse the JWS representation to extract the serialized values
for the components of the JWS. When using the JWS Compact for the components of the JWS. When using the JWS Compact
Serialization, these components are the base64url encoded Serialization, these components are the base64url encoded
representations of the JWS Protected Header, the JWS Payload, representations of the JWS Protected Header, the JWS Payload,
and the JWS Signature, and when using the JWS JSON and the JWS Signature, and when using the JWS JSON
Serialization, these components also include the unencoded JWS Serialization, these components also include the unencoded JWS
Unprotected Header value. When using the JWS Compact Unprotected Header value. When using the JWS Compact
Serialization, the JWS Protected Header, the JWS Payload, and Serialization, the JWS Protected Header, the JWS Payload, and
the JWS Signature are represented as base64url encoded values in the JWS Signature are represented as base64url encoded values in
that order, separated by two period ('.') characters. The JWS that order, with each value being separated from the next by a
JSON Serialization is described in Section 7.2. single period ('.') character, resulting in exactly two
delimiting period characters being used. The JWS JSON
Serialization is described in Section 7.2.
2. Base64url decode the encoded representation of the JWS Protected 2. Base64url decode the encoded representation of the JWS Protected
Header, following the restriction that no line breaks, white Header, following the restriction that no line breaks, white
space, or other additional characters have been used. space, or other additional characters have been used.
3. Verify that the resulting octet sequence is a UTF-8 encoded 3. Verify that the resulting octet sequence is a UTF-8 encoded
representation of a completely valid JSON object conforming to representation of a completely valid JSON object conforming to
RFC 7159 [RFC7159]; let the JWS Protected Header be this JSON RFC 7159 [RFC7159]; let the JWS Protected Header be this JSON
object. object.
4. If using the JWS Compact Serialization, let the JOSE Header be 4. If using the JWS Compact Serialization, let the JOSE 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 JOSE Header be the union of the members Serialization, let the JOSE Header be the union of the members
of the corresponding JWS Protected Header and JWS Unprotected of the corresponding JWS Protected Header and JWS Unprotected
Header, all of which must be completely valid JSON objects. Header, all of which must be completely valid JSON objects.
During this step, verify that the resulting JOSE Header does not During this step, verify that the resulting JOSE Header does not
contain duplicate Header Parameter names. When using the JWS contain duplicate Header Parameter names. When using the JWS
JSON Serialization, this restriction includes that the same JSON Serialization, this restriction includes that the same
Header Parameter name also MUST NOT occur in distinct JSON Header Parameter name also MUST NOT occur in distinct JSON
object values that together comprise the JOSE Header. object values that together comprise the JOSE Header.
skipping to change at page 22, line 37 skipping to change at page 23, line 8
The registry records the Header Parameter name and a reference to the The registry records the Header Parameter name and a reference to the
specification that defines it. The same Header Parameter name can be specification that defines it. The same Header Parameter name can be
registered multiple times, provided that the parameter usage is registered multiple times, provided that the parameter usage is
compatible between the specifications. Different registrations of compatible between the specifications. Different registrations of
the same Header Parameter name will typically use different Header the same Header Parameter name will typically use different Header
Parameter Usage Location(s) values. Parameter Usage Location(s) values.
9.1.1. Registration Template 9.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., "kid"). 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 Description: Header Parameter Description:
Brief description of the Header Parameter (e.g., "Example Brief description of the Header Parameter (e.g., "Key ID").
description").
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.
skipping to change at page 25, line 15 skipping to change at page 25, line 31
"application/jose+json" Media Type in the MIME Media Types registry, "application/jose+json" Media Type in the MIME Media Types registry,
which can be used to indicate that the content is a JWS or JWE object which can be used to indicate that the content is a JWS or JWE object
using the JWS JSON Serialization or the JWE JSON Serialization. using the JWS JSON Serialization or the JWE JSON Serialization.
o Type name: application o Type name: application
o Subtype name: jose o Subtype name: jose
o Required parameters: n/a o Required parameters: n/a
o Optional parameters: n/a o Optional parameters: n/a
o Encoding considerations: 8bit; application/jose values are encoded o Encoding considerations: 8bit; application/jose values are encoded
as a series of base64url encoded values (some of which may be the as a series of base64url encoded values (some of which may be the
empty string) separated by period ('.') characters. empty string) each separated from the next by a single period
('.') character.
o Security considerations: See the Security Considerations section o Security considerations: See the Security Considerations section
of [[ this document ]] of [[ this document ]]
o Interoperability considerations: n/a o Interoperability considerations: n/a
o Published specification: [[ this document ]] o Published specification: [[ this document ]]
o Applications that use this media type: OpenID Connect, Mozilla o Applications that use this media type: OpenID Connect, Mozilla
Persona, Salesforce, Google, Android, Windows Azure, Xbox One, and Persona, Salesforce, Google, Android, Windows Azure, Xbox One, and
numerous others that use JWTs numerous others that use JWTs
o Fragment identifier considerations: n/a o Fragment identifier considerations: n/a
o Additional information: Magic number(s): n/a, File extension(s): o Additional information: Magic number(s): n/a, File extension(s):
n/a, Macintosh file type code(s): n/a n/a, Macintosh file type code(s): n/a
skipping to change at page 31, line 18 skipping to change at page 31, line 32
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),
October 2014. October 2014.
[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),
October 2014. October 2014.
[RFC20] Cerf, V., "ASCII format for Network Interchange", RFC 20,
October 1969.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. 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.
skipping to change at page 31, line 44 skipping to change at page 32, line 12
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC4945] Korver, B., "The Internet IP Security PKI Profile of [RFC4945] Korver, B., "The Internet IP Security PKI Profile of
IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007. IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, August 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011. Security (TLS)", RFC 6125, March 2011.
[RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer
(SSL) Version 2.0", RFC 6176, March 2011. (SSL) Version 2.0", RFC 6176, March 2011.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014. Interchange Format", RFC 7159, March 2014.
[USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986.
11.2. Informative References 11.2. Informative References
[CanvasApp] [CanvasApp]
Facebook, "Canvas Applications", 2010. Facebook, "Canvas Applications", 2010.
[I-D.ietf-uta-tls-bcp] [I-D.ietf-uta-tls-bcp]
Sheffer, Y., Holz, R., and P. Saint-Andre, Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of TLS and DTLS", "Recommendations for Secure Use of TLS and DTLS",
draft-ietf-uta-tls-bcp-03 (work in progress), draft-ietf-uta-tls-bcp-05 (work in progress),
September 2014. October 2014.
[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. and J. Hildebrand, "JSON Web Encryption (JWE)", [JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
draft-ietf-jose-json-web-encryption (work in progress), draft-ietf-jose-json-web-encryption (work in progress),
October 2014. October 2014.
[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
skipping to change at page 53, line 17 skipping to change at page 53, line 17
This specification is the work of the JOSE Working Group, which This specification is the work of the JOSE Working Group, which
includes dozens of active and dedicated participants. In particular, includes dozens of active and dedicated participants. In particular,
the following individuals contributed ideas, feedback, and wording the following individuals contributed ideas, feedback, and wording
that influenced this specification: that influenced this specification:
Dirk Balfanz, Richard Barnes, Brian Campbell, Alissa Cooper, Breno de Dirk Balfanz, Richard Barnes, Brian Campbell, Alissa Cooper, Breno de
Medeiros, Stephen Farrell, Dick Hardt, Joe Hildebrand, Jeff Hodges, Medeiros, Stephen Farrell, Dick Hardt, Joe Hildebrand, Jeff Hodges,
Russ Housley, Edmund Jay, Tero Kivinen, Yaron Y. Goland, Ben Laurie, Russ Housley, Edmund Jay, Tero Kivinen, Yaron Y. Goland, Ben Laurie,
Ted Lemon, James Manger, Matt Miller, Kathleen Moriarty, Tony Ted Lemon, James Manger, Matt Miller, Kathleen Moriarty, Tony
Nadalin, Hideki Nara, Axel Nennker, John Panzer, Emmanuel Raviart, Nadalin, Hideki Nara, Axel Nennker, John Panzer, Ray Polk, Emmanuel
Eric Rescorla, Pete Resnick, Jim Schaad, Paul Tarjan, Hannes Raviart, Eric Rescorla, Pete Resnick, Jim Schaad, Paul Tarjan, Hannes
Tschofenig, and Sean Turner. 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, Stephen Farrell, and Kathleen Moriarty served as Sean Turner, Stephen Farrell, and Kathleen Moriarty served as
Security area directors during the creation of this specification. Security area directors during the creation of this specification.
Appendix H. Document History Appendix H. 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 ]]
-35
o Addressed AppsDir reviews by Ray Polk.
o Used real values for examples in the IANA Registration Template.
-34 -34
o Addressed IESG review comments by Alissa Cooper, Pete Resnick, o Addressed IESG review comments by Alissa Cooper, Pete Resnick,
Richard Barnes, Ted Lemon, and Stephen Farrell. Richard Barnes, Ted Lemon, and Stephen Farrell.
o Addressed Gen-ART review comments by Russ Housley. o Addressed Gen-ART review comments by Russ Housley.
o Referenced RFC 4945 for PEM certificate delimiter syntax. o Referenced RFC 4945 for PEM certificate delimiter syntax.
-33 -33
 End of changes. 31 change blocks. 
48 lines changed or deleted 66 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/