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]