draft-ietf-oauth-json-web-token-06.txt   draft-ietf-oauth-json-web-token-07.txt 
OAuth Working Group M. Jones OAuth Working Group M. Jones
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track J. Bradley Intended status: Standards Track J. Bradley
Expires: June 30, 2013 Ping Identity Expires: October 25, 2013 Ping Identity
N. Sakimura N. Sakimura
NRI NRI
December 27, 2012 April 23, 2013
JSON Web Token (JWT) JSON Web Token (JWT)
draft-ietf-oauth-json-web-token-06 draft-ietf-oauth-json-web-token-07
Abstract Abstract
JSON Web Token (JWT) is a compact URL-safe means of representing JSON Web Token (JWT) is a compact URL-safe means of representing
claims to be transferred between two parties. The claims in a JWT claims to be transferred between two parties. The claims in a JWT
are encoded as a JavaScript Object Notation (JSON) object that is are encoded as a JavaScript Object Notation (JSON) object that is
used as the payload of a JSON Web Signature (JWS) structure or as the used as the payload of a JSON Web Signature (JWS) structure or as the
plaintext of a JSON Web Encryption (JWE) structure, enabling the plaintext of a JSON Web Encryption (JWE) structure, enabling the
claims to be digitally signed or MACed and/or encrypted. claims to be digitally signed or MACed and/or encrypted.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 June 30, 2013. This Internet-Draft will expire on October 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. JSON Web Token (JWT) Overview . . . . . . . . . . . . . . . . 6 3. JSON Web Token (JWT) Overview . . . . . . . . . . . . . . . . 7
3.1. Example JWT . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Example JWT . . . . . . . . . . . . . . . . . . . . . . . 7
4. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Reserved Claim Names . . . . . . . . . . . . . . . . . . . 7 4.1. Reserved Claim Names . . . . . . . . . . . . . . . . . . . 8
4.1.1. "iss" (Issuer) Claim . . . . . . . . . . . . . . . . . 8 4.1.1. "iss" (Issuer) Claim . . . . . . . . . . . . . . . . . 9
4.1.2. "sub" (Subject) Claim . . . . . . . . . . . . . . . . 8 4.1.2. "sub" (Subject) Claim . . . . . . . . . . . . . . . . 9
4.1.3. "aud" (Audience) Claim . . . . . . . . . . . . . . . . 8 4.1.3. "aud" (Audience) Claim . . . . . . . . . . . . . . . . 9
4.1.4. "exp" (Expiration Time) Claim . . . . . . . . . . . . 8 4.1.4. "exp" (Expiration Time) Claim . . . . . . . . . . . . 9
4.1.5. "nbf" (Not Before) Claim . . . . . . . . . . . . . . . 8 4.1.5. "nbf" (Not Before) Claim . . . . . . . . . . . . . . . 9
4.1.6. "iat" (Issued At) Claim . . . . . . . . . . . . . . . 9 4.1.6. "iat" (Issued At) Claim . . . . . . . . . . . . . . . 10
4.1.7. "jti" (JWT ID) Claim . . . . . . . . . . . . . . . . . 9 4.1.7. "jti" (JWT ID) Claim . . . . . . . . . . . . . . . . . 10
4.1.8. "typ" (Type) Claim . . . . . . . . . . . . . . . . . . 9 4.1.8. "typ" (Type) Claim . . . . . . . . . . . . . . . . . . 10
4.2. Public Claim Names . . . . . . . . . . . . . . . . . . . . 9 4.2. Public Claim Names . . . . . . . . . . . . . . . . . . . . 10
4.3. Private Claim Names . . . . . . . . . . . . . . . . . . . 9 4.3. Private Claim Names . . . . . . . . . . . . . . . . . . . 10
5. JWT Header . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. JWT Header . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. "typ" (Type) Header Parameter . . . . . . . . . . . . . . 10 5.1. "typ" (Type) Header Parameter . . . . . . . . . . . . . . 11
5.2. "cty" (Content Type) Header Parameter . . . . . . . . . . 10 5.2. "cty" (Content Type) Header Parameter . . . . . . . . . . 11
6. Plaintext JWTs . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Plaintext JWTs . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Example Plaintext JWT . . . . . . . . . . . . . . . . . . 11 6.1. Example Plaintext JWT . . . . . . . . . . . . . . . . . . 12
7. Rules for Creating and Validating a JWT . . . . . . . . . . . 11 7. Rules for Creating and Validating a JWT . . . . . . . . . . . 12
7.1. String Comparison Rules . . . . . . . . . . . . . . . . . 13 7.1. String Comparison Rules . . . . . . . . . . . . . . . . . 14
8. Cryptographic Algorithms . . . . . . . . . . . . . . . . . . . 14 8. Cryptographic Algorithms . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9.1. JSON Web Token Claims Registry . . . . . . . . . . . . . . 14 9.1. JSON Web Token Claims Registry . . . . . . . . . . . . . . 15
9.1.1. Registration Template . . . . . . . . . . . . . . . . 15 9.1.1. Registration Template . . . . . . . . . . . . . . . . 16
9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 15 9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 16
9.2. Sub-Namespace Registration of 9.2. Sub-Namespace Registration of
urn:ietf:params:oauth:token-type:jwt . . . . . . . . . . . 16 urn:ietf:params:oauth:token-type:jwt . . . . . . . . . . . 17
9.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 16 9.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 17
9.3. JSON Web Signature and Encryption Type Values 9.3. JSON Web Signature and Encryption Type Values
Registration . . . . . . . . . . . . . . . . . . . . . . . 16 Registration . . . . . . . . . . . . . . . . . . . . . . . 17
9.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 16 9.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 17
9.4. Media Type Registration . . . . . . . . . . . . . . . . . 16 9.4. Media Type Registration . . . . . . . . . . . . . . . . . 17
9.4.1. Registry Contents . . . . . . . . . . . . . . . . . . 16 9.4.1. Registry Contents . . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . . 19 Appendix A. Example Encrypted JWT . . . . . . . . . . . . . . . . 20
Appendix A. Example Encrypted JWT . . . . . . . . . . . . . . . . 19 Appendix B. Relationship of JWTs to SAML Assertions . . . . . . . 21
Appendix B. Relationship of JWTs to SAML Assertions . . . . . . . 20 Appendix C. Relationship of JWTs to Simple Web Tokens (SWTs) . . 22
Appendix C. Relationship of JWTs to Simple Web Tokens (SWTs) . . 21 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 22
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 21 Appendix E. Document History . . . . . . . . . . . . . . . . . . 23
Appendix E. Open Issues . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Appendix F. Document History . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
JSON Web Token (JWT) is a compact claims representation format JSON Web Token (JWT) is a compact claims representation format
intended for space constrained environments such as HTTP intended for space constrained environments such as HTTP
Authorization headers and URI query parameters. JWTs encode claims Authorization headers and URI query parameters. JWTs encode claims
to be transmitted as a JavaScript Object Notation (JSON) [RFC4627] to be transmitted as a JavaScript Object Notation (JSON) [RFC4627]
object that is used as the payload of a JSON Web Signature (JWS) object that is used as the payload of a JSON Web Signature (JWS)
[JWS] structure or as the plaintext of a JSON Web Encryption (JWE) [JWS] structure or as the plaintext of a JSON Web Encryption (JWE)
[JWE] structure, enabling the claims to be digitally signed or MACed [JWE] structure, enabling the claims to be digitally signed or MACed
and/or encrypted. and/or encrypted. JWTs are always represented using the JWS Compact
Serialization or the JWE Compact Serialization.
The suggested pronunciation of JWT is the same as the English word The suggested pronunciation of JWT is the same as the English word
"jot". "jot".
1.1. Notational Conventions 1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in Key words for use in document are to be interpreted as described in Key words for use in
RFCs to Indicate Requirement Levels [RFC2119]. RFCs to Indicate Requirement Levels [RFC2119].
skipping to change at page 4, line 38 skipping to change at page 5, line 39
JSON Web Token (JWT) A string representing a set of claims as a JSON JSON Web Token (JWT) A string representing a set of claims as a JSON
object that is encoded in a JWS or JWE, enabling the claims to be object that is encoded in a JWS or JWE, enabling the claims to be
digitally signed or MACed and/or encrypted. digitally signed or MACed and/or encrypted.
Base64url Encoding The URL- and filename-safe Base64 encoding Base64url Encoding The URL- and filename-safe Base64 encoding
described in RFC 4648 [RFC4648], Section 5, with the (non URL- described in RFC 4648 [RFC4648], Section 5, with the (non URL-
safe) '=' padding characters omitted, as permitted by Section 3.2. safe) '=' padding characters omitted, as permitted by Section 3.2.
(See Appendix C of [JWS] for notes on implementing base64url (See Appendix C of [JWS] for notes on implementing base64url
encoding without padding.) encoding without padding.)
JSON Text Object A UTF-8 encoded text string representing a JSON JSON Text Object A UTF-8 [RFC3629] encoded text string representing
object; the syntax of JSON objects is defined in Section 2.2 of a JSON object; the syntax of JSON objects is defined in Section
[RFC4627]. 2.2 of [RFC4627].
JWT Header A JSON Text Object that describes the cryptographic JWT Header A JSON Text Object that describes the cryptographic
operations applied to the JWT. When the JWT is digitally signed operations applied to the JWT. When the JWT is digitally signed
or MACed, the JWT Header is a JWS Header. When the JWT is or MACed, the JWT Header is a JWS Header. When the JWT is
encrypted, the JWT Header is a JWE Header. encrypted, the JWT Header is a JWE Header.
Header Parameter Name The name of a member of the JWT Header. Header Parameter Name The name of a member of the JWT Header.
Header Parameter Value The value of a member of the JWT Header. Header Parameter Value The value of a member of the JWT Header.
JWT Claims Set A JSON Text Object that contains the Claims conveyed JWT Claims Set A JSON Text Object that contains the Claims conveyed
by the JWT, where each claim is represented as a name/value pair by the JWT.
of a Claim Name and a Claim Value.
Claim A piece of information asserted about a subject. Here, Claims Claim A piece of information asserted about a subject. A Claim is
are represented name/value pairs, consisting of a Claim Name and a represented as a name/value pair consisting of a Claim Name and a
Claim Value. Claim Value.
Claim Name The name portion of a Claim representation. A Claim Name Claim Name The name portion of a Claim representation. A Claim Name
is always a string. is always a string.
Claim Value The value portion of a Claim representation. A Claim Claim Value The value portion of a Claim representation. A Claim
Value can be any JSON value. Value can be any JSON value.
Encoded JWT Header Base64url encoding of the JWT Header. Encoded JWT Header Base64url encoding of the JWT Header.
Nested JWT A JWT in which nested signing or encryption are employed. Nested JWT A JWT in which nested signing and/or encryption are
In nested JWTs, a JWT is used as the payload or plaintext value of employed. In nested JWTs, a JWT is used as the payload or
an enclosing JWS or JWE structure, respectively. plaintext value of an enclosing JWS or JWE structure,
respectively.
Plaintext JWT A JWT whose Claims are not integrity protected or Plaintext JWT A JWT whose Claims are not integrity protected or
encrypted. encrypted.
Collision Resistant Namespace A namespace that allows names to be Collision Resistant Namespace A namespace that allows names to be
allocated in a manner such that they are highly unlikely to allocated in a manner such that they are highly unlikely to
collide with other names. For instance, collision resistance can collide with other names. For instance, collision resistance can
be achieved through administrative delegation of portions of the be achieved through administrative delegation of portions of the
namespace or through use of collision-resistant name allocation namespace or through use of collision-resistant name allocation
functions. Examples of Collision Resistant Namespaces include: functions. Examples of Collision Resistant Namespaces include:
skipping to change at page 6, line 30 skipping to change at page 7, line 30
MACed, with the JWT Claims Set being the JWS Payload. If the JWT MACed, with the JWT Claims Set being the JWS Payload. If the JWT
Header is a JWE Header, the JWT is represented as a JWE, and the Header is a JWE Header, the JWT is represented as a JWE, and the
claims are encrypted, with the JWT Claims Set being the input claims are encrypted, with the JWT Claims Set being the input
Plaintext. A JWT may be enclosed in another JWE or JWS structure to Plaintext. A JWT may be enclosed in another JWE or JWS structure to
create a Nested JWT, enabling nested signing and encryption to be create a Nested JWT, enabling nested signing and encryption to be
performed. performed.
A JWT is represented as a sequence of URL-safe parts separated by A JWT is represented as a sequence of URL-safe parts separated by
period ('.') characters. Each part contains a base64url encoded period ('.') characters. Each part contains a base64url encoded
value. The number of parts in the JWT is dependent upon the value. The number of parts in the JWT is dependent upon the
representation of the resulting JWS or JWE. representation of the resulting JWS or JWE object using the JWS
Compact Serialization or the JWE Compact Serialization.
3.1. Example JWT 3.1. Example JWT
The following example JWT Header declares that the encoded object is The following example JWT Header declares that the encoded object is
a JSON Web Token (JWT) and the JWT is MACed using the HMAC SHA-256 a JSON Web Token (JWT) and the JWT is MACed using the HMAC SHA-256
algorithm: algorithm:
{"typ":"JWT", {"typ":"JWT",
"alg":"HS256"} "alg":"HS256"}
Base64url encoding the bytes of the UTF-8 representation of the JWT Base64url encoding the octets of the UTF-8 representation of the JWT
Header yields this Encoded JWS Header value, which is used as the Header yields this Encoded JWS Header value, which is used as the
Encoded JWT Header: Encoded JWT Header:
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
The following is an example of a JWT Claims Set: The following is an example of a JWT Claims Set:
{"iss":"joe", {"iss":"joe",
"exp":1300819380, "exp":1300819380,
"http://example.com/is_root":true} "http://example.com/is_root":true}
Base64url encoding the bytes of the UTF-8 representation of the JSON Base64url encoding the octets of the UTF-8 representation of the JSON
Claims Set yields this Encoded JWS Payload (with line breaks for Claims Set yields this Encoded JWS Payload (with line breaks for
display purposes only): display purposes only):
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly
9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ 9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ
Signing the Encoded JWS Header and Encoded JWS Payload with the HMAC Signing the Encoded JWS Header and Encoded JWS Payload with the HMAC
SHA-256 algorithm and base64url encoding the signature in the manner SHA-256 algorithm and base64url encoding the signature in the manner
specified in [JWS], yields this Encoded JWS Signature: specified in [JWS], yields this Encoded JWS Signature:
skipping to change at page 7, line 37 skipping to change at page 8, line 37
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
This computation is illustrated in more detail in Appendix A.1 of This computation is illustrated in more detail in Appendix A.1 of
[JWS]. See Appendix A for an example of an encrypted JWT. [JWS]. See Appendix A for an example of an encrypted JWT.
4. JWT Claims 4. JWT Claims
The JWT Claims Set represents a JSON object whose members are the The JWT Claims Set represents a JSON object whose members are the
claims conveyed by the JWT. The Claim Names within a JWT Claims Set claims conveyed by the JWT. The Claim Names within a JWT Claims Set
MUST be unique; JWTs with duplicate Claim Names MUST be rejected. MUST be unique; JWTs with duplicate Claim Names MUST be rejected.
Note however, that the set of claims that a JWT must contain to be
considered valid is context-dependent and is outside the scope of The set of claims that a JWT must contain to be considered valid is
this specification. When used in a security-related context, context-dependent and is outside the scope of this specification.
implementations MUST understand and support all of the claims Specific applications of JWTs will require implementations to
present; otherwise, the JWT MUST be rejected for processing. understand and process some claims in particular ways. However, in
the absence of such requirements, all claims that are not understood
by implementations SHOULD be ignored.
There are three classes of JWT Claim Names: Reserved Claim Names, There are three classes of JWT Claim Names: Reserved Claim Names,
Public Claim Names, and Private Claim Names. Public Claim Names, and Private Claim Names.
4.1. Reserved Claim Names 4.1. Reserved Claim Names
The following Claim Names are reserved. None of the claims defined The following Claim Names are reserved. None of the claims defined
below are intended to be mandatory to use, but rather, provide a below are intended to be mandatory to use, but rather, provide a
starting point for a set of useful, interoperable claims. All the starting point for a set of useful, interoperable claims. All the
names are short because a core goal of JWTs is for the representation names are short because a core goal of JWTs is for the representation
skipping to change at page 10, line 15 skipping to change at page 11, line 15
5. JWT Header 5. JWT Header
The members of the JSON object represented by the JWT Header describe The members of the JSON object represented by the JWT Header describe
the cryptographic operations applied to the JWT and optionally, the cryptographic operations applied to the JWT and optionally,
additional properties of the JWT. The member names within the JWT additional properties of the JWT. The member names within the JWT
Header are referred to as Header Parameter Names. These names MUST Header are referred to as Header Parameter Names. These names MUST
be unique; JWTs with duplicate Header Parameter Names MUST be be unique; JWTs with duplicate Header Parameter Names MUST be
rejected. The corresponding values are referred to as Header rejected. The corresponding values are referred to as Header
Parameter Values. Parameter Values.
Implementations MUST understand the entire contents of the header;
otherwise, the JWT MUST be rejected for processing.
JWS Header Parameters are defined by [JWS]. JWE Header Parameters JWS Header Parameters are defined by [JWS]. JWE Header Parameters
are defined by [JWE]. This specification further specifies the use are defined by [JWE]. This specification further specifies the use
of the following header parameter in both the cases where the JWT is of the following header parameter in both the cases where the JWT is
a JWS and where it is a JWE. a JWS and where it is a JWE.
5.1. "typ" (Type) Header Parameter 5.1. "typ" (Type) Header Parameter
The "typ" (type) header parameter is used to declare the type of this The "typ" (type) header parameter is used to declare the type of this
object. If present, it is RECOMMENDED that its value be either "JWT" object. If present, it is RECOMMENDED that its value be either "JWT"
or "urn:ietf:params:oauth:token-type:jwt" to indicate that this or "urn:ietf:params:oauth:token-type:jwt" to indicate that this
skipping to change at page 11, line 15 skipping to change at page 12, line 12
defined in JSON Web Algorithms (JWA) [JWA]; it is a JWS with the defined in JSON Web Algorithms (JWA) [JWA]; it is a JWS with the
empty string for its JWS Signature value. empty string for its JWS Signature value.
6.1. Example Plaintext JWT 6.1. Example Plaintext JWT
The following example JWT Header declares that the encoded object is The following example JWT Header declares that the encoded object is
a Plaintext JWT: a Plaintext JWT:
{"alg":"none"} {"alg":"none"}
Base64url encoding the bytes of the UTF-8 representation of the JWT Base64url encoding the octets of the UTF-8 representation of the JWT
Header yields this Encoded JWT Header: Header yields this Encoded JWT Header:
eyJhbGciOiJub25lIn0 eyJhbGciOiJub25lIn0
The following is an example of a JWT Claims Set: The following is an example of a JWT Claims Set:
{"iss":"joe", {"iss":"joe",
"exp":1300819380, "exp":1300819380,
"http://example.com/is_root":true} "http://example.com/is_root":true}
Base64url encoding the bytes of the UTF-8 representation of the JSON Base64url encoding the octets of the UTF-8 representation of the JSON
Claims Set yields this Encoded JWS Payload (with line breaks for Claims Set yields this Encoded JWS Payload (with line breaks for
display purposes only): display purposes only):
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
The Encoded JWS Signature is the empty string. The Encoded JWS Signature is the empty string.
Concatenating these parts in this order with period ('.') characters Concatenating these parts in this order with period ('.') characters
between the parts yields this complete JWT (with line breaks for between the parts yields this complete JWT (with line breaks for
skipping to change at page 12, line 9 skipping to change at page 13, line 5
7. Rules for Creating and Validating a JWT 7. Rules for Creating and Validating a JWT
To create a JWT, one MUST perform these steps. The order of the To create a JWT, 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 a JWT Claims Set containing the desired claims. Note that 1. Create a JWT Claims Set containing the desired claims. Note that
white space is explicitly allowed in the representation and no white space is explicitly allowed in the representation and no
canonicalization is performed before encoding. canonicalization is performed before encoding.
2. Let the Message be the bytes of the UTF-8 representation of the 2. Let the Message be the octets of the UTF-8 representation of the
JWT Claims Set. JWT Claims Set.
3. Create a JWT Header containing the desired set of header 3. Create a JWT Header containing the desired set of header
parameters. The JWT MUST conform to either the [JWS] or [JWE] parameters. The JWT MUST conform to either the [JWS] or [JWE]
specifications. Note that white space is explicitly allowed in specifications. Note that white space is explicitly allowed in
the representation and no canonicalization is performed before the representation and no canonicalization is performed before
encoding. encoding.
4. Base64url encode the bytes of the UTF-8 representation of the JWT 4. Base64url encode the octets of the UTF-8 representation of the
Header. Let this be the Encoded JWT Header. JWT Header. Let this be the Encoded JWT Header.
5. Depending upon whether the JWT is a JWS or JWE, there are two 5. Depending upon whether the JWT is a JWS or JWE, there are two
cases: cases:
* If the JWT is a JWS, create a JWS using the JWT Header as the * If the JWT is a JWS, create a JWS using the JWT Header as the
JWS Header and the Message as the JWS Payload; all steps JWS Header and the Message as the JWS Payload; all steps
specified in [JWS] for creating a JWS MUST be followed. specified in [JWS] for creating a JWS MUST be followed.
* Else, if the JWT is a JWE, create a JWE using the JWT Header * Else, if the JWT is a JWE, create a JWE using the JWT Header
as the JWE Header and the Message as the JWE Plaintext; all as the JWE Header and the Message as the JWE Plaintext; all
skipping to change at page 13, line 10 skipping to change at page 14, line 7
3. The Encoded JWT Header MUST be successfully base64url decoded 3. The Encoded JWT Header MUST be successfully base64url decoded
following the restriction given in this specification that no following the restriction given in this specification that no
padding characters have been used. padding characters have been used.
4. The resulting JWT Header MUST be completely valid JSON syntax 4. The resulting JWT Header MUST be completely valid JSON syntax
conforming to RFC 4627 [RFC4627]. conforming to RFC 4627 [RFC4627].
5. The resulting JWT Header MUST be validated to only include 5. The resulting JWT Header MUST be validated to only include
parameters and values whose syntax and semantics are both parameters and values whose syntax and semantics are both
understood and supported. understood and supported or that are specified as being ignored
when not understood.
6. Determine whether the JWT is a JWS or a JWE by examining the 6. Determine whether the JWT is a JWS or a JWE by examining the
"alg" (algorithm) header value and optionally, the "enc" "alg" (algorithm) header value and optionally, the "enc"
(encryption method) header value, if present. (encryption method) header value, if present.
7. Depending upon whether the JWT is a JWS or JWE, there are two 7. Depending upon whether the JWT is a JWS or JWE, there are two
cases: cases:
* If the JWT is a JWS, all steps specified in [JWS] for * If the JWT is a JWS, all steps specified in [JWS] for
validating a JWS MUST be followed. Let the Message be the validating a JWS MUST be followed. Let the Message be the
result of base64url decoding the JWS Payload. result of base64url decoding the JWS Payload.
* Else, if the JWT is a JWE, all steps specified in [JWE] for * Else, if the JWT is a JWE, all steps specified in [JWE] for
validating a JWE MUST be followed. Let the Message be the validating a JWE MUST be followed. Let the Message be the
JWE Plaintext. JWE Plaintext.
8. If the JWT Header contains a "cty" (content type) value of 8. If the JWT Header contains a "cty" (content type) value of
"JWT", then the Message contains a JWT that was the subject of "JWT", then the Message is a JWT that was the subject of nested
nested signing or encryption operations. In this case, return signing or encryption operations. In this case, return to Step
to Step 1, using the Message as the JWT. 1, using the Message as the JWT.
9. Otherwise, let the JWT Claims Set be the Message. 9. Otherwise, let the JWT Claims Set be the Message.
10. The JWT Claims Set MUST be completely valid JSON syntax 10. The JWT Claims Set MUST be completely valid JSON syntax
conforming to RFC 4627 [RFC4627]. conforming to RFC 4627 [RFC4627].
11. When used in a security-related context, the JWT Claims Set MUST
be validated to only include claims whose syntax and semantics
are both understood and supported.
7.1. String Comparison Rules 7.1. String Comparison Rules
Processing a JWT inevitably requires comparing known strings to Processing a JWT inevitably requires comparing known strings to
values in JSON objects. For example, in checking what the algorithm values in JSON objects. For example, in checking what the algorithm
is, the Unicode string encoding "alg" will be checked against the is, the Unicode string encoding "alg" will be checked against the
member names in the JWT Header to see if there is a matching Header member names in the JWT Header to see if there is a matching Header
Parameter Name. Parameter Name.
Comparisons between JSON strings and other Unicode strings MUST be Comparisons between JSON strings and other Unicode strings MUST be
performed by comparing Unicode code points without normalization as performed by comparing Unicode code points without normalization as
specified in the String Comparison Rules in Section 5.3 of [JWS]. specified in the String Comparison Rules in Section 5.3 of [JWS].
8. Cryptographic Algorithms 8. Cryptographic Algorithms
JWTs use JSON Web Signature (JWS) [JWS] and JSON Web Encryption (JWE) JWTs use JSON Web Signature (JWS) [JWS] and JSON Web Encryption (JWE)
[JWE] to sign and/or encrypt the contents of the JWT. [JWE] to sign and/or encrypt the contents of the JWT.
Of the JWS signing algorithms, only HMAC SHA-256 and "none" MUST be Of the JWA signing algorithms, only HMAC SHA-256 ("HS256") and "none"
implemented by conforming JWT implementations. It is RECOMMENDED MUST be implemented by conforming JWT implementations. It is
that implementations also support the RSA SHA-256 and ECDSA P-256 RECOMMENDED that implementations also support RSASSA-PKCS1-V1_5 with
SHA-256 algorithms. Support for other algorithms and key sizes is the SHA-256 hash algorithm ("RS256") and ECDSA using the P-256 curve
OPTIONAL. and the SHA-256 hash algorithm ("ES256"). Support for other
algorithms and key sizes is OPTIONAL.
If an implementation provides encryption capabilities, of the JWE If an implementation provides encryption capabilities, of the JWA
encryption algorithms, only RSA-PKCS1-1.5 with 2048 bit keys, AES- encryption algorithms, only RSAES-PKCS1-V1_5 with 2048 bit keys
128-KW, AES-256-KW, AES-128-CBC, and AES-256-CBC MUST be implemented ("RSA1_5"), AES Key Wrap with 128 and 256 bit keys ("A128KW" and
by conforming implementations. It is RECOMMENDED that "A256KW"), and the composite authenticated encryption algorithm using
implementations also support ECDH-ES with 256 bit keys, AES-128-GCM, AES CBC and HMAC SHA-2 ("A128CBC-HS256" and "A256CBC-HS512") MUST be
and AES-256-GCM. Support for other algorithms and key sizes is implemented by conforming implementations. It is RECOMMENDED that
OPTIONAL. implementations also support using ECDH-ES to agree upon a key used
to wrap the Content Encryption Key ("ECDH-ES+A128KW" and
"ECDH-ES+A256KW") and AES in Galois/Counter Mode (GCM) with 128 bit
and 256 bit keys ("A128GCM" and "A256GCM"). Support for other
algorithms and key sizes is OPTIONAL.
9. IANA Considerations 9. IANA Considerations
9.1. JSON Web Token Claims Registry 9.1. JSON Web Token Claims Registry
This specification establishes the IANA JSON Web Token Claims This specification establishes the IANA JSON Web Token Claims
registry for reserved JWT Claim Names. The registry records the registry for reserved JWT Claim Names. The registry records the
reserved Claim Name and a reference to the specification that defines reserved Claim Name and a reference to the specification that defines
it. This specification registers the Claim Names defined in it. This specification registers the Claim Names defined in
Section 4.1. Section 4.1.
skipping to change at page 17, line 9 skipping to change at page 18, line 9
the content is a JWT. the content is a JWT.
o Type Name: application o Type Name: application
o Subtype Name: jwt o Subtype Name: jwt
o Required Parameters: n/a o Required Parameters: n/a
o Optional Parameters: n/a o Optional Parameters: n/a
o Encoding considerations: JWT values are encoded as a series of o Encoding considerations: JWT values are encoded as a series of
base64url encoded values (some of which may be the empty string) base64url encoded values (some of which may be the empty string)
separated by period ('.') characters separated by period ('.') characters
o Security Considerations: See the Security Considerations section o Security Considerations: See the Security Considerations section
of this document of [[ this document ]]
o Interoperability Considerations: n/a o Interoperability Considerations: n/a
o Published Specification: [[ this document ]] o Published Specification: [[ this document ]]
o Applications that use this media type: OpenID Connect, Mozilla o Applications that use this media type: OpenID Connect, Mozilla
Browser ID, Salesforce, Google, numerous others Persona, Salesforce, Google, numerous others
o Additional Information: Magic number(s): n/a, File extension(s): o Additional Information: Magic number(s): n/a, File extension(s):
n/a, Macintosh file type code(s): n/a n/a, Macintosh file type code(s): n/a
o Person & email address to contact for further information: Michael o Person & email address to contact for further information: Michael
B. Jones, mbj@microsoft.com B. Jones, mbj@microsoft.com
o Intended Usage: COMMON o Intended Usage: COMMON
o Restrictions on Usage: none o Restrictions on Usage: none
o Author: Michael B. Jones, mbj@microsoft.com o Author: Michael B. Jones, mbj@microsoft.com
o Change Controller: IETF o Change Controller: IETF
10. Security Considerations 10. Security Considerations
skipping to change at page 17, line 46 skipping to change at page 18, line 46
Claims Set in the same manner that they do to the JWS Header. Claims Set in the same manner that they do to the JWS Header.
While syntactically, the signing and encryption operations for Nested While syntactically, the signing and encryption operations for Nested
JWTs may be applied in any order, normally senders should sign the JWTs may be applied in any order, normally senders should sign the
message and then encrypt the result (thus encrypting the signature). message and then encrypt the result (thus encrypting the signature).
This prevents attacks in which the signature is stripped, leaving This prevents attacks in which the signature is stripped, leaving
just an encrypted message, as well as providing privacy for the just an encrypted message, as well as providing privacy for the
signer. Furthermore, signatures over encrypted text are not signer. Furthermore, signatures over encrypted text are not
considered valid in many jurisdictions. considered valid in many jurisdictions.
Note that potential concerns about security issues related to the
order of signing and encryption operations are already addressed by
the underlying JWS and JWE specifications; in particular, because JWE
only supports the use of authenticated encryption algorithms,
cryptographic concerns about the potential need to sign after
encryption that apply in many contexts do not apply to this
specification.
11. References 11. References
11.1. Normative References 11.1. Normative References
[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),
December 2012. April 2013.
[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), December 2012. (work in progress), April 2013.
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", draft-ietf-jose-json-web-signature (work Signature (JWS)", draft-ietf-jose-json-web-signature (work
in progress), December 2012. in progress), April 2013.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996. November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002. Internet: Timestamps", RFC 3339, July 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005. Registration Procedures", RFC 4288, December 2005.
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006. JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace
for OAuth", RFC 6755, October 2012. for OAuth", RFC 6755, October 2012.
[USA15] Davis, M., Whistler, K., and M. Duerst, "Unicode
Normalization Forms", Unicode Standard Annex 15, 09 2009.
11.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.
[MagicSignatures] [MagicSignatures]
Panzer (editor), J., Laurie, B., and D. Balfanz, "Magic Panzer (editor), J., Laurie, B., and D. Balfanz, "Magic
skipping to change at page 19, line 48 skipping to change at page 21, line 4
[W3C.REC-xml-c14n-20010315] [W3C.REC-xml-c14n-20010315]
Boyer, J., "Canonical XML Version 1.0", World Wide Web Boyer, J., "Canonical XML Version 1.0", World Wide Web
Consortium Recommendation REC-xml-c14n-20010315, Consortium Recommendation REC-xml-c14n-20010315,
March 2001, March 2001,
<http://www.w3.org/TR/2001/REC-xml-c14n-20010315>. <http://www.w3.org/TR/2001/REC-xml-c14n-20010315>.
Appendix A. Example Encrypted JWT Appendix A. Example Encrypted JWT
This example encrypts the same claims as used in Section 3.1 to the This example encrypts the same claims as used in Section 3.1 to the
recipient using RSAES-PKCS1-V1_5 and AES CBC. AES CBC does not have recipient using RSAES-PKCS1-V1_5 and AES_128_CBC_HMAC_SHA_256.
an integrated integrity check, so a separate integrity check
calculation is performed using HMAC SHA-256, with separate encryption
and integrity keys being derived from a master key using the Concat
KDF with the SHA-256 digest function.
The following example JWE Header (with line breaks for display The following example JWE Header (with line breaks for display
purposes only) declares that: purposes only) declares that:
o the Content Master Key is encrypted to the recipient using the o the Content Encryption Key is encrypted to the recipient using the
RSAES-PKCS1-V1_5 algorithm to produce the JWE Encrypted Key and RSAES-PKCS1-V1_5 algorithm to produce the JWE Encrypted Key and
o the Plaintext is encrypted using the AES CBC algorithm with a 128 o the Plaintext is encrypted using the AES_128_CBC_HMAC_SHA_256
bit key to produce the Ciphertext, with the integrity of the algorithm to produce the Ciphertext.
Ciphertext and the parameters used to create it being secured
using the HMAC SHA-256 algorithm.
{"alg":"RSA1_5","enc":"A128CBC+HS256"} {"alg":"RSA1_5","enc":"A128CBC-HS256"}
Other than using the bytes of the UTF-8 representation of the JSON Other than using the octets of the UTF-8 representation of the JSON
Claims Set from Section 3.1 as the plaintext value, the computation Claims Set from Section 3.1 as the plaintext value, the computation
of this JWT is identical to the computation of the JWE in Appendix of this JWT is identical to the computation of the JWE in Appendix
A.2 of [JWE], including the keys used. A.2 of [JWE], including the keys used.
The final result in this example (with line breaks for display The final result in this example (with line breaks for display
purposes only) is: purposes only) is:
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDK0hTMjU2In0. eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.
pwaFh7yJPivLjjPkzC-GeAyHuy7AinGcS51AZ7TXnwkC80Ow1aW47kcT_UV54ubo EcA0HJqCj8MhE2Gu-d-wrNgxBabw3eQg7feWIelT_k0g_MOf7imKPsFqtiy3k08u
nONbeArwOVuR7shveXnwPmucwrk_3OCcHrCbE1HR-Jfme2mF_WR3zUMcwqmU0RlH 8ynLJ-f9FaPXJZxk0y9JQm5nM-CQchlwb_R-vxA3QO-MuUgqDxhFSWhcmIfvUdme
kwx9txo_sKRasjlXc8RYP-evLCmT1XRXKjtY5l44Gnh0A84hGvVfMxMfCWXh38hi ezpuGpcEBv_Z9P-RiliSGqnveR_FW8HabEbypZa6lOkkSPYOc_qVm3FV6bdRlVT3
2h8JMjQHGQ3mivVui5lbf-zzb3qXXxNO1ZYoWgs5tP1-T54QYc9Bi9wodFPWNPKB wQblSnRaGtNNad5ITsZgjdIdTUu4h6ljGXrZNaXMgGLQtwbHzr07I2qxLyaX0zIE
kY-BgewG-Vmc59JqFeprk1O08qhKQeOGCWc0WPC_n_LIpGWH6spRm7KGuYdgDMkQ tiLOZTEs3Z-a5P3s0wLkhRuFbM3nd-WXJcrPGDOPNzvGt_Qz4bOz5vB9c1UzMaZZ
bd4uuB0uPPLx_euVCdrVrA. RVVqVa0mi-Orar8uOW_wGQ.
AxY8DCtDaGlsbGljb3RoZQ. AxY8DCtDaGlsbGljb3RoZQ.
7MI2lRCaoyYx1HclVXkr8DhmDoikTmOp3IdEmm4qgBThFkqFqOs3ivXLJTku4M0f MKOle7UQrG6nSxTLX6Mqwt0orbHvAKeWnDYvpIAeZ72deHxz3roJDXQyhxx0wKaM
laMAbGG_X6K8_B-0E-7ak-Olm_-_V03oBUUGTAc-F0A. HDjUEOKIwrtkHthpqEanSBNYHZgmNOV7sln1Eu9g3J8.
OwWNxnC-BMEie-GkFHzVWiNiaV3zUHf6fCOGTwbRckU _k19B2pzd5OvZ-ngGi8cZw
Appendix B. Relationship of JWTs to SAML Assertions Appendix B. Relationship of JWTs to SAML Assertions
SAML 2.0 [OASIS.saml-core-2.0-os] provides a standard for creating SAML 2.0 [OASIS.saml-core-2.0-os] provides a standard for creating
security tokens with greater expressivity and more security options security tokens with greater expressivity and more security options
than supported by JWTs. However, the cost of this flexibility and than supported by JWTs. However, the cost of this flexibility and
expressiveness is both size and complexity. SAML's use of XML expressiveness is both size and complexity. SAML's use of XML
[W3C.CR-xml11-20021015] and XML DSIG [RFC3275] contributes to the [W3C.CR-xml11-20021015] and XML DSIG [RFC3275] contributes to the
size of SAML assertions; its use of XML and especially XML size of SAML assertions; its use of XML and especially XML
Canonicalization [W3C.REC-xml-c14n-20010315] contributes to their Canonicalization [W3C.REC-xml-c14n-20010315] contributes to their
skipping to change at page 22, line 13 skipping to change at page 23, line 11
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, Prateek Mishra, Tony Nadalin, Axel Nennker, Laurie, James Manger, Prateek Mishra, Tony Nadalin, Axel Nennker,
John Panzer, Emmanuel Raviart, David Recordon, Eric Rescorla, Jim John Panzer, Emmanuel Raviart, David Recordon, Eric Rescorla, Jim
Schaad, Paul Tarjan, Hannes Tschofenig, and Sean Turner. Schaad, Paul Tarjan, Hannes Tschofenig, and Sean Turner.
Hannes Tschofenig and Derek Atkins chaired the OAuth working group Hannes Tschofenig and Derek Atkins chaired the OAuth working group
and Sean Turner and Stephen Farrell served as Security area directors and Sean Turner and Stephen Farrell served as Security area directors
during the creation of this specification. during the creation of this specification.
Appendix E. Open Issues Appendix E. 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 ]]
The following items remain to be considered or done in this draft: -07
o Track changes to the underlying JOSE specifications.
o Should all claims continue to be required to be understood by o Defined that the default action for claims that are not understood
implementations using them when used in a security-related context is to ignore them unless otherwise specified by applications.
or should a means of declaring that specific claims may be safely
ignored if not understood should be defined? This is related to
the similar JOSE issue about whether all header fields must
continue to be understood.
Appendix F. Document History o Changed from using the term "byte" to "octet" when referring to 8
bit values.
[[ to be removed by the RFC editor before publication as an RFC ]] o Tracked encryption computation changes in the JWE specification.
-06 -06
o Changed the name of the "prn" claim to "sub" (subject) both to o Changed the name of the "prn" claim to "sub" (subject) both to
more closely align with SAML name usage and to use a more more closely align with SAML name usage and to use a more
intuitive name. intuitive name.
o Allow JWTs to have multiple audiences. o Allow JWTs to have multiple audiences.
o Applied editorial improvements suggested by Jeff Hodges, Prateek o Applied editorial improvements suggested by Jeff Hodges, Prateek
 End of changes. 48 change blocks. 
142 lines changed or deleted 138 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/