draft-ietf-oauth-jwt-bearer-03.txt   draft-ietf-oauth-jwt-bearer-04.txt 
OAuth Working Group M. Jones OAuth Working Group M. Jones
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track B. Campbell Intended status: Standards Track B. Campbell
Expires: May 10, 2013 Ping Identity Expires: June 30, 2013 Ping Identity
C. Mortimore C. Mortimore
Salesforce Salesforce
November 6, 2012 December 27, 2012
JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
draft-ietf-oauth-jwt-bearer-03 draft-ietf-oauth-jwt-bearer-04
Abstract Abstract
This specification defines the use of a JSON Web Token (JWT) Bearer This specification defines the use of a JSON Web Token (JWT) Bearer
Token as a means for requesting an OAuth 2.0 access token as well as Token as a means for requesting an OAuth 2.0 access token as well as
for use as a means of client authentication. for use as a means of client authentication.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 May 10, 2013. This Internet-Draft will expire on June 30, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 6, line 8 skipping to change at page 6, line 8
In order to issue an access token response as described in The OAuth In order to issue an access token response as described in The OAuth
2.0 Authorization Framework [RFC6749] or to rely on a JWT for client 2.0 Authorization Framework [RFC6749] or to rely on a JWT for client
authentication, the authorization server MUST validate the JWT authentication, the authorization server MUST validate the JWT
according to the criteria below. Application of additional according to the criteria below. Application of additional
restrictions and policy are at the discretion of the authorization restrictions and policy are at the discretion of the authorization
server. server.
o The JWT MUST contain an "iss" (issuer) claim that contains a o The JWT MUST contain an "iss" (issuer) claim that contains a
unique identifier for the entity that issued the JWT. unique identifier for the entity that issued the JWT.
o The JWT MUST contain a "prn" (principal) claim identifying the o The JWT MUST contain a "sub" (subject) claim identifying the
subject of the transaction. The principal MAY identify the subject of the transaction. The subject MAY identify the resource
resource owner for whom the access token is being requested. For owner for whom the access token is being requested. For client
client authentication, the principal MUST be the "client_id" of authentication, the subject MUST be the "client_id" of the OAuth
the OAuth client. When using a JWT as an authorization grant, the client. When using a JWT as an authorization grant, the subject
principal SHOULD identify an authorized accessor for whom the SHOULD identify an authorized accessor for whom the access token
access token is being requested (typically the resource owner, or is being requested (typically the resource owner, or an authorized
an authorized delegate). delegate).
o The JWT MUST contain an "aud" (audience) claim containing a URI o The JWT MUST contain an "aud" (audience) claim containing an
reference that identifies the authorization server, or the service audience value that identifies the authorization server, or the
provider principal entity of its controlling domain, as an service provider principal entity of its controlling domain, as an
intended audience. The token endpoint URL of the authorization intended audience. The token endpoint URL of the authorization
server MAY be used as an acceptable value for an "aud" element. server MAY be used as an acceptable value for an "aud" element.
The authorization server MUST verify that it is an intended The authorization server MUST verify that it is an intended
audience for the JWT. audience for the JWT.
o The JWT MUST contain an "exp" (expiration) claim that limits the o The JWT MUST contain an "exp" (expiration) claim that limits the
time window during which the JWT can be used. The authorization time window during which the JWT can be used. The authorization
server MUST verify that the expiration time has not passed, server MUST verify that the expiration time has not passed,
subject to allowable clock skew between systems. The subject to allowable clock skew between systems. The
authorization server MAY reject JWTs with an "exp" claim value authorization server MAY reject JWTs with an "exp" claim value
skipping to change at page 8, line 9 skipping to change at page 8, line 9
4. Authorization Grant Example 4. Authorization Grant Example
Though non-normative, the following examples illustrate what a Though non-normative, the following examples illustrate what a
conforming JWT and access token request would look like. conforming JWT and access token request would look like.
Below is an example JSON object that could be encoded to produce the Below is an example JSON object that could be encoded to produce the
JWT Claims Object for a JWT: JWT Claims Object for a JWT:
{"iss":"https://jwt-idp.example.com", {"iss":"https://jwt-idp.example.com",
"prn":"mailto:mike@example.com", "sub":"mailto:mike@example.com",
"aud":"https://jwt-rp.example.net", "aud":"https://jwt-rp.example.net",
"nbf":1300815780, "nbf":1300815780,
"exp":1300819380, "exp":1300819380,
"http://claims.example.com/member":true} "http://claims.example.com/member":true}
The following example JSON object, used as the header of a JWT, The following example JSON object, used as the header of a JWT,
declares that the JWT is signed with the ECDSA P-256 SHA-256 declares that the JWT is signed with the ECDSA P-256 SHA-256
algorithm. algorithm.
{"alg":"ES256"} {"alg":"ES256"}
skipping to change at page 9, line 37 skipping to change at page 9, line 37
o Specification Document: [[this document]] o Specification Document: [[this document]]
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-oauth-assertions] [I-D.ietf-oauth-assertions]
Campbell, B., Mortimore, C., Jones, M., and Y. Goland, Campbell, B., Mortimore, C., Jones, M., and Y. Goland,
"Assertion Framework for OAuth 2.0", "Assertion Framework for OAuth 2.0",
draft-ietf-oauth-assertions-06 (work in progress), draft-ietf-oauth-assertions-08 (work in progress),
September 2012. November 2012.
[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", November 2012. (JWT)", draft-ietf-oauth-json-web-token (work in
progress), December 2012.
[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.
[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.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework",
RFC 6749, October 2012. RFC 6749, October 2012.
[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.
7.2. Informative References 7.2. Informative References
[I-D.ietf-oauth-saml2-bearer] [I-D.ietf-oauth-saml2-bearer]
Campbell, B. and C. Mortimore, "SAML 2.0 Bearer Assertion Campbell, B. and C. Mortimore, "SAML 2.0 Bearer Assertion
Profiles for OAuth 2.0", draft-ietf-oauth-saml2-bearer-14 Profiles for OAuth 2.0", draft-ietf-oauth-saml2-bearer-15
(work in progress), September 2012. (work in progress), November 2012.
Appendix A. Acknowledgements Appendix A. Acknowledgements
This profile was derived from SAML 2.0 Bearer Assertion Profiles for This profile was derived from SAML 2.0 Bearer Assertion Profiles for
OAuth 2.0 [I-D.ietf-oauth-saml2-bearer] by Brian Campbell and Chuck OAuth 2.0 [I-D.ietf-oauth-saml2-bearer] by Brian Campbell and Chuck
Mortimore. Mortimore.
Appendix B. Document History Appendix B. 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 ]]
-04
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
intuitive name.
o Added seriesInfo information to Internet Draft references.
-03 -03
o Reference RFC 6749 and RFC 6755. o Reference RFC 6749 and RFC 6755.
-02 -02
o Add more text to intro explaining that an assertion/JWT grant type o Add more text to intro explaining that an assertion/JWT grant type
can be used with or without client authentication/identification can be used with or without client authentication/identification
and that client assertion/JWT authentication is nothing more than and that client assertion/JWT authentication is nothing more than
an alternative way for a client to authenticate to the token an alternative way for a client to authenticate to the token
 End of changes. 11 change blocks. 
21 lines changed or deleted 30 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/