Owner Authorization Grant Type Profile for OAuth 2.0
draft-zhou-oauth-owner-auth-00

Abstract

This document proposes to let resource owners directly authorize a relying party to access resources stored in other resource servers.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

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 March 13, 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 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
• 1.1. Terminology
• 2. Owner_authorization Grant
• 3. Owner_authorization_code and Owner_authorization_type
• 4. IANA Considerations
• 4.1. Sub-Namespace Registration of urn:ietf:params:oauth:grant-type:owner_authorization
• 4.2. owner_authorization_code Parameter Registration
• 4.3. owner_authorization_type Parameter Registration
• 5. Security Considerations
• 6. References
• Author's Address

1. Introduction

The OAuth 2.0 authorization framework [I-D.ietf-oauth-v2] enables a client (a third-party application ) to obtain limited access to an HTTP service, where resources controlled by the resource owners are hosted, in a way resource owners don't have to leak their credentials with the resource servers to clients, instead clients are granted time limited access tokens from interacting with resource owners and an authorization server.

There are four basic grant types defined in [I-D.ietf-oauth-v2]: "authorization_code","password","client_credentials","refresh_token". The grant type of authorization_code enables a client to get an authorization code from the authorization server, and trades in an access token from the authorization server later by presenting the authorization code. For the grant type of password, a client uses resource owner's password credential as an authorization code to get an access token from the authorization server. It is used when clients are trusted by resource owners so that resource owners can leak their password credentials to them. For the grant type of client_credentials, a client uses the credential of itself as an authorization code to get an access token from the authorization server. It is used when clients have control of the resources or resource owners have authorized the authorization servers. The grant type of refresh_token is used when clients want to have a new access token by presenting a refresh token as an authorization code.

The grant type of authorization_code is representative of all the OAuth's grant types. But it requires multiple interactive exchanges between resource owners and authorization servers before issuing authorization codes. Sometime this interactive procedure may not be necessary. And it is more natural to let a resource owner rather than an authorization server to issue authorization codes, after all the access to the resources should be determined by the resource owners ultimately and entirely. In this document, we define a grant type "owner_authorization" that allows resourse owners to authorize clients directly, and parameters "owner_authorization_code", "owner_authorization_type" that allow for detailed definition and expansion of the grant type of owner_authorization.

1.1. Terminology

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 [RFC2119].

2. Owner_authorization Grant

The owner_authorization grant type can be used to obtain both access tokens and refresh tokens for confidential clients.

   +----------+
   | resource |
   |   owner  |
   +----------+
         ^
         |
        (B)
         |
         v
    +----------+                                 +---------------+
    |         -+----(A2)- Client Identifier ---->|               |
    |  User-   |   &redirection URI              | Authorization |
    |  Agent   +<---(B)-- Script----------------<|     Server    |
    +-|----|---+                                 +---------------+
      |    |                                         ^      v
    (A1)  (C) Delegation code                        |      |
      |    |                                         |      |
      ^    v                                         |      |
    +---------+                                      |      |
    |         |>--(D)--(Derivative) Delegation Code--'      |
    |  Client |          & Redirection URI                  |
    |         |                                             |
    |         |<---(E)----- Access Token -------------------'
    +---------+       (w/ Optional Refresh Token)

Figure 1

The flow illustrated in Figure 1 includes the following steps:

(A1) The client initiates the flow by directing the resource owner's user-agent to the authorization endpoint. The client includes its client identifier, requested scope, local state, and a redirection URI to which the resource owner will send the delegation code back once access is granted (or denied).

(A2) The user-agent is redirected to Authorization Server.

(B) The redirection from user-agent leads it to download script from AS, some information in the redirection will be extracted into the script and user is prompted to input password or private key.

(C) The resource owner fills in required items through Script and generates a delegation code,sends the delegation code to client (redirection URI) through user-agent.

(D) The client requests an access token from the authorization server's token endpoint by including the delegation code received in the previous step, or a derivative delegation code calculated from delegation code. When making the request, the client authenticates with the authorization server.

(E) The authorization server authenticates the client, validates the (derivative) delegation code. If valid, the authorization server responds back with an access token and optional refresh token.

3. Owner_authorization_code and Owner_authorization_type

Parameters owner_authorization_type and owner_authorization_code are used to define variable implementations of owner_authorization grant.

For example, an owner_authorization_type="signature" could be defined, and the owner_authorization_code can include (client identity, resource owner identity, resource identity, authorization time period, signature), where signature is a digital signature computed on all the other information concatenated together using the private key of the resource owners. Authorization server verifies the signature, if valid, generates an access token and sends to the client.

An owner_authorization_type="proxy_signature" could be defined, and the owner_authorization_code can include (client identity, resource owner identity, resource identity, authorization time period, psig), where psig is a proxy signature computed on all the other information concatenated together and the proxy private key assigned to clients by resource owners . Authorization server verifies the proxy signature, if valid, generates an access token and sends to the client.

An owner_authorization_type="mac1" could be defined, and the owner_authorization_code can include (client identity, resource owner identity, resource identity, authorization time period, random token, mac1), where mac1 is a message authentication code computed on all the other information concatenated together and the secret key shared between resource owner and authorization server. Authorization server recalculates the message authentication code, if the result equals mac1, generates an access token and sends to the client.

An owner_authorization_type="mac2" could be defined, and the owner_authorization_code can include (client identity, resource owner identity, resource identity, authorization time period, com, mac2, PoK), where mac2 is a message authentication code computed on all the other information concatenated together and the secret key shared between resource owner and authorization server, and com is the result of comitment(random token, client secret key) where client secret key is the secret between clients and AS, PoK is a proof of knowledge of client secret key in com. Authorization server recalculates the message authentication code, if the result equals mac2, then continue to verify PoK , if valid, generates an access token and sends to the client.

4. IANA Considerations

4.1. Sub-Namespace Registration of urn:ietf:params:oauth:grant-type:owner_authorization

This is a request to IANA to register the value "grant-type:owner_authorization" in the registry urn:ietf:params:oauth established in [I-D.ietf-oauth-urn-sub-ns]

o URN: urn:ietf:params:oauth:grant- type:owner_authorization

o Common Name: Owner Authorization Grant Type Profile for OAuth 2.0

o Change controller: IETF

o Specification Document: this document

4.2. owner_authorization_code Parameter Registration

The following is the parameter registration request for the "owner_authorization_code" parameter according to [I-D.ietf-oauth-v2]

o Parameter name: owner_authorization_code

o Parameter usage location: token request

o Change controller: IETF

o Specification document(s): [[this document]]

4.3. owner_authorization_type Parameter Registration

The following is the parameter registration request for the "owner_authorization_type" parameter according to [I-D.ietf-oauth-v2],

o Parameter name: owner_authorization_type

o Parameter usage location: token request

o Change controller: IETF

o Specification document(s): [[this document]]

5. Security Considerations

TBD.

6. References

Author's Address