draft-ietf-jose-json-web-signature-17.txt   draft-ietf-jose-json-web-signature-18.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 10, 2014 Ping Identity Expires: May 16, 2014 Ping Identity
N. Sakimura N. Sakimura
NRI NRI
October 7, 2013 November 12, 2013
JSON Web Signature (JWS) JSON Web Signature (JWS)
draft-ietf-jose-json-web-signature-17 draft-ietf-jose-json-web-signature-18
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 10, 2014. This Internet-Draft will expire on May 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. JSON Web Signature (JWS) Overview . . . . . . . . . . . . . . 6 3. JSON Web Signature (JWS) Overview . . . . . . . . . . . . . . 6
3.1. Example JWS . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Example JWS . . . . . . . . . . . . . . . . . . . . . . . 7
4. JWS Header . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. JWS Header . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Registered Header Parameter Names . . . . . . . . . . . . 9 4.1. Registered Header Parameter Names . . . . . . . . . . . . 9
4.1.1. "alg" (Algorithm) Header Parameter . . . . . . . . . . 9 4.1.1. "alg" (Algorithm) Header Parameter . . . . . . . . . . 9
4.1.2. "jku" (JWK Set URL) Header Parameter . . . . . . . . . 10 4.1.2. "jku" (JWK Set URL) Header Parameter . . . . . . . . . 10
4.1.3. "jwk" (JSON Web Key) Header Parameter . . . . . . . . 10 4.1.3. "jwk" (JSON Web Key) Header Parameter . . . . . . . . 10
4.1.4. "x5u" (X.509 URL) Header Parameter . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . 11 Parameter . . . . . . . . . . . . . . . . . . . . . . 10
4.1.6. "x5c" (X.509 Certificate Chain) Header Parameter . . . 11 4.1.6. "x5c" (X.509 Certificate Chain) Header Parameter . . . 11
4.1.7. "kid" (Key ID) Header Parameter . . . . . . . . . . . 11 4.1.7. "kid" (Key ID) Header Parameter . . . . . . . . . . . 11
4.1.8. "typ" (Type) Header Parameter . . . . . . . . . . . . 12 4.1.8. "typ" (Type) Header Parameter . . . . . . . . . . . . 11
4.1.9. "cty" (Content Type) Header Parameter . . . . . . . . 12 4.1.9. "cty" (Content Type) Header Parameter . . . . . . . . 12
4.1.10. "crit" (Critical) Header Parameter . . . . . . . . . . 13 4.1.10. "crit" (Critical) Header Parameter . . . . . . . . . . 12
4.2. Public Header Parameter Names . . . . . . . . . . . . . . 13 4.2. Public Header Parameter Names . . . . . . . . . . . . . . 13
4.3. Private Header Parameter Names . . . . . . . . . . . . . . 13 4.3. Private Header Parameter Names . . . . . . . . . . . . . . 13
5. Producing and Consuming JWSs . . . . . . . . . . . . . . . . . 14 5. Producing and Consuming JWSs . . . . . . . . . . . . . . . . . 13
5.1. Message Signing or MACing . . . . . . . . . . . . . . . . 14 5.1. Message Signature or MAC Computation . . . . . . . . . . . 13
5.2. Message Signature or MAC Validation . . . . . . . . . . . 14 5.2. Message Signature or MAC Validation . . . . . . . . . . . 14
5.3. String Comparison Rules . . . . . . . . . . . . . . . . . 16 5.3. String Comparison Rules . . . . . . . . . . . . . . . . . 16
6. Key Identification . . . . . . . . . . . . . . . . . . . . . . 16 6. Key Identification . . . . . . . . . . . . . . . . . . . . . . 16
7. Serializations . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Serializations . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. JWS Compact Serialization . . . . . . . . . . . . . . . . 17 7.1. JWS Compact Serialization . . . . . . . . . . . . . . . . 17
7.2. JWS JSON Serialization . . . . . . . . . . . . . . . . . . 17 7.2. JWS JSON Serialization . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. JSON Web Signature and Encryption Header Parameters 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9.1. JSON Web Signature and Encryption Header Parameters
Registry . . . . . . . . . . . . . . . . . . . . . . . . . 20 Registry . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1.1. Registration Template . . . . . . . . . . . . . . . . 20 9.1.1. Registration Template . . . . . . . . . . . . . . . . 20
8.1.2. Initial Registry Contents . . . . . . . . . . . . . . 20 9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 21
8.2. Media Type Registration . . . . . . . . . . . . . . . . . 22 9.2. Media Type Registration . . . . . . . . . . . . . . . . . 22
8.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 22 9.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9.1. Cryptographic Security Considerations . . . . . . . . . . 23 10.1. Cryptographic Security Considerations . . . . . . . . . . 23
9.2. JSON Security Considerations . . . . . . . . . . . . . . . 24 10.2. JSON Security Considerations . . . . . . . . . . . . . . . 25
9.3. Unicode Comparison Security Considerations . . . . . . . . 25 10.3. Unicode Comparison Security Considerations . . . . . . . . 25
9.4. TLS Requirements . . . . . . . . . . . . . . . . . . . . . 25 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . . 27
10.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. JWS Examples . . . . . . . . . . . . . . . . . . . . 28 Appendix A. JWS Examples . . . . . . . . . . . . . . . . . . . . 28
A.1. Example JWS using HMAC SHA-256 . . . . . . . . . . . . . . 28 A.1. Example JWS using HMAC SHA-256 . . . . . . . . . . . . . . 28
A.1.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 28 A.1.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 28
A.1.2. Validating . . . . . . . . . . . . . . . . . . . . . . 30 A.1.2. Validating . . . . . . . . . . . . . . . . . . . . . . 30
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. Validating . . . . . . . . . . . . . . . . . . . . . . 33
A.3. Example JWS using ECDSA P-256 SHA-256 . . . . . . . . . . 33 A.3. Example JWS using ECDSA P-256 SHA-256 . . . . . . . . . . 33
A.3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 33 A.3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 33
A.3.2. Validating . . . . . . . . . . . . . . . . . . . . . . 35 A.3.2. Validating . . . . . . . . . . . . . . . . . . . . . . 35
A.4. Example JWS using ECDSA P-521 SHA-512 . . . . . . . . . . 35 A.4. Example JWS using ECDSA P-521 SHA-512 . . . . . . . . . . 36
A.4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 36 A.4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . 36
A.4.2. Validating . . . . . . . . . . . . . . . . . . . . . . 38 A.4.2. Validating . . . . . . . . . . . . . . . . . . . . . . 38
A.5. Example Plaintext JWS . . . . . . . . . . . . . . . . . . 38 A.5. Example Plaintext JWS . . . . . . . . . . . . . . . . . . 38
A.6. Example JWS Using JWS JSON Serialization . . . . . . . . . 39 A.6. Example JWS Using JWS JSON Serialization . . . . . . . . . 39
A.6.1. JWS Per-Signature Protected Headers . . . . . . . . . 39 A.6.1. JWS Per-Signature Protected Headers . . . . . . . . . 39
A.6.2. JWS Per-Signature Unprotected Headers . . . . . . . . 40 A.6.2. JWS Per-Signature Unprotected Headers . . . . . . . . 40
A.6.3. Complete JWS Header Values . . . . . . . . . . . . . . 40 A.6.3. Complete JWS Header Values . . . . . . . . . . . . . . 40
A.6.4. Complete JWS JSON Serialization Representation . . . . 40 A.6.4. Complete JWS JSON Serialization Representation . . . . 40
Appendix B. "x5c" (X.509 Certificate Chain) Example . . . . . . . 41 Appendix B. "x5c" (X.509 Certificate Chain) Example . . . . . . . 41
Appendix C. Notes on implementing base64url encoding without Appendix C. Notes on implementing base64url encoding without
padding . . . . . . . . . . . . . . . . . . . . . . . 43 padding . . . . . . . . . . . . . . . . . . . . . . . 43
Appendix D. Negative Test Case for "crit" Header Parameter . . . 44 Appendix D. Negative Test Case for "crit" Header Parameter . . . 44
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 44 Appendix E. Detached Content . . . . . . . . . . . . . . . . . . 44
Appendix F. Document History . . . . . . . . . . . . . . . . . . 45 Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 Appendix G. Document History . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
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 5, line 10 skipping to change at page 5, line 10
ASCII(STRING) denotes the octets of the ASCII [USASCII] ASCII(STRING) denotes the octets of the ASCII [USASCII]
representation of STRING. representation 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
JSON Web Signature (JWS) A data structure representing a digitally JSON Web Signature (JWS) A data structure representing a digitally
signed or MACed message. signed or MACed message.
JSON Text Object A UTF-8 [RFC3629] encoded text string representing JWS Header A JSON object (or JSON objects, when using the JWS JSON
a JSON object; the syntax of JSON objects is defined in Section Serialization) that describes the digital signature or MAC
2.2 of [RFC4627]. operation applied to create the JWS Signature value. The members
of the JWS Header object(s) are Header Parameters.
JWS Header A JSON Text Object (or JSON Text Objects, when using the
JWS JSON Serialization) that describes the digital signature or
MAC operation applied to create the JWS Signature value. The
members of the JWS Header object(s) are Header Parameters.
JWS Payload The sequence of octets to be secured -- a.k.a., the JWS Payload The sequence of octets to be secured -- a.k.a., the
message. The payload can contain an arbitrary sequence of octets. message. The payload can contain an arbitrary sequence of octets.
JWS Signature A sequence of octets containing the cryptographic JWS Signature A sequence of octets containing the cryptographic
material that ensures the integrity of the JWS Protected Header material that ensures the integrity of the JWS Protected Header
and the JWS Payload. The JWS Signature value is a digital and the JWS Payload. The JWS Signature value is a digital
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 object that contains the portion of the
the JWS Header that is integrity protected. For the JWS Compact 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.
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.)
JWS Signing Input The input to the digital signature or MAC JWS Signing Input The input to the digital signature or MAC
computation. Its value is ASCII(BASE64URL(UTF8(JWS Protected computation. Its value is ASCII(BASE64URL(UTF8(JWS Protected
Header)) || '.' || BASE64URL(JWS Payload)). Header)) || '.' || BASE64URL(JWS Payload)).
JWS Compact Serialization A representation of the JWS as the string JWS Compact Serialization A representation of the JWS as a compact,
BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS URL-safe string.
Payload) || '.' || BASE64URL(JWS Signature). This 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 object.
structure. Unlike the JWS Compact Serialization, the JWS JSON Unlike the JWS Compact Serialization, the JWS JSON Serialization
Serialization enables multiple digital signatures and/or MACs to enables multiple digital signatures and/or MACs to be applied to
be applied to the same content. This representation is neither the same content. This representation is neither compact nor URL-
compact nor URL-safe. 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
skipping to change at page 9, line 35 skipping to change at page 9, line 26
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 9.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. This Header
Header Parameter is REQUIRED. This Header Parameter MUST be Parameter MUST be present and MUST be understood and processed by
understood and processed by implementations. implementations.
A list of defined "alg" values for this use can be found in the IANA A list of defined "alg" values for this use can be found in the IANA
JSON Web Signature and Encryption Algorithms registry defined in JSON Web Signature and Encryption Algorithms registry defined in
[JWA]; the initial contents of this registry are the values defined [JWA]; the initial contents of this registry are the values defined
in Section 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
skipping to change at page 11, line 19 skipping to change at page 11, line 6
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 9.1.
4.1.6. "x5c" (X.509 Certificate Chain) Header Parameter 4.1.6. "x5c" (X.509 Certificate Chain) Header Parameter
The "x5c" (X.509 Certificate Chain) Header Parameter contains the The "x5c" (X.509 Certificate Chain) Header Parameter contains the
X.509 public key certificate or certificate chain [RFC5280] X.509 public key certificate or certificate chain [RFC5280]
corresponding to the key used to digitally sign the JWS. The corresponding to the key used to digitally sign the JWS. The
certificate or certificate chain is represented as a JSON array of certificate or certificate chain is represented as a JSON array of
certificate value strings. Each string in the array is a base64 certificate value strings. Each string in the array is a base64
encoded ([RFC4648] Section 4 -- not base64url encoded) DER encoded ([RFC4648] Section 4 -- not base64url encoded) DER
[ITU.X690.1994] PKIX certificate value. The certificate containing [ITU.X690.1994] PKIX certificate value. The certificate containing
skipping to change at page 11, line 44 skipping to change at page 11, line 31
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. The structure of
recipient be unable to locate a key corresponding to the "kid" value,
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 is used to match a JWK "kid"
"kid" parameter value. 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 MIME Media The "typ" (type) Header Parameter is used to declare the MIME Media
Type [IANA.MediaTypes] of this complete JWS object in contexts where Type [IANA.MediaTypes] of this complete JWS object in contexts where
this is useful to the application. This parameter has no effect upon this is useful to the application. This parameter has no effect upon
the JWS processing. Use of this Header Parameter is OPTIONAL. the JWS processing. Use of this Header Parameter is OPTIONAL.
Per [RFC2045], all media type values, subtype values, and parameter Per [RFC2045], all media type values, subtype values, and parameter
names are case-insensitive. However, parameter values are case- names are case-insensitive. However, parameter values are case-
sensitive unless otherwise specified for the specific parameter. sensitive unless otherwise specified for the specific parameter.
To keep messages compact in common situations, it is RECOMMENDED that To keep messages compact in common situations, it is RECOMMENDED that
senders omit an "application/" prefix of a media type value in a senders omit an "application/" prefix of a media type value in a
"typ" Header Parameter when no other '/' appears in the media type "typ" Header Parameter when no other '/' appears in the media type
value. A recipient using the media type value MUST treat it as if value. A recipient using the media type value MUST treat it as if
"application/" were prepended to any "typ" value not containing a "application/" were prepended to any "typ" value not containing a
'/'. For instance, a "typ" value of "example" SHOULD be used to '/'. For instance, a "typ" value of "example" SHOULD be used to
represent the "application/example" media type. represent the "application/example" media type; whereas, the media
type "application/example;part="1/2"" cannot be shortened to
"example;part="1/2"".
The "typ" value "JOSE" can be used by applications to indicate that 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 this object is a JWS or JWE using the JWS Compact Serialization or
the JWE Compact Serialization. The "typ" value "JOSE+JSON" can be the JWE Compact Serialization. The "typ" value "JOSE+JSON" can be
used by applications to indicate that this object is a JWS or JWE used by applications to indicate that this object is a JWS or JWE
using the JWS JSON Serialization or the JWE JSON Serialization. using the JWS JSON Serialization or the JWE JSON Serialization.
Other type values can also be used by applications. 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
skipping to change at page 12, line 49 skipping to change at page 12, line 36
Per [RFC2045], all media type values, subtype values, and parameter Per [RFC2045], all media type values, subtype values, and parameter
names are case-insensitive. However, parameter values are case- names are case-insensitive. However, parameter values are case-
sensitive unless otherwise specified for the specific parameter. sensitive unless otherwise specified for the specific parameter.
To keep messages compact in common situations, it is RECOMMENDED that To keep messages compact in common situations, it is RECOMMENDED that
senders omit an "application/" prefix of a media type value in a senders omit an "application/" prefix of a media type value in a
"cty" Header Parameter when no other '/' appears in the media type "cty" Header Parameter when no other '/' appears in the media type
value. A recipient using the media type value MUST treat it as if value. A recipient using the media type value MUST treat it as if
"application/" were prepended to any "cty" value not containing a "application/" were prepended to any "cty" value not containing a
'/'. For instance, a "cty" value of "example" SHOULD be used to '/'. For instance, a "cty" value of "example" SHOULD be used to
represent the "application/example" media type. represent the "application/example" media type; whereas, the media
type "application/example;part="1/2"" cannot be shortened to
"example;part="1/2"".
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 the initial RFC versions of [[ this specification ]] and [JWA] are
processed. Its value is an array listing the Header Parameter names being used that MUST be understood and processed. Its value is an
defined by those extensions that are used in the JWS Header. If any array listing the Header Parameter names present in the JWS Header
of the listed extension Header Parameters are not understood and that use those extensions. If any of the listed extension Header
supported by the receiver, it MUST reject the JWS. Senders MUST NOT Parameters are not understood and supported by the receiver, it MUST
include Header Parameter names defined by [[ this specification ]] or reject the JWS. Senders must not include Header Parameter names
by [JWA] for use with JWS, duplicate names, or names that do not defined by the initial RFC versions of [[ this specification ]] or
occur as Header Parameter names within the JWS Header in the "crit" [JWA] for use with JWS, duplicate names, or names that do not occur
list. Senders MUST not use the empty list "[]" as the "crit" value. as Header Parameter names within the JWS Header in the "crit" 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 the initial RFC versions of [[ this
[JWA] for use with JWS, or any other constraints on its use are specification ]] or [JWA] for use with JWS, or any other constraints
violated. This Header Parameter MUST be integrity protected, and on its use are violated. This Header Parameter MUST be integrity
therefore MUST occur only with the JWS Protected Header, when used. protected, and therefore MUST occur only within the JWS Protected
Use of this Header Parameter is OPTIONAL. This Header Parameter MUST Header, when used. Use of this Header Parameter is OPTIONAL. This
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
} }
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 9.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 Signature or MAC Computation
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. Compute the encoded payload value BASE64URL(JWS Payload).
3. Create a JWS Header containing the desired set of Header 3. Create the JSON object(s) containing the desired set of Header
Parameters. Note that white space is explicitly allowed in the Parameters, which together comprise the JWS Header: the JWS
representation and no canonicalization need be performed before Protected Header, and if the JWS JSON Serialization is being
encoding. used, the JWS Unprotected Header.
4. Compute the encoded header value BASE64URL(UTF8(JWS Protected 4. Compute the encoded header value BASE64URL(UTF8(JWS Protected
Header)). If the JWS Protected Header is not present (which can Header)). If the JWS Protected Header is not present (which can
only happen when using the JWS JSON Serialization and no only happen when using the JWS JSON Serialization and no
"protected" member is present), let this value be the empty "protected" member is present), let this value be the empty
string. 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 particular algorithm being used over the JWS Signing Input
ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload)). The "alg" (algorithm) Header Parameter BASE64URL(JWS Payload)). The "alg" (algorithm) Header Parameter
MUST be present in the JWS Header, with the algorithm value MUST be present in the JWS Header, with the algorithm value
accurately representing the algorithm used to construct the JWS accurately representing the algorithm used to construct the JWS
Signature. Signature.
6. Compute the encoded signature value BASE64URL(JWS Signature). 6. Compute the encoded signature value BASE64URL(JWS Signature).
7. These three encoded values are used in both the JWS Compact 7. These three encoded values are used in both the JWS Compact
Serialization and the JWS JSON Serialization representations. 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. (steps 1-7) 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 BASE64URL(UTF8(JWS Protected Serialization of this result is BASE64URL(UTF8(JWS Protected
Header)) || '.' || BASE64URL(JWS Payload) || '.' || BASE64URL(JWS Header)) || '.' || BASE64URL(JWS Payload) || '.' || BASE64URL(JWS
Signature). The JWS JSON Serialization is described in Signature). The JWS JSON Serialization is described in
Section 7.2. 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
skipping to change at page 15, line 26 skipping to change at page 15, line 18
Protected Header, the JWS Payload, and the JWS Signature, and Protected Header, the JWS Payload, and the JWS Signature, and
when using the JWS JSON Serialization, also the unencoded JWS when using the JWS JSON Serialization, also 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, separated by two period ('.') characters. The JWS
JSON Serialization is described in Section 7.2. JSON Serialization is described in Section 7.2.
2. The encoded representation of the JWS Protected Header MUST be 2. The encoded representation of the JWS Protected Header MUST be
successfully base64url decoded following the restriction that no 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. The resulting octet sequence MUST be a UTF-8 encoded
completely valid JSON object conforming to RFC 4627 [RFC4627]. representation of a completely valid JSON object conforming to
RFC 4627 [RFC4627], which is the JWS Protected Header.
4. If using the JWS Compact Serialization, let the JWS Header be 4. 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 JWS Protected Header and JWS Unprotected 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.
5. The resulting JWS Header MUST NOT contain duplicate Header 5. 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 object values that together
comprise the JWS Header. comprise the JWS Header.
6. The resulting JWS Header MUST be validated to only include 6. Verify that the implementation understands and can process all
parameters and values whose syntax and semantics are both fields that it is required to support, whether required by this
understood and supported or that are specified as being ignored specification, by the algorithm being used, or by the "crit"
when not understood. Header Parameter value, and that the values of those parameters
are also understood and supported.
7. The encoded representation of the JWS Payload MUST be 7. The encoded representation of the JWS Payload MUST be
successfully base64url decoded following the restriction that no successfully base64url decoded following the restriction that no
padding characters have been used. padding characters have been used.
8. The encoded representation of the JWS Signature MUST be 8. The encoded representation of the JWS Signature MUST be
successfully base64url decoded following the restriction that no successfully base64url decoded following the restriction that no
padding characters have been used. padding characters have been used.
9. The JWS Signature MUST be successfully validated against the JWS 9. The JWS Signature MUST be successfully validated against the JWS
Signing Input ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' Signing Input ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.'
|| BASE64URL(JWS Payload)) in the manner defined for the || BASE64URL(JWS Payload)) in the manner defined for the
algorithm being used, which MUST be accurately represented by algorithm being used, which MUST be accurately represented by
the value of the "alg" (algorithm) Header Parameter, which MUST the value of the "alg" (algorithm) Header Parameter, which MUST
be present. be present.
10. If the JWS JSON Serialization is being used, repeat this process 10. If the JWS JSON Serialization is being used, repeat this process
for each digital signature or MAC value contained in the (steps 1-9) for each digital signature or MAC value contained in
representation. the 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 members and values in a JSON object. For example, in checking what
is, the Unicode string encoding "alg" will be checked against the the algorithm is, the Unicode string "alg" will be checked against
member names in the JWS Header to see if there is a matching Header the member names in the JWS Header to see if there is a matching
Parameter name. A similar process occurs when determining if the Header Parameter name. The same process is then used to determine if
value of the "alg" Header Parameter represents a supported algorithm. the value of the "alg" Header Parameter represents a supported
algorithm.
Comparisons between JSON strings and other Unicode strings MUST be Since the only string comparision operations that are performed are
performed as specified below: equality and inequality, the same rules can be used for comparing
1. Remove any JSON escaping from the input JSON string and convert both member names and member values against known strings. The JSON
the string into a sequence of Unicode code points. rules for doing member name comparison are described in Section 8.3
2. Likewise, convert the string to be compared against into a of [I-D.ietf-json-rfc4627bis].
sequence of Unicode code points.
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
against.
4. Comparisons between the two strings MUST be performed as a
Unicode code point to code point equality comparison. (Note that
values that originally used different Unicode encodings (UTF-8,
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 10.2 and the
Unicode security considerations in Section 9.3. Unicode security considerations in Section 10.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
skipping to change at page 17, line 13 skipping to change at page 16, line 49
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. For general-purpose Serialization or the JWS JSON Serialization. Applications using this
implementations, both the JWS Compact Serialization and JWS JSON specification need to specify what serialization and serialization
Serialization support for the single signature or MAC value case are features are used for that application. For instance, applications
mandatory to implement; support for multiple signatures and/or MAC might specify that only the JWS JSON Serialization is used, that only
values is OPTIONAL. Special-purpose implementations are permitted to JWS JSON Serialization support for a single signature or MAC value is
implement only a single serialization, if that meets the needs of the used, or that support for multiple signatures and/or MAC values is
targeted use cases. used. JWS implementations only need to implement the features needed
for the applications they are designed to support.
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 content as a compact URL-safe string. This string is
BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS
Payload) || '.' || BASE64URL(JWS Signature). Only one signature/MAC Payload) || '.' || BASE64URL(JWS Signature). Only one signature/MAC
is supported by the JWS Compact Serialization. is supported by the JWS Compact Serialization and it provides no
syntax to represent a JWS Unprotected Header value.
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 18, line 4 skipping to change at page 17, line 41
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 value BASE64URL(JWS Payload) 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 value BASE64URL(JWS Signature), if non-empty, is stored in o Each value BASE64URL(JWS Signature), if non-empty, is stored in
the "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 value BASE64URL(UTF8(JWS Protected Header)), if non-empty, is
stored in the "protected" member of the corresponding element of stored in the "protected" member of the corresponding element of
the "signatures" array. the "signatures" array.
o Each JWS Unprotected Header value, if non-empty, is stored in the o Each JWS Unprotected Header value, if non-empty, is stored in the
"header" member of the corresponding element of the "signatures" "header" member of the corresponding element of the "signatures"
array. If present, a JWS Unprotected Header value is represented array. If present, a JWS Unprotected Header value is represented
as an unencoded JSON Text Object, rather than as a string. as an unencoded JSON object, rather than as a string.
o The Header Parameter values used when creating or validating 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 JWS of Header Parameter values that may be present: (1) the JWS
Protected Header values represented in the "protected" member of Protected Header values represented in the "protected" member of
the signature/MAC's array element, and (2) the JWS Unprotected the signature/MAC's array element, and (2) the JWS Unprotected
Header values in the "header" member of the signature/MAC's array Header values in the "header" member of the signature/MAC's array
element. The union of these sets of Header Parameters comprises element. The union of these sets of Header Parameters comprises
the JWS Header. The Header Parameter names in the two locations the JWS Header. The Header Parameter names in the two locations
MUST be disjoint. MUST be disjoint.
skipping to change at page 19, line 16 skipping to change at page 19, line 6
property that each JWS Signature value represented in the property that each JWS Signature value represented in the
"signatures" array is identical to the value that would have been "signatures" array is identical to the value that would have been
computed for the same parameter in the JWS Compact Serialization, computed for the same parameter in the JWS Compact Serialization,
provided that the JWS Protected Header value for that signature/MAC provided that the JWS Protected Header value for that signature/MAC
computation (which represents the integrity-protected Header computation (which represents the integrity-protected Header
Parameter values) matches 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. TLS Requirements
Implementations MUST support TLS. Which version(s) ought to be
implemented will vary over time, and depend on the widespread
deployment and known security vulnerabilities at the time of
implementation. At the time of this writing, TLS version 1.2
[RFC5246] is the most recent version, but has very limited actual
deployment, and might not be readily available in implementation
toolkits. TLS version 1.0 [RFC2246] is the most widely deployed
version, and will give the broadest interoperability.
To protect against information disclosure and tampering,
confidentiality protection MUST be applied using TLS with a
ciphersuite that provides confidentiality and integrity protection.
Whenever TLS is used, a TLS server certificate check MUST be
performed, per RFC 6125 [RFC6125].
9. IANA Considerations
The following registration procedure is used for all the registries The following registration procedure is used for all the registries
established by this specification. established by this specification.
Values are registered with a Specification Required [RFC5226] after a Values are registered with a Specification Required [RFC5226] after a
two-week review period on the [TBD]@ietf.org mailing list, on the two-week review period on the [TBD]@ietf.org mailing list, on the
advice of one or more Designated Experts. However, to allow for the advice of one or more Designated Experts. However, to allow for the
allocation of values prior to publication, the Designated Expert(s) allocation of values prior to publication, the Designated Expert(s)
may approve registration once they are satisfied that such a may approve registration once they are satisfied that such a
specification will be published. specification will be published.
skipping to change at page 20, line 13 skipping to change at page 20, line 23
list. list.
It is suggested that multiple Designated Experts be appointed who are It is suggested that multiple Designated Experts be appointed who are
able to represent the perspectives of different applications using able to represent the perspectives of different applications using
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 9.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 can 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 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., "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 Description:
Brief description of the Header Parameter (e.g., "Example
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.
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.
skipping to change at page 20, line 48 skipping to change at page 21, line 15
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 9.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 Description: Algorithm
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 Description: JWK Set URL
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.2 of [[ this document ]] o Specification Document(s): Section 4.1.2 of [[ this document ]]
o Header Parameter Name: "jwk" o Header Parameter Name: "jwk"
o Header Parameter Description: JSON Web Key
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.3 of [[ this document ]] o Specification document(s): Section 4.1.3 of [[ this document ]]
o Header Parameter Name: "x5u" o Header Parameter Name: "x5u"
o Header Parameter Description: X.509 URL
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.4 of [[ this document ]] o Specification Document(s): Section 4.1.4 of [[ this document ]]
o Header Parameter Name: "x5t" o Header Parameter Name: "x5t"
o Header Parameter Description: X.509 Certificate SHA-1 Thumbprint
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.5 of [[ this document ]] o Specification Document(s): Section 4.1.5 of [[ this document ]]
o Header Parameter Name: "x5c" o Header Parameter Name: "x5c"
o Header Parameter Description: X.509 Certificate Chain
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.6 of [[ this document ]] o Specification Document(s): Section 4.1.6 of [[ this document ]]
o Header Parameter Name: "kid" o Header Parameter Name: "kid"
o Header Parameter Description: Key ID
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.7 of [[ this document ]] o Specification Document(s): Section 4.1.7 of [[ this document ]]
o Header Parameter Name: "typ" o Header Parameter Name: "typ"
o Header Parameter Description: Type
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.8 of [[ this document ]] o Specification Document(s): Section 4.1.8 of [[ this document ]]
o Header Parameter Name: "cty" o Header Parameter Name: "cty"
o Header Parameter Description: Content Type
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 Description: Critical
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. Media Type Registration 9.2. Media Type Registration
8.2.1. Registry Contents 9.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 23, line 19 skipping to change at page 23, line 43
o Applications that use this media type: TBD o Applications that use this media type: TBD
o Additional information: Magic number(s): n/a, File extension(s): o Additional information: Magic number(s): n/a, File extension(s):
n/a, Macintosh file type code(s): n/a n/a, Macintosh file type code(s): n/a
o Person & email address to contact for further information: Michael o Person & email address to contact for further information: Michael
B. Jones, mbj@microsoft.com B. Jones, mbj@microsoft.com
o Intended usage: COMMON o Intended usage: COMMON
o Restrictions on usage: none o Restrictions on usage: none
o Author: Michael B. Jones, mbj@microsoft.com o Author: Michael B. Jones, mbj@microsoft.com
o Change Controller: IESG o Change Controller: IESG
9. Security Considerations 10. Security Considerations
9.1. Cryptographic Security Considerations 10.1. Cryptographic Security Considerations
All of the security issues faced by any cryptographic application All of the security issues faced by any cryptographic application
must be faced by a JWS/JWE/JWK agent. Among these issues are must be faced by a JWS/JWE/JWK agent. Among these issues are
protecting the user's private and symmetric keys, preventing various protecting the user's private and symmetric keys, preventing various
attacks, and helping the user avoid mistakes such as inadvertently attacks, and helping the user avoid mistakes such as inadvertently
encrypting a message for the wrong recipient. The entire list of encrypting a message for the wrong recipient. The entire list of
security considerations is beyond the scope of this document, but security considerations is beyond the scope of this document, but
some significant concerns are listed here. some significant concerns are listed here.
All the security considerations in XML DSIG 2.0 All the security considerations in XML DSIG 2.0
skipping to change at page 24, line 27 skipping to change at page 25, line 5
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 10.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
skipping to change at page 25, line 5 skipping to change at page 25, line 32
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 10.3. Unicode Comparison Security Considerations
Header Parameter names and algorithm names are Unicode strings. For Header Parameter names and algorithm names are Unicode strings. For
security reasons, the representations of these names must be compared security reasons, the representations of these names must be compared
verbatim after performing any escape processing (as per RFC 4627 verbatim after performing any escape processing (as per RFC 4627
[RFC4627], Section 2.5). This means, for instance, that these JSON [RFC4627], Section 2.5). This means, for instance, that these JSON
strings must compare as being equal ("sig", "\u0073ig"), whereas strings must compare as being equal ("sig", "\u0073ig"), whereas
these must all compare as being not equal to the first set or to each these must all compare as being not equal to the first set or to each
other ("SIG", "Sig", "si\u0047"). other ("SIG", "Sig", "si\u0047").
JSON strings can contain characters outside the Unicode Basic JSON strings can contain characters outside the Unicode Basic
Multilingual Plane. For instance, the G clef character (U+1D11E) may Multilingual Plane. For instance, the G clef character (U+1D11E) may
be represented in a JSON string as "\uD834\uDD1E". Ideally, JWS be represented in a JSON string as "\uD834\uDD1E". Ideally, JWS
implementations SHOULD ensure that characters outside the Basic implementations SHOULD ensure that characters outside the Basic
Multilingual Plane are preserved and compared correctly; Multilingual Plane are preserved and compared correctly;
alternatively, if this is not possible due to these characters alternatively, if this is not possible due to these characters
exercising limitations present in the underlying JSON implementation, exercising limitations present in the underlying JSON implementation,
then input containing them MUST be rejected. then input containing them MUST be rejected.
9.4. TLS Requirements 11. References
11.1. Normative References
Implementations MUST support TLS. Which version(s) ought to be
implemented will vary over time, and depend on the widespread
deployment and known security vulnerabilities at the time of
implementation. At the time of this writing, TLS version 1.2
[RFC5246] is the most recent version, but has very limited actual
deployment, and might not be readily available in implementation
toolkits. TLS version 1.0 [RFC2246] is the most widely deployed
version, and will give the broadest interoperability.
To protect against information disclosure and tampering,
confidentiality protection MUST be applied using TLS with a
ciphersuite that provides confidentiality and integrity protection.
Whenever TLS is used, a TLS server certificate check MUST be
performed, per RFC 6125 [RFC6125].
10. References
10.1. Normative References
[ECMAScript] [ECMAScript]
Ecma International, "ECMAScript Language Specification, Ecma International, "ECMAScript Language Specification,
5.1 Edition", ECMA 262, June 2011. 5.1 Edition", ECMA 262, June 2011.
[I-D.ietf-json-rfc4627bis]
Bray, T., "The JSON Data Interchange Format",
draft-ietf-json-rfc4627bis-07 (work in progress),
November 2013.
[IANA.MediaTypes] [IANA.MediaTypes]
Internet Assigned Numbers Authority (IANA), "MIME Media Internet Assigned Numbers Authority (IANA), "MIME Media
Types", 2005. Types", 2005.
[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),
October 2013. November 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),
October 2013. November 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 [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
skipping to change at page 27, line 24 skipping to change at page 27, line 38
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.
[USA15] Davis, M., Whistler, K., and M. Deurst, "Unicode
Normalization Forms", Unicode Standard Annex 15, 09 2009.
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
[W3C.WD-xmldsig-bestpractices-20110809] [W3C.WD-xmldsig-bestpractices-20110809]
Datta, P. and F. Hirsch, "XML Signature Best Practices", Datta, P. and F. Hirsch, "XML Signature Best Practices",
World Wide Web Consortium WD WD-xmldsig-bestpractices- World Wide Web Consortium WD WD-xmldsig-bestpractices-
20110809, August 2011, <http://www.w3.org/TR/2011/ 20110809, August 2011, <http://www.w3.org/TR/2011/
WD-xmldsig-bestpractices-20110809>. WD-xmldsig-bestpractices-20110809>.
10.2. Informative References 11.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), October 2013. (work in progress), November 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), October 2013. progress), November 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 44, line 39 skipping to change at page 44, line 39
"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
ZJTkVEIl0sDQogImh0dHA6Ly9leGFtcGxlLmNvbS9VTkRFRklORUQiOnRydWUNCn0. ZJTkVEIl0sDQogImh0dHA6Ly9leGFtcGxlLmNvbS9VTkRFRklORUQiOnRydWUNCn0.
RkFJTA. RkFJTA.
Appendix E. Acknowledgements Appendix E. Detached Content
In some contexts, it is useful integrity protect content that is not
itself contained in a JWS object. One way to do this is create a JWS
object in the normal fashion using a representation of the content as
the payload, but then delete the payload representation from the JWS,
and send this modified object to the recipient, rather than the JWS.
When using the JWS Compact Serialization, the deletion is
accomplished by replacing the second field (which contains
BASE64URL(JWS Payload)) value with the empty string; when using the
JWS JSON Serialization, the deletion is accomplished by deleting the
"payload" member. This method assumes that the recipient can
reconstruct the exact payload used in the JWS. To use the modified
object, the recipient reconstructs the JWS by re-inserting the
payload representation into the modified object, and uses the
resulting JWS in the usual manner. Note that this method needs no
support from JWS libraries, as applications can use this method by
modifying the inputs and outputs of standard JWS libraries.
Appendix F. Acknowledgements
Solutions for signing JSON content were previously explored by Magic Solutions for signing JSON content were previously explored by Magic
Signatures [MagicSignatures], JSON Simple Sign [JSS], and Canvas Signatures [MagicSignatures], JSON Simple Sign [JSS], and Canvas
Applications [CanvasApp], all of which influenced this draft. Applications [CanvasApp], all of which influenced this draft.
Thanks to Axel Nennker for his early implementation and feedback on Thanks to Axel Nennker for his early implementation and feedback on
the JWS and JWE specifications. the JWS and JWE specifications.
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,
skipping to change at page 45, line 17 skipping to change at page 45, line 36
Dirk Balfanz, Richard Barnes, Brian Campbell, Breno de Medeiros, Dick Dirk Balfanz, Richard Barnes, Brian Campbell, Breno de Medeiros, Dick
Hardt, Joe Hildebrand, Jeff Hodges, Edmund Jay, Yaron Y. Goland, Ben Hardt, Joe Hildebrand, Jeff Hodges, Edmund Jay, Yaron Y. Goland, Ben
Laurie, James Manger, Matt Miller, Tony Nadalin, Axel Nennker, John Laurie, James Manger, Matt Miller, Tony Nadalin, Axel Nennker, John
Panzer, Emmanuel Raviart, Eric Rescorla, Jim Schaad, Paul Tarjan, Panzer, Emmanuel Raviart, Eric Rescorla, Jim Schaad, Paul Tarjan,
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 G. 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 ]]
-18
o Updated the mandatory-to-implement (MTI) language to say that
applications using this specification need to specify what
serialization and serialization features are used for that
application, addressing issue #119.
o Changes to address editorial and minor issues #25, #89, #97, #110,
#114, #115, #116, #117, #120, and #184.
o Added and used Header Parameter Description registry field.
-17 -17
o Refined the "typ" and "cty" definitions to always be MIME Media o Refined the "typ" and "cty" definitions to always be MIME Media
Types, with the omission of "application/" prefixes recommended Types, with the omission of "application/" prefixes recommended
for brevity, addressing issue #50. for brevity, addressing issue #50.
o Updated the mandatory-to-implement (MTI) language to say that o Updated the mandatory-to-implement (MTI) language to say that
general-purpose implementations must implement the single general-purpose implementations must implement the single
signature/MAC value case for both serializations whereas special- signature/MAC value case for both serializations whereas special-
purpose implementations can implement just one serialization if purpose implementations can implement just one serialization if
skipping to change at page 51, line 42 skipping to change at page 52, line 25
Michael B. Jones Michael B. Jones
Microsoft Microsoft
Email: mbj@microsoft.com Email: mbj@microsoft.com
URI: http://self-issued.info/ URI: http://self-issued.info/
John Bradley John Bradley
Ping Identity Ping Identity
Email: ve7jtb@ve7jtb.com Email: ve7jtb@ve7jtb.com
URI: http://www.thread-safe.com/
Nat Sakimura Nat Sakimura
Nomura Research Institute Nomura Research Institute
Email: n-sakimura@nri.co.jp Email: n-sakimura@nri.co.jp
URI: http://nat.sakimura.org/
 End of changes. 84 change blocks. 
173 lines changed or deleted 218 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/