One document matched: draft-zhou-oauth-owner-auth-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-zhou-oauth-owner-auth-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="draft-zhou-oauth-owner-auth-00">Owner Authorization Grant
Type Profile for OAuth 2.0</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Sujing Zhou" initials="S.Z." surname="Zhou">
<organization>ZTE Corporation</organization>
<address>
<postal>
<street>No.68 Zijinghua Rd. Yuhuatai District</street>
<!-- Reorder these if your country does things differently -->
<city>Nanjing</city>
<region>Jiang Su</region>
<code>210012</code>
<country>R.R.China</country>
</postal>
<email>zhou.sujing@zte.com.cn</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date day="11" month="September" year="2012"/>
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Security Area</area>
<workgroup>OAuth</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document proposes to let resource owners directly authorize a
relying party to access resources stored in other resource servers.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The OAuth 2.0 authorization framework <xref
target="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. </t>
<t>There are four basic grant types defined in <xref
target="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.</t>
<t>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.</t>
<t/>
<t/>
<t/>
<section title="Terminology ">
<t>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 <xref
target="RFC2119"/>.</t>
</section>
</section>
<!-- -->
<section title="Owner_authorization Grant ">
<t>The owner_authorization grant type can be used to obtain both access
tokens and refresh tokens for confidential clients.</t>
<t/>
<t/>
<figure>
<artwork><![CDATA[ +----------+
| 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)
]]></artwork>
<postamble>Figure 1</postamble>
</figure>
<t/>
<t>The flow illustrated in Figure 1 includes the following steps:</t>
<t>(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).</t>
<t>(A2) The user-agent is redirected to Authorization Server.</t>
<t>(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.</t>
<t>(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.</t>
<t>(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.</t>
<t>(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.</t>
</section>
<section title=" Owner_authorization_code and Owner_authorization_type">
<t>Parameters owner_authorization_type and owner_authorization_code are
used to define variable implementations of owner_authorization
grant.</t>
<t>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.</t>
<t>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.</t>
<t>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. </t>
<t>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. </t>
</section>
<section anchor="IANA" title="IANA Considerations">
<section title="Sub-Namespace Registration of urn:ietf:params:oauth:grant-type:owner_authorization">
<t>This is a request to IANA to register the value
"grant-type:owner_authorization" in the registry urn:ietf:params:oauth
established in <xref target="I-D.ietf-oauth-urn-sub-ns"/></t>
<t>o URN: urn:ietf:params:oauth:grant- type:owner_authorization</t>
<t>o Common Name: Owner Authorization Grant Type Profile for OAuth
2.0</t>
<t>o Change controller: IETF</t>
<t>o Specification Document: this document</t>
</section>
<section title="owner_authorization_code Parameter Registration">
<t>The following is the parameter registration request for the
"owner_authorization_code" parameter according to <xref
target="I-D.ietf-oauth-v2"/></t>
<t>o Parameter name: owner_authorization_code</t>
<t>o Parameter usage location: token request</t>
<t>o Change controller: IETF</t>
<t>o Specification document(s): [[this document]]</t>
</section>
<section title="owner_authorization_type Parameter Registration">
<t>The following is the parameter registration request for the
"owner_authorization_type" parameter according to <xref
target="I-D.ietf-oauth-v2"/>,</t>
<t>o Parameter name: owner_authorization_type</t>
<t>o Parameter usage location: token request</t>
<t>o Change controller: IETF</t>
<t>o Specification document(s): [[this document]]</t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>TBD.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<?rfc include='reference.RFC.2119.xml'?>
<?rfc include='reference.RFC.4851.xml'?>
<?rfc include='reference.RFC.5281.xml'?>
<?rfc include='reference.I-D.ietf-oauth-urn-sub-ns.xml'?>
<?rfc include='reference.I-D.ietf-oauth-v2.xml'?>
</references>
<!-- -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:11:06 |