INTERNET-DRAFT Nat Sakimura Intended Status: Proposed Standard Nomura Research Institute Expires: May 8, 2014 November 4, 2013 OAuth 2.0 Registered JWT Profile 1.0 draft-sakimura-oauth-rjwtprof-00 Abstract This specification defines a profile of OAuth 2.0 framework that provides the holder of key facility for the compliant client. It achieves this without channel binding but solely based on the application protocol to make it easy for the client developers to develop such client. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2013 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 Nat Sakimura Expires May 8, 2014 [Page 1] INTERNET DRAFT OAuth 2.0 Registered JWT Profile 1.0 November 4, 2013 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Notational Conventions . . . . . . . . . . . . . . . . . . 3 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Registered JWT . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use of Registered JWT . . . . . . . . . . . . . . . . . . . . 4 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 5 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1 Normative References . . . . . . . . . . . . . . . . . . . 5 5.2 Informative References . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 Nat Sakimura Expires May 8, 2014 [Page 2] INTERNET DRAFT OAuth 2.0 Registered JWT Profile 1.0 November 4, 2013 1 Introduction OAuth 2.0 Bearer Token Usage follows the "Bearer Instrument" pattern that the token is not registered to any party, thus the token can be used by any party that act as a bearer. The flexibility provided by this pattern is very flexible. However, when it has its weakness in the cases of token loss. This draft addresses the issue with another very popular pattern in the area of financial instruments called "registered instruments". In this case, the token is registered to a user, thus it will not be usable by any other party than the registered user whose identity can be verified through evidence of identity. To achieve the same effect as the "registered instruments", this draft uses JWT as the token type and defines two additional claims to make it possible to obtain the identifier of the rightful registered owner of the token. In addition, this draft defines a method to verify that the exerciser of the token is the registered owner of the token. 1.1 Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.2 Terminology entity something that has separate and distinct existence and that can be identified in a context [ITU-T X.1252] Registered JWT JWT that is registered to an entity Note: There are two main ways to achieve this. One is to have the identifier of the owner in the token itself, while the other is to provide an interface that returns the identifier of the owner when asked. 2. Registered JWT To achieve Registered JWT, this document defines the two new claims for JWT. Nat Sakimura Expires May 8, 2014 [Page 3] INTERNET DRAFT OAuth 2.0 Registered JWT Profile 1.0 November 4, 2013 azp String. Required if azu is not available. The identifier of the entity that this JWT is registered to. This is primarily used in the case that the registered owner (the authorized party) of the JWT will not change. Note: This is very similar to 'azp' in OpenID Connect. azu String. Required if azp is not available. A URL from which the value of azp can be found. This is used in the case where the registered owner of the JWT will change over time. Following is a non-normative example of the JWT payload with the above claims. { "iss":"https://oauth.example.com/", "azp":"https://client.example.net/", "aud":"https://resource.example.org/", "sub":"sakimura@example.com#1234", "exp":"2013-03-31T00:00:00Z" } 3. Use of Registered JWT If a server receives a request for a protected resource, and an acceptable Authorization header is not sent, the server responds with a "401 Unauthorized" status code, and a WWW-Authenticate header as follows: Nat Sakimura Expires May 8, 2014 [Page 4] INTERNET DRAFT OAuth 2.0 Registered JWT Profile 1.0 November 4, 2013 3 Security Considerations 4 IANA Considerations 5 References 5.1 Normative References 5.2 Informative References Authors' Addresses Nat Sakimura Nomura Research Institute EMail: sakimura@gmail.com Nat Sakimura Expires May 8, 2014 [Page 5]