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

INTERNET-DRAFT                                              Nat Sakimura
Intended Status: Proposed Standard             Nomura Research Institute
Expires: May 10, 2014                                   November 6, 2013

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

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 10, 2014                  [Page 1]
INTERNET DRAFT    OAuth 2.0 Registered JWT Profile 1.0  November 6, 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. Obtaining the Registered JWT  . . . . . . . . . . . . . . . . .  4
   4.  Use of Registered JWT  . . . . . . . . . . . . . . . . . . . .  5
     4.1 Use of Registered JWT as a grant . . . . . . . . . . . . . .  5
       4.1.1 Token request  . . . . . . . . . . . . . . . . . . . . .  6
       4.1.2 Token response . . . . . . . . . . . . . . . . . . . . .  6
       4.1.3 Token error response . . . . . . . . . . . . . . . . . .  6
     4.2 Use of Registered JWT as an access token . . . . . . . . . .  6
       4.2.1 Resource request . . . . . . . . . . . . . . . . . . . .  6
       4.2.2 Resource request verification  . . . . . . . . . . . . .  7
       4.2.3 Positive Response  . . . . . . . . . . . . . . . . . . .  7
       4.2.4 Error Response . . . . . . . . . . . . . . . . . . . . .  7
   3  Security Considerations . . . . . . . . . . . . . . . . . . . .  8
   4  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  8
   5  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.1  Normative References  . . . . . . . . . . . . . . . . . . .  8
     5.2  Informative References  . . . . . . . . . . . . . . . . . .  8
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  8

 

Nat Sakimura              Expires May 10, 2014                  [Page 2]
INTERNET DRAFT    OAuth 2.0 Registered JWT Profile 1.0  November 6, 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