OAuth 2.0 Registered JWT Profile 1.0
draft-sakimura-oauth-rjwtprof-00

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

   <Security considerations text>

4  IANA Considerations

   <IANA considerations text>

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]