--- 1/draft-ietf-oauth-jwt-bearer-03.txt 2012-12-28 11:27:51.216207608 +0100 +++ 2/draft-ietf-oauth-jwt-bearer-04.txt 2012-12-28 11:27:51.236238576 +0100 @@ -1,21 +1,21 @@ OAuth Working Group M. Jones Internet-Draft Microsoft Intended status: Standards Track B. Campbell -Expires: May 10, 2013 Ping Identity +Expires: June 30, 2013 Ping Identity C. Mortimore Salesforce - November 6, 2012 + December 27, 2012 JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 - draft-ietf-oauth-jwt-bearer-03 + draft-ietf-oauth-jwt-bearer-04 Abstract 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 for use as a means of client authentication. Status of this Memo This Internet-Draft is submitted in full conformance with the @@ -24,21 +24,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -212,32 +212,32 @@ 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 authentication, the authorization server MUST validate the JWT according to the criteria below. Application of additional restrictions and policy are at the discretion of the authorization server. o The JWT MUST contain an "iss" (issuer) claim that contains a unique identifier for the entity that issued the JWT. - o The JWT MUST contain a "prn" (principal) claim identifying the - subject of the transaction. The principal MAY identify the - resource owner for whom the access token is being requested. For - client authentication, the principal MUST be the "client_id" of - the OAuth client. When using a JWT as an authorization grant, the - principal SHOULD identify an authorized accessor for whom the - access token is being requested (typically the resource owner, or - an authorized delegate). + o The JWT MUST contain a "sub" (subject) claim identifying the + subject of the transaction. The subject MAY identify the resource + owner for whom the access token is being requested. For client + authentication, the subject MUST be the "client_id" of the OAuth + client. When using a JWT as an authorization grant, the subject + SHOULD identify an authorized accessor for whom the access token + is being requested (typically the resource owner, or an authorized + delegate). - o The JWT MUST contain an "aud" (audience) claim containing a URI - reference that identifies the authorization server, or the service - provider principal entity of its controlling domain, as an + o The JWT MUST contain an "aud" (audience) claim containing an + audience value that identifies the authorization server, or the + service provider principal entity of its controlling domain, as an intended audience. The token endpoint URL of the authorization server MAY be used as an acceptable value for an "aud" element. The authorization server MUST verify that it is an intended audience for the JWT. o The JWT MUST contain an "exp" (expiration) claim that limits the time window during which the JWT can be used. The authorization server MUST verify that the expiration time has not passed, subject to allowable clock skew between systems. The authorization server MAY reject JWTs with an "exp" claim value @@ -302,21 +302,21 @@ 4. Authorization Grant Example Though non-normative, the following examples illustrate what a conforming JWT and access token request would look like. Below is an example JSON object that could be encoded to produce the JWT Claims Object for a JWT: {"iss":"https://jwt-idp.example.com", - "prn":"mailto:mike@example.com", + "sub":"mailto:mike@example.com", "aud":"https://jwt-rp.example.net", "nbf":1300815780, "exp":1300819380, "http://claims.example.com/member":true} 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 algorithm. {"alg":"ES256"} @@ -376,55 +376,64 @@ o Specification Document: [[this document]] 7. References 7.1. Normative References [I-D.ietf-oauth-assertions] Campbell, B., Mortimore, C., Jones, M., and Y. Goland, "Assertion Framework for OAuth 2.0", - draft-ietf-oauth-assertions-06 (work in progress), - September 2012. + draft-ietf-oauth-assertions-08 (work in progress), + November 2012. [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 Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006. [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012. [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace for OAuth", RFC 6755, October 2012. 7.2. Informative References [I-D.ietf-oauth-saml2-bearer] Campbell, B. and C. Mortimore, "SAML 2.0 Bearer Assertion - Profiles for OAuth 2.0", draft-ietf-oauth-saml2-bearer-14 - (work in progress), September 2012. + Profiles for OAuth 2.0", draft-ietf-oauth-saml2-bearer-15 + (work in progress), November 2012. Appendix A. Acknowledgements 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 Mortimore. Appendix B. Document History [[ 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 o Reference RFC 6749 and RFC 6755. -02 o Add more text to intro explaining that an assertion/JWT grant type can be used with or without client authentication/identification and that client assertion/JWT authentication is nothing more than an alternative way for a client to authenticate to the token