draft-ietf-jose-json-web-signature-13.txt   draft-ietf-jose-json-web-signature-14.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: January 16, 2014 Ping Identity Expires: January 30, 2014 Ping Identity
N. Sakimura N. Sakimura
NRI NRI
July 15, 2013 July 29, 2013
JSON Web Signature (JWS) JSON Web Signature (JWS)
draft-ietf-jose-json-web-signature-13 draft-ietf-jose-json-web-signature-14
Abstract Abstract
JSON Web Signature (JWS) is a means of representing content secured JSON Web Signature (JWS) is a means of representing content secured
with digital signatures or Message Authentication Codes (MACs) using with digital signatures or Message Authentication Codes (MACs) using
JavaScript Object Notation (JSON) based data structures. JavaScript Object Notation (JSON) based data structures.
Cryptographic algorithms and identifiers for use with this Cryptographic algorithms and identifiers for use with this
specification are described in the separate JSON Web Algorithms (JWA) specification are described in the separate JSON Web Algorithms (JWA)
specification. Related encryption capabilities are described in the specification. Related encryption capabilities are described in the
separate JSON Web Encryption (JWE) specification. separate JSON Web Encryption (JWE) specification.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 16, 2014. This Internet-Draft will expire on January 30, 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 11, line 11 skipping to change at page 11, line 11
When used with a JWK, the "kid" value can be used to match a JWK When used with a JWK, the "kid" value can be used to match a JWK
"kid" parameter value. "kid" parameter value.
4.1.8. "typ" (Type) Header Parameter 4.1.8. "typ" (Type) Header Parameter
The "typ" (type) header parameter MAY be used to declare the type of The "typ" (type) header parameter MAY be used to declare the type of
this complete JWS object in an application-specific manner in this complete JWS object in an application-specific manner in
contexts where this is useful to the application. This parameter has contexts where this is useful to the application. This parameter has
no effect upon the JWS processing. The type value "JOSE" MAY be used no effect upon the JWS processing. The type value "JOSE" MAY be used
to indicate that this object is a JWS or JWE using the JWS Compact by applications to indicate that this object is a JWS or JWE using
Serialization or the JWE Compact Serialization. The type value the JWS Compact Serialization or the JWE Compact Serialization. The
"JOSE+JSON" MAY be used to indicate that this object is a JWS or JWE type value "JOSE+JSON" MAY be used by applications to indicate that
using the JWS JSON Serialization or the JWE JSON Serialization. this object is a JWS or JWE using the JWS JSON Serialization or the
Other type values MAY be used, and if not understood, SHOULD be JWE JSON Serialization. Other type values MAY be used, and if not
ignored. The "typ" value is a case sensitive string. Use of this understood, SHOULD be ignored. The "typ" value is a case sensitive
header parameter is OPTIONAL. string. Use of this header parameter is OPTIONAL.
MIME Media Type [RFC2046] values MAY be used as "typ" values. MIME Media Type [RFC2046] values MAY be used as "typ" values.
"typ" values SHOULD either be registered in the IANA JSON Web "typ" values SHOULD either be registered in the IANA JSON Web
Signature and Encryption Type Values registry Section 8.2 or be a Signature and Encryption Type Values registry Section 8.2 or be a
value that contains a Collision Resistant Namespace. value that contains a Collision Resistant Namespace.
4.1.9. "cty" (Content Type) Header Parameter 4.1.9. "cty" (Content Type) Header Parameter
The "cty" (content type) header parameter MAY be used to declare the The "cty" (content type) header parameter MAY be used to declare the
skipping to change at page 16, line 45 skipping to change at page 16, line 45
that are integrity protected are still base64url encoded.) that are integrity protected are still base64url encoded.)
o The Encoded JWS Payload value is stored in the "payload" member. o The Encoded JWS Payload value is stored in the "payload" member.
o There can be multiple signature and/or MAC values, rather than o There can be multiple signature and/or MAC values, rather than
just one. A JSON array in the "signatures" member is used to hold just one. A JSON array in the "signatures" member is used to hold
values that are specific to a particular signature or MAC values that are specific to a particular signature or MAC
computation, with one array element per signature/MAC represented. computation, with one array element per signature/MAC represented.
These array elements are JSON objects. These array elements are JSON objects.
o Each Encoded JWS Signature value is stored in the "signature" o Each Encoded JWS Signature value, if non-empty, is stored in the
member of a JSON object that is an element of the "signatures" "signature" member of a JSON object that is an element of the
array. "signatures" array.
o Each Encoded JWS Header value, which is a base64url encoded set of o Each Encoded JWS Header value, which is a base64url encoded set of
header parameter values that are included in the signature/MAC header parameter values that are included in the signature/MAC
computation, if non-empty, is stored in the "protected" member of computation, if non-empty, is stored in the "protected" member of
the corresponding element of the "signatures" array. the corresponding element of the "signatures" array.
o Unlike the JWS Compact Serialization, in the JWS JSON o Unlike the JWS Compact Serialization, in the JWS JSON
Serialization there can also be header parameter values that are Serialization there can also be header parameter values that are
not included in the signature/MAC computation. If present, not included in the signature/MAC computation. If present,
unprotected header parameter values are represented as an unprotected header parameter values are represented as an
skipping to change at page 27, line 48 skipping to change at page 27, line 48
[W3C.CR-xmldsig-core2-20120124] [W3C.CR-xmldsig-core2-20120124]
Eastlake, D., Reagle, J., Yiu, K., Solo, D., Datta, P., Eastlake, D., Reagle, J., Yiu, K., Solo, D., Datta, P.,
Hirsch, F., Cantor, S., and T. Roessler, "XML Signature Hirsch, F., Cantor, S., and T. Roessler, "XML Signature
Syntax and Processing Version 2.0", World Wide Web Syntax and Processing Version 2.0", World Wide Web
Consortium CR CR-xmldsig-core2-20120124, January 2012, Consortium CR CR-xmldsig-core2-20120124, January 2012,
<http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124>. <http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124>.
Appendix A. JWS Examples Appendix A. JWS Examples
This section provides several examples of JWSs. While these examples This section provides several examples of JWSs. While the first
all represent JSON Web Tokens (JWTs) [JWT], the payload can be any three examples all represent JSON Web Tokens (JWTs) [JWT], the
base64url encoded content. payload can be any octet sequence, as shown in Appendix A.4.
A.1. Example JWS using HMAC SHA-256 A.1. Example JWS using HMAC SHA-256
A.1.1. Encoding A.1.1. Encoding
The following example JWS Header declares that the data structure is The following example JWS Header declares that the data structure is
a JSON Web Token (JWT) [JWT] and the JWS Signing Input is secured a JSON Web Token (JWT) [JWT] and the JWS Signing Input is secured
using the HMAC SHA-256 algorithm. using the HMAC SHA-256 algorithm.
{"typ":"JWT", {"typ":"JWT",
skipping to change at page 46, line 4 skipping to change at page 46, line 4
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 F. Document History
[[ to be removed by the RFC editor before publication as an RFC ]] [[ to be removed by the RFC editor before publication as an RFC ]]
-14
o Stated that the "signature" parameter is to be omitted in the JWS
JSON Serialization when its value would be empty (which is only
the case for a Plaintext JWS).
-13 -13
o Made all header parameter values be per-signature/MAC, addressing o Made all header parameter values be per-signature/MAC, addressing
issue #24. issue #24.
-12 -12
o Clarified that the "typ" and "cty" header parameters are used in o Clarified that the "typ" and "cty" header parameters are used in
an application-specific manner and have no effect upon the JWS an application-specific manner and have no effect upon the JWS
processing. processing.
 End of changes. 8 change blocks. 
17 lines changed or deleted 23 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/