diff options
| author | Andrew Arnott <andrewarnott@gmail.com> | 2010-02-08 20:25:47 -0800 |
|---|---|---|
| committer | Andrew Arnott <andrewarnott@gmail.com> | 2010-02-08 20:25:47 -0800 |
| commit | 5e1a57ba973e31fa11875fc07fb317b5e2c582b7 (patch) | |
| tree | d0aeb790b995e6a5768709b20b68edb151958785 /doc/specs | |
| parent | 7940d41066092f3763307a1d143e56416d3e9496 (diff) | |
| download | DotNetOpenAuth-5e1a57ba973e31fa11875fc07fb317b5e2c582b7.zip DotNetOpenAuth-5e1a57ba973e31fa11875fc07fb317b5e2c582b7.tar.gz DotNetOpenAuth-5e1a57ba973e31fa11875fc07fb317b5e2c582b7.tar.bz2 | |
Upgraded spec version.
Diffstat (limited to 'doc/specs')
| -rw-r--r-- | doc/specs/OAuthWRAP-v0.9.7.2.pdf | bin | 312947 -> 0 bytes | |||
| -rw-r--r-- | doc/specs/draft-hardt-oauth-01.htm | 2313 |
2 files changed, 2313 insertions, 0 deletions
diff --git a/doc/specs/OAuthWRAP-v0.9.7.2.pdf b/doc/specs/OAuthWRAP-v0.9.7.2.pdf Binary files differdeleted file mode 100644 index 084fd8a..0000000 --- a/doc/specs/OAuthWRAP-v0.9.7.2.pdf +++ /dev/null diff --git a/doc/specs/draft-hardt-oauth-01.htm b/doc/specs/draft-hardt-oauth-01.htm new file mode 100644 index 0000000..e13cdf0 --- /dev/null +++ b/doc/specs/draft-hardt-oauth-01.htm @@ -0,0 +1,2313 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> +<!-- saved from url=(0137)https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor34 --> +<HTML><HEAD><META http-equiv="Content-Type" content="text/html; charset=UTF-8"></HEAD><BODY> + + + + + + + +<DIV> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<TABLE summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><TBODY><TR><TD><TABLE summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1"> +<TBODY><TR><TD>Internet Engineering Task Force</TD><TD>D. Hardt, Ed.</TD></TR> +<TR><TD>Internet-Draft</TD><TD>Microsoft</TD></TR> +<TR><TD>Intended status: Informational</TD><TD>A. Tom</TD></TR> +<TR><TD>Expires: July 19, 2010</TD><TD>Yahoo!</TD></TR> +<TR><TD> </TD><TD>B. Eaton</TD></TR> +<TR><TD> </TD><TD>Google</TD></TR> +<TR><TD> </TD><TD>Y. Goland</TD></TR> +<TR><TD> </TD><TD>Microsoft</TD></TR> +<TR><TD> </TD><TD>January 15, 2010</TD></TR> +</TBODY></TABLE></TD></TR></TBODY></TABLE> +<H1><BR>OAuth Web Resource Authorization + Profiles<BR>draft-hardt-oauth-01</H1> + +<H3>Abstract</H3> + +<P>The OAuth Web Resource Authorization Profiles (OAuth WRAP) allow a + server hosting a Protected Resource to delegate authorization to one or + more authorities. An application (Client) accesses the Protected + Resource by presenting a short lived, opaque, bearer token (Access + Token) obtained from an authority (Authorization Server). There are + Profiles for how a Client may obtain an Access Token when acting + autonomously or on behalf of a User. +</P> +<H3>Status of this Memo</H3> +<P> +This Internet-Draft is submitted to IETF in full +conformance with the provisions of BCP 78 and BCP 79.</P> +<P> +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.</P> +<P> +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.”</P> +<P> +The list of current Internet-Drafts can be accessed at +<A href="http://www.ietf.org/ietf/1id-abstracts.txt" target="_blank">http://www.ietf.org/ietf/1id-<WBR>abstracts.txt</A>.</P> +<P> +The list of Internet-Draft Shadow Directories can be accessed at +<A href="http://www.ietf.org/shadow.html" target="_blank">http://www.ietf.org/shadow.<WBR>html</A>.</P> +<P> +This Internet-Draft will expire on July 19, 2010.</P> + +<H3>Copyright Notice</H3> +<P> +Copyright (c) 2010 IETF Trust and the persons identified as the +document authors. All rights reserved.</P> +<P> +This document is subject to BCP 78 and the IETF Trust's Legal +Provisions Relating to IETF Documents in effect on the date of +publication of this document (<A href="http://trustee.ietf.org/license-info" target="_blank">http://trustee.ietf.org/<WBR>license-info</A>). +Please review these documents carefully, as they describe your +rights and restrictions with respect to this document.</P> +<A name="0.2_toc"></A><BR><HR> +<H3>Table of Contents</H3> +<P> +<A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor1">1.</A> +Overview<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor2">1.1.</A> +Accessing a Protected Resource<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor3">1.2.</A> +Autonomous Client Profiles<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor4">1.3.</A> +User Delegation Profiles<BR> +<A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor5">2.</A> +Requirements Language<BR> +<A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor6">3.</A> +Definitions<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor7">3.1.</A> +URLs<BR> +<A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_ProtectedResource">4.</A> +Accessing a Protected Resource<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor8">4.1.</A> +Access Token<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor9">4.2.</A> +Acquiring an Access Token<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor10">4.3.</A> +Client Calls Protected Resource Using HTTP Header<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor11">4.4.</A> +Client Calls Protected Resource Using URL Query Parameter<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor12">4.5.</A> +Client Calls Protected Resource Using Post Parameter<BR> +<A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_autonomous.profiles">5.</A> +Acquiring an Access Token: Autonomous Client Profiles<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p1">5.1.</A> +Client Account and Password Profile<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor13">5.1.1.</A> +Provisioning<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p1request">5.1.2.</A> +Client Requests Access Token<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor14">5.1.3.</A> +Successful Access Token Response from Authorization Server<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor15">5.1.4.</A> +Unsuccessful Access Token Response from Authorization Server<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor16">5.1.5.</A> +Client Refreshes Access Token<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p2">5.2.</A> +Assertion Profile<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor17">5.2.1.</A> +Provisioning<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p2.assertion">5.2.2.</A> +Client Obtains Assertion<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p2.request">5.2.3.</A> +Client Requests Access Token<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor18">5.2.4.</A> +Successful Access Token Response from Authorization Server<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor19">5.2.5.</A> +Unsuccessful Access Token Response from Authorization Server<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor20">5.2.6.</A> +Client Refreshes Access Token<BR> +<A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_user.profiles">6.</A> +Acquiring an Access Token: User Delegation Profiles<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p3">6.1.</A> +Username and Password Profile<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor21">6.1.1.</A> +Provisioning<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p3.password">6.1.2.</A> +Client Obtains Username and Password<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p3.request">6.1.3.</A> +Client Requests Access Token<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor22">6.1.4.</A> +Successful Access Token Response from Authorization Server<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor23">6.1.5.</A> +Unsuccessful Access Token Response from Authorization Server<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor24">6.1.6.</A> +Verification URL Response from Authorization Server<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor25">6.1.7.</A> +CAPTCHA Response from Authorization Server<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor26">6.1.8.</A> +Client Refreshes Access Token<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor27">6.1.9.</A> +Successful Access Token Refresh<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor28">6.1.10.</A> +Unsuccessful Access Token Refresh<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p4">6.2.</A> +Web App Profile<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor29">6.2.1.</A> +Provisioning<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p4.authorization">6.2.2.</A> +Client Directs the User to the Authorization Server<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor30">6.2.3.</A> +Authorization Server Confirms Authorization Request with User<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor31">6.2.4.</A> +Authorization Server Directs User back to the Client<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p4.request">6.2.5.</A> +Client Requests Access Token<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor32">6.2.6.</A> +Successful Access Token Response from Authorization Server<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor33">6.2.7.</A> +Unsuccessful Access Token Response from Authorization Server<BR> + <A href="./draft-hardt-oauth-01_files/draft-hardt-oauth-01.htm">6.2.8.</A> +Client Refreshes Access Token<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor35">6.2.9.</A> +Successful Access Token Refresh<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor36">6.2.10.</A> +Unsuccessful Access Token Refresh<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p5">6.3.</A> +Rich App Profile<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor37">6.3.1.</A> +Provisioning<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p5.authorization">6.3.2.</A> +Client Directs the User to the Authorization Server<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor38">6.3.3.</A> +Authorization Server Confirms Authorization Request with User<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p5.request">6.3.4.</A> +Client Requests Access Token<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p5.verification">6.3.5.</A> +Successful Access Token Response from Authorization Server<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor41">6.3.6.</A> +Unsuccessful Access Token Response from Authorization Server<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor42">6.3.7.</A> +Client Refreshes Access Token<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor43">6.3.8.</A> +Successful Access Token Refresh<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor44">6.3.9.</A> +Unsuccessful Access Token Refresh<BR> +<A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_ParamCon">7.</A> +Parameter Considerations<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor45">7.1.</A> +Authorization Server Request / Response Parameter Encoding<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor46">7.2.</A> +Parameter Size<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor47">7.3.</A> +Access Token Format<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor48">7.4.</A> +Refresh Token Format<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor49">7.5.</A> +Additional Authorization Server Parameters<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor50">7.6.</A> +Parameter Names and Order<BR> +<A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_IANA">8.</A> +IANA Considerations<BR> +<A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_Security">9.</A> +Security Considerations<BR> +<A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_rfc.references1">10.</A> +References<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_rfc.references1">10.1.</A> +Normative References<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_rfc.references2">10.2.</A> +Informative References<BR> +<A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor53">Appendix A.</A> +Client Account and Password Profile Example<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor54">A.1.</A> +Provisioning<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor55">A.2.</A> +Client Requests Access Token<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor56">A.3.</A> +Successful Access Token Response from Authorization Server<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor57">A.4.</A> +Client Calls Protected Resource<BR> +<A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor58">Appendix B.</A> +Web App Profile Example<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor59">B.1.</A> +Provisioning<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor60">B.2.</A> +Client Directs the User to the Server<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor61">B.3.</A> +Authorization Server Confirms Delegation Request with User<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor62">B.4.</A> +Server Directs User back to the Client<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor63">B.5.</A> +Client Requests Access Token<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor64">B.6.</A> +Successful Access Token Response from Authorization Server<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor65">B.7.</A> +Client Calls Protected Resource<BR> + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_anchor66">B.8.</A> +Client Refreshes Access Token<BR> +<A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_rfc.authors">§</A> +Authors' Addresses<BR> +</P> +<BR clear="all"> + +<A name="0.2_anchor1"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.1"></A><H3>1. +Overview</H3> + +<P>As the internet has evolved, there is a growing trend for a variety + of applications (Clients) to access resources through an API over HTTP + or other protocols. Often these resources require authorization for + access and are Protected Resources. The systems that are trusted to make + authorization decisions may be independent from the Protected Resources + for scale and security reasons. The OAuth Web Resource Authorization + Profiles (OAuth WRAP) enable a Protected Resource to delegate the + authorization to access a Protected Resource to one or more trusted + authorities. +</P> +<P>Clients that wish to access a Protected Resource first obtain + authorization from a trusted authority (Authorization Server). Different + credentials and profiles can be used to obtain this authorization, but + once authorized, the Client is provided an Access Token, and possible a + Refresh Token to obtain new Access Tokens. The Authorization Server + typically includes authorization information in the Access Token and + digitally signs the Access Token. Protected Resource can verify that an + Access Token received from a Client was issued by a trusted + Authorization Server and is valid. The Protected Resource can then + examine the contents of the Access Token to determine the authorization + that has been granted to the Client. +</P> +<A name="0.2_anchor2"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.1.1"></A><H3>1.1. +Accessing a Protected Resource</H3> + +<P>The Access Token is opaque to the Client, and can be any format + agreed to between the Authorization Server and the Protected Resource + enabling existing systems to reuse suitable tokens, or use a standard + token format such as a Simple Web Token or JSON Web Token. Since the + Access Token provides the Client authorization to the Protected + Resource for the life of the Access Token, the Authorization Server + should issue Access Tokens that expire within an appropriate time. + When an Access Token expires, the Client requests a new Access Token + from the Authorization Server, which once again computes the Client's + authorization, and issues a new Access Token. <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_fig1">Figure 1</A> below shows the flow between the Client and + Authorization Server (A,B); and then between the Client and Protected + Resource (C,D): +</P><BR><HR> +<A name="0.2_fig1"></A> +<DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> +---+ +---------------+ + | C |--(A)------ credentials --------->| Authorization | + | l |<-(B)------ Access Token ---------| Server | + | i | +---------------+ + | e | + | n | Access Token +-----------+ + | t |--(C)----- in HTTP header ------->| Protected | + | |<-(D)------ API response ---------| Resource | + +---+ +-----------+ +</PRE></DIV><TABLE border="0" cellpadding="0" cellspacing="2" align="center"><TBODY><TR><TD align="center"><FONT face="monaco, MS Sans Serif" size="1"><B> Figure 1 </B></FONT><BR></TD></TR></TBODY></TABLE><HR> + +<P>In step A, the Client presents credentials to the Authorization + Server in exchange for an Access Token. +</P> +<P> A Profile specifies the credentials to be provided in step A, and + how the Client obtains them. This specification defines a number of + Profiles; additional Profiles may be defined to support additional + scenarios. The Profiles in this specification are separated into two + groups: autonomous profiles where the Client as acting for itself, and + user delegation profiles where the Client is acting on behalf of a + User. +</P> +<A name="0.2_anchor3"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.1.2"></A><H3>1.2. +Autonomous Client Profiles</H3> + +<P>The following two Profiles (see <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_autonomous.profiles">Section 5<SPAN> (</SPAN><SPAN>Acquiring an Access Token: Autonomous Client Profiles</SPAN><SPAN>)</SPAN></A>) are recommended for scenarios + involving a Client acting autonomously. +</P> +<P>Client Account and Password Profile (<A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p1">Section 5.1<SPAN> (</SPAN><SPAN>Client Account and Password Profile</SPAN><SPAN>)</SPAN></A>): This + is the simplest Profile. The Client is provisioned with an account name + and corresponding password by the Authorization Server. The Client + presents the account name and password to the Access Token URL at the + Authorization Server in exchange for an Access Token. This Profile is + not intended for a Client acting on behalf of a User. See the User + Delegation Profiles. +</P> +<P>Assertion Profile (<A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p2">Section 5.2<SPAN> (</SPAN><SPAN>Assertion Profile</SPAN><SPAN>)</SPAN></A>): This profile enables a + Client with a <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_OASIS.saml-core-2.0-os">SAML<SPAN> (</SPAN><SPAN>Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.</SPAN><SPAN>)</SPAN></A> [OASIS.saml‑core‑2.0‑os] or other + assertion recognized by the Authorization Server. The Client presents + the assertion to the Access Token URL at the Authorization Server in + exchange for an Access Token. How the Client obtains the assertion is + out of scope of OAuth WRAP. +</P> +<P>Access Tokens are short lived bearer tokens. When the Protected + Resource is presented with an expired Access Token by the Client, the + Protected Resource returns an error. The Client presents the assertion + once again to the Authorization Server to obtain a new Access + Token. +</P> +<A name="0.2_anchor4"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.1.3"></A><H3>1.3. +User Delegation Profiles</H3> + +<P>Common scenarios involve the User delegating to a Client to act on + the User's behalf, adding another party (the User) to the protocol. In + these Profiles (see <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_user.profiles">Section 6<SPAN> (</SPAN><SPAN>Acquiring an Access Token: User Delegation Profiles</SPAN><SPAN>)</SPAN></A>), the Client + receives a Refresh Token when it acquires the first Access Token. When + an Access Token expires, the Client presents the Refresh Token to + acquire a new Access Token. Refresh Tokens are sensitive as they + represent long-lived permissions to access a Protected Resource and + are always transmitted using HTTPS. +</P> +<P>Username and Password Profile (<A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p3">Section 6.1<SPAN> (</SPAN><SPAN>Username and Password Profile</SPAN><SPAN>)</SPAN></A>): While + the User may use a username and password to authenticate to the + Authorization Server, it is undesirable for the Client to store the + User's username and password. In this profile the User provides their + username and password to an application (Client) they have installed + on their device. The Client presents a Client Identifier, the username + and password (credentials) to the Access Token URL at the + Authorization Server in exchange for an Access Token and a Refresh + Token as depicted in <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_fig2">Figure 2</A> below. +</P><BR><HR> +<A name="0.2_fig2"></A> +<DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> +---+ +---------------+ + | C |--(A)------ credentials --------->| Authorization | + | l |<-(B)------ Access Token ---------| Server | + | i | Refresh Token +---------------+ + | e | + | n | Access Token +-----------+ + | t |--(C)----- in HTTP header ------->| Protected | + | |<-(D)------ API response ---------| Resource | + +---+ +-----------+ + +</PRE></DIV><TABLE border="0" cellpadding="0" cellspacing="2" align="center"><TBODY><TR><TD align="center"><FONT face="monaco, MS Sans Serif" size="1"><B> Figure 2 </B></FONT><BR></TD></TR></TBODY></TABLE><HR> + +<P>When the Access Token expires, the Client presents the Refresh + Token to the Refresh Token URL at the Authorization Server in exchange + for a new Access Token (<A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_fig3">Figure 3</A>, steps A and B). + The Client then uses the new Access Token to access the Protected + Resource (<A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_fig3">Figure 3</A>, steps C and D). +</P><BR><HR> +<A name="0.2_fig3"></A> +<DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> +---+ +---------------+ + | C |--(A)----- Refresh Token -------->| Authorization | + | l |<-(B)------ Access Token ---------| Server | + | i | +---------------+ + | e | + | n | Access Token +-----------+ + | t |--(C)----- in HTTP header ------->| Protected | + | |<-(D)------ API response ---------| Resource | + +---+ +-----------+ + +</PRE></DIV><TABLE border="0" cellpadding="0" cellspacing="2" align="center"><TBODY><TR><TD align="center"><FONT face="monaco, MS Sans Serif" size="1"><B> Figure 3 </B></FONT><BR></TD></TR></TBODY></TABLE><HR> + +<P>Web App Profile (<A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p4">Section 6.2<SPAN> (</SPAN><SPAN>Web App Profile</SPAN><SPAN>)</SPAN></A>): It is undesirable for + a User to provide their Authorization Server username and password to + web applications. Additionally, the User may authenticate to the + Authorization Server using other mechanisms than a username and + password. In this profile, a web application (Client) has been + provisioned with a Client Identifier and Client Secret and may have + registered a Callback URL. <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_fig4">Figure 4</A> below + illustrates the protocol. (A) The Client initiates the protocol by + redirecting the User to the User Authorization URL at the + Authorization Server passing the Client Identifier and the Callback + URL. (B) The Authorization Server authenticates the User, confirms the + User would like to authorize the Client to access the Protected + Resource, and generates a Verification Code. (C) The Authorization + Server then redirects the User to the Callback URL at the Client + passing along the Verification Code. +</P><BR><HR> +<A name="0.2_fig4"></A> +<DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> +---------+ + | Web App | + | Client | + +---------+ + v ^ + | | + (A) (C) + | | + \ \ + +---------+ +---------------+ + | |\---(C)-- Verification Code ----<| | + | User | | Authorization | + | at |<---(B)-- User authenticates --->| Server | + | Browser | | | + | |\---(A)-- Client Identifier ---->| | + +---------+ +---------------+ +</PRE></DIV><TABLE border="0" cellpadding="0" cellspacing="2" align="center"><TBODY><TR><TD align="center"><FONT face="monaco, MS Sans Serif" size="1"><B> Figure 4 </B></FONT><BR></TD></TR></TBODY></TABLE><HR> + +<P>Similar to step A in <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_fig2">Figure 2</A>, the Client then + presents the Client Identifier, Client Secret, Callback URL and + Verification code (credentials) to the Access Token URL at the + Authorization Server for an Access Token and a Refresh Token. +</P> +<P>Rich App Profile (<A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p5">Section 6.3<SPAN> (</SPAN><SPAN>Rich App Profile</SPAN><SPAN>)</SPAN></A>): This profile is + suitable when the Client is an application the User has installed on + their device and a web browser is available, but it is undesirable for + the User to provide their username and password to an application, or + the user may not be using a username and password to authenticate to + the Authorization Server. +</P> +<P>The Client initiates the protocol by directing the User's browser + to the Authorization URL at the Authorization Server passing the + Client Identifier and potentially a Callback URL. The Authorization + Server authenticates the User, confirms the User would like to + authorize the Client to access the Protected Resource, and generates a + Verification Code. The Verification Code may be communicated back to + the Client in a number of ways: +</P> +<P></P> +<BLOCKQUOTE><DL> +<DT>a.</DT> +<DD>the Authorization Server presents the Verification Code to the + User, who is instructed to enter the Verification Code directly in + the Client; +</DD> +<DT>b.</DT> +<DD>the Client reads the Verification Code from the title of the + web page presented by the Authorization Server; +</DD> +<DT>c.</DT> +<DD>the Authorization Server redirects the User to the Callback URL + that presents Client specific language for the User to enter the + Verification Code into the Client; or +</DD> +<DT>d.</DT> +<DD>the Client has registered a custom scheme and the Authorization + Server redirects the browser to the custom scheme that causes the + User's browser to load the Client application with the + Verification Code as a parameter. +</DD> +</DL></BLOCKQUOTE> + +<P>Similar to step A in <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_fig2">Figure 2</A>, the Client then + presents the Client Identifier, Callback URL (if provided) and + Verification code (credentials) to the Access Token URL at the + Authorization Server for an Access Token and a Refresh Token. +</P> +<A name="0.2_anchor5"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.2"></A><H3>2. +Requirements Language</H3> + +<P>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 <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_RFC2119">[RFC2119]<SPAN> (</SPAN><SPAN>Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</SPAN><SPAN>)</SPAN></A>. Domain name examples use <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_RFC2606">[RFC2606]<SPAN> (</SPAN><SPAN>Eastlake, D. and A. Panitz, “Reserved Top Level DNS Names,” June 1999.</SPAN><SPAN>)</SPAN></A>. +</P> +<A name="0.2_anchor6"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.3"></A><H3>3. +Definitions</H3> + +<P></P> +<BLOCKQUOTE><DL> +<DT>Access Token:</DT> +<DD>a short lived bearer token issued by the + Authorization Server to the Client. The Access Token is presented by + the Client to the Protected Resource to access protected + resources. +</DD> +<DT>Authorization Server:</DT> +<DD>an authorization resource that + issues Access Tokens to Clients after successful authorization. May + be the same entity as the Protected Resource. +</DD> +<DT>Client:</DT> +<DD>an application that would like access to a + Protected Resource. Client Identifier:"> a value used by a Client + to identify itself to the Authorization Server. This may be a human + readable string or an opaque identifier. +</DD> +<DT>Client Secret:</DT> +<DD>a secret used by a web application + Client to establish ownership of the Client Identifier. +</DD> +<DT>Profile:</DT> +<DD>a mechanism for a Client to obtain an Access + Token from an Authorization Server. +</DD> +<DT>Protected Resource:</DT> +<DD>a protected API that allows access + via OAuth WRAP. May be the same entity as the Authorization Server. + Refresh Token:"> a long lived bearer token used by a Client to + acquire an Access Token from an Authorization Server. +</DD> +<DT>User:</DT> +<DD>an individual who has an account with the + Authorization Server. +</DD> +<DT>Verification Code:</DT> +<DD>a code used by a Client to verify + the User has authorized the Client to have specific access to a + Protected Resource. +</DD> +</DL></BLOCKQUOTE> + +<A name="0.2_anchor7"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.3.1"></A><H3>3.1. +URLs</H3> + +<P></P> +<BLOCKQUOTE><DL> +<DT>Access Token URL:</DT> +<DD>the Authorization Server URL at + which an Access Token is requested by the Client. The URL may + accept a variety of parameters depending on the Profile. A Refresh + Token may also be returned to the Client. This URL MUST be an + HTTPS URL and MUST always be called with POST. +</DD> +<DT>Callback URL:</DT> +<DD>the Client URL where the User will be + redirected after an authorization request to the Authorization + Server. +</DD> +<DT>Refresh Token URL:</DT> +<DD>the Authorization Server URL at + which a Refresh Token is presented in exchange for a new Access + Token is requested. This URL MUST be an HTTPS URL and MUST always + be called with POST. +</DD> +<DT>User Authorization URL:</DT> +<DD>the Authorization Server URL + where the Client redirects the User to make an authorization + request. +</DD> +</DL></BLOCKQUOTE> + +<A name="0.2_ProtectedResource"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.4"></A><H3>4. +Accessing a Protected Resource</H3> + +<P>Clients always present an Access Token to access a Protected + Resource. Use of the Authorization header is RECOMMENDED, since HTTP + implementations are aware that Authorization headers have special + security properties and may require special treatment in caches and + logs. Protected Resources SHOULD take precautions to insure that Access + Tokens are not inadvertently logged or captured. In addition to the + methods presented here, the Protected Resource MAY allow the Client to + present the Access Token using any scheme agreed on by the Client and + Protected Resource. +</P> +<A name="0.2_anchor8"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.4.1"></A><H3>4.1. +Access Token</H3> + +<P>The exact format of the Access Token is opaque to Clients and is + out of scope of this specification. However, Protected Resources MUST + be able to verify that the Access Token was issued by a trusted + Authorization Server and is still valid. Access Tokens SHOULD + periodically expire. The expiry time of Access Tokens is determined as + an appropriate balance between excessive resource utilization if too + short and unauthorized access if too long. +</P> +<A name="0.2_anchor9"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.4.2"></A><H3>4.2. +Acquiring an Access Token</H3> + +<P>An Authorization Server may support one or more protocol profiles + that enable a Client to obtain an Access Token that can be used to + access a Protected Resource. +</P> +<P>Client developers only need to implement the profile(s) that align + with how their application will be deployed and are supported by the + Authorization Server. +</P> +<P>Authorization Server developers only need to implement the + profile(s) that are appropriate for them. +</P> +<P>Protected Resource developers do not implement a profile as the + Client always interacts with the Protected Resource by presenting an + Access Token. +</P> +<P><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_ParamCon">Section 7<SPAN> (</SPAN><SPAN>Parameter Considerations</SPAN><SPAN>)</SPAN></A> has general information about + parameters passed to and from the Authorization Server. +</P> +<P>See <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_autonomous.profiles">Section 5<SPAN> (</SPAN><SPAN>Acquiring an Access Token: Autonomous Client Profiles</SPAN><SPAN>)</SPAN></A> for how the Client + acquires an Access Token when acting autonomously, and <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_user.profiles">Section 6<SPAN> (</SPAN><SPAN>Acquiring an Access Token: User Delegation Profiles</SPAN><SPAN>)</SPAN></A> for how the Client acquires an Access + Token when acting acting on behalf of a User. +</P> +<A name="0.2_anchor10"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.4.3"></A><H3>4.3. +Client Calls Protected Resource Using HTTP Header</H3> + +<P>The Protected Resource SHOULD enable Clients to access the + Protected Resource by including the Access Token in the HTTP + Authorization header using the OAuth WRAP scheme with the following + parameter: +</P> +<P></P> +<BLOCKQUOTE><DL> +<DT>access_token</DT> +<DD> REQUIRED. The value of the + Access Token +</DD> +</DL></BLOCKQUOTE> + +<P>For example, if the Access Token is the string 123456789, the HTTP + header would be: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> Authorization: WRAP access_token="123456789" +</PRE></DIV> +<P>Note that per section 1.2 of <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_RFC2617">[RFC2617]<SPAN> (</SPAN><SPAN>Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.</SPAN><SPAN>)</SPAN></A> that + the following header is also valid: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> Authorization: WRAP access_token = 123456789 +</PRE></DIV> +<P>If the Access Token has expired or is invalid, the Protected + Resource MUST return: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> HTTP 401 Unauthorized +</PRE></DIV> +<P>and the HTTP header: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> WWW-Authenticate: WRAP +</PRE></DIV> +<A name="0.2_anchor11"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.4.4"></A><H3>4.4. +Client Calls Protected Resource Using URL Query Parameter</H3> + +<P>The Protected Resource MAY allow the Client to access protected + resources at the Protected Resource by including the following HTTP + URL query parameter in the URL: +</P> +<P></P> +<BLOCKQUOTE><DL> +<DT>access_token</DT> +<DD> REQUIRED. The value of the + Access Token +</DD> +</DL></BLOCKQUOTE> + +<P>If the Access Token has expired or is invalid, the Protected + Resource MUST return: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> HTTP 401 Unauthorized +</PRE></DIV> +<P>and the HTTP header: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> WWW-Authenticate: WRAP +</PRE></DIV> +<A name="0.2_anchor12"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.4.5"></A><H3>4.5. +Client Calls Protected Resource Using Post Parameter</H3> + +<P>The Protected Resource MAY allow the Client to access protected + resources at the Protected Resource by including the following + parameter in the body of a HTTP post message formatted as + application/x-www-form-<WBR>urlencoded per <A href="http://www.w3.org/TR/1999/REC-W3C.REC-html40-19980424-19991224/interact/forms.html#h-17.13.4.1" target="_blank">17.13.4</A> + of <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_W3C.REC-html40-19980424">HTML 4.01<SPAN> (</SPAN><SPAN>Hors, A., Jacobs, I., and D. Raggett, “HTML 4.0 Specification,” April 1998.</SPAN><SPAN>)</SPAN></A> [W3C.REC‑html40‑19980424]: +</P> +<P></P> +<BLOCKQUOTE><DL> +<DT>access_token</DT> +<DD> REQUIRED. The value of the + Access Token +</DD> +</DL></BLOCKQUOTE> + +<P>If the Access Token has expired or is invalid, the Protected + Resource MUST return: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> HTTP 401 Unauthorized +</PRE></DIV> +<P>and the HTTP header: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> WWW-Authenticate: WRAP +</PRE></DIV> +<A name="0.2_autonomous.profiles"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.5"></A><H3>5. +Acquiring an Access Token: Autonomous Client Profiles</H3> + +<P>These are the profiles the Client uses when acting autonomously. +</P> +<A name="0.2_p1"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.5.1"></A><H3>5.1. +Client Account and Password Profile</H3> + +<P>This profile is suitable when the Client is an application calling + the Protected Resource on behalf of an organization and the + Authorization Server accepts account passwords for authentication. + This enables the Authorization Server to use an existing + authentication mechanism. This profile SHOULD NOT be used when the + Client is acting on behalf of a user. Profiles <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p3">6.1<SPAN> (</SPAN><SPAN>Username and Password Profile</SPAN><SPAN>)</SPAN></A>, <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p4">6.2<SPAN> (</SPAN><SPAN>Web App Profile</SPAN><SPAN>)</SPAN></A> or + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p5">6.3<SPAN> (</SPAN><SPAN>Rich App Profile</SPAN><SPAN>)</SPAN></A> are RECOMMENDED when a + Client is acting on behalf of a User. +</P> +<A name="0.2_anchor13"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.5.1.1"></A><H3>5.1.1. +Provisioning</H3> + +<P>Prior to initiating this protocol profile, the Client MUST have + obtained an account name and account password from the Authorization + Server. +</P> +<A name="0.2_p1request"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.5.1.2"></A><H3>5.1.2. +Client Requests Access Token</H3> + +<P>The Client makes an HTTPS request to the Authorization Server's + Access Token URL using POST. The request contains the following + parameters: +</P> +<P></P> +<BLOCKQUOTE><DL> +<DT>wrap_name</DT> +<DD> REQUIRED. The account + name. +</DD> +<DT>wrap_password</DT> +<DD> REQUIRED. The account + password. +</DD> +<DT>wrap_scope</DT> +<DD> OPTIONAL. The Authorization + Server MAY define authorization scope values for the Client to + include. +</DD> +<DT>Additional parameters</DT> +<DD>Any additional + parameters, as defined by the Authorization Server. +</DD> +</DL></BLOCKQUOTE> + +<A name="0.2_anchor14"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.5.1.3"></A><H3>5.1.3. +Successful Access Token Response from Authorization Server</H3> + +<P>If successful, the Authorization Server returns: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> HTTP 200 OK +</PRE></DIV> +<P>with the Refresh Token and an Access Token in the response body. + The response body contains the following parameters: +</P> +<P></P> +<BLOCKQUOTE><DL> +<DT>wrap_refresh_token</DT> +<DD> REQUIRED. The + Refresh Token. +</DD> +<DT>wrap_access_token</DT> +<DD> REQUIRED. The Access + Token. +</DD> +<DT>wrap_access_token_expires_in</DT> +<DD> OPTIONAL. + The lifetime of the Access Token in seconds. For example, 3600 + represents one hour. +</DD> +<DT>Additional parameters</DT> +<DD> Any additional + parameters, as defined by the Authorization Server. +</DD> +</DL></BLOCKQUOTE> + +<P>The Client may now use the Access Token to access the Protected + Resource per <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_ProtectedResource">Section 4<SPAN> (</SPAN><SPAN>Accessing a Protected Resource</SPAN><SPAN>)</SPAN></A> +</P> +<A name="0.2_anchor15"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.5.1.4"></A><H3>5.1.4. +Unsuccessful Access Token Response from Authorization Server</H3> + +<P>If the Client account name and password are invalid, the + Authorization Server MUST respond with: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> HTTP 401 Unauthorized +</PRE></DIV> +<P>and the HTTP header: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> WWW-Authenticate: WRAP +</PRE></DIV> +<P>The Client MUST obtain a valid account name and password before + retrying the request. +</P> +<A name="0.2_anchor16"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.5.1.5"></A><H3>5.1.5. +Client Refreshes Access Token</H3> + +<P>Authorization Servers SHOULD issue Access Tokens that expire and + require Clients to refresh them. Upon receiving the HTTP 401 + response when accessing protected resources per <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_ProtectedResource">Section 4<SPAN> (</SPAN><SPAN>Accessing a Protected Resource</SPAN><SPAN>)</SPAN></A>, the Client should request a new + Access Token by repeating <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p1request">Section 5.1.2<SPAN> (</SPAN><SPAN>Client Requests Access Token</SPAN><SPAN>)</SPAN></A> +</P> +<A name="0.2_p2"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.5.2"></A><H3>5.2. +Assertion Profile</H3> + +<A name="0.2_anchor17"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.5.2.1"></A><H3>5.2.1. +Provisioning</H3> + +<P>Prior to initiating this protocol profile, the Client MUST have a + mechanism for obtained an assertion from an assertion issuer that + can be presented to the Authorization Server for access to the + Protected Resource. +</P> +<A name="0.2_p2.assertion"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.5.2.2"></A><H3>5.2.2. +Client Obtains Assertion</H3> + +<P>The Client obtains an assertion. The process for obtaining the + assertion is defined by the assertion issuer and the Authorization + Server, and is out of scope of this specification. +</P> +<A name="0.2_p2.request"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.5.2.3"></A><H3>5.2.3. +Client Requests Access Token</H3> + +<P>The Client makes an HTTPS request to the Authorization Server's + Access Token URL using POST. The request contains the following + parameters: +</P> +<P></P> +<BLOCKQUOTE><DL> +<DT>wrap_assertion_format</DT> +<DD> REQUIRED. The + format of the assertion as defined by the Authorization + Server. +</DD> +<DT>wrap_assertion</DT> +<DD> REQUIRED. The + assertion. +</DD> +<DT>wrap_scope</DT> +<DD> OPTIONAL. The Authorization + Server MAY define authorization scope values for the Client to + include +</DD> +<DT>Additional parameters</DT> +<DD> Any additional + parameters, as defined by the Authorization Server. +</DD> +</DL></BLOCKQUOTE> + +<A name="0.2_anchor18"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.5.2.4"></A><H3>5.2.4. +Successful Access Token Response from Authorization Server</H3> + +<P>If successful, the Authorization Server returns: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> HTTP 200 OK +</PRE></DIV> +<P>with the Access Token in the response body. The response body + contains the following parameters: +</P> +<P></P> +<BLOCKQUOTE><DL> +<DT>wrap_access_token</DT> +<DD> REQUIRED. The Access + Token. +</DD> +<DT>wrap_access_token_expires_in</DT> +<DD> OPTIONAL. + The lifetime of the Access Token in seconds. For example, 3600 + represents one hour. +</DD> +<DT>Additional parameters</DT> +<DD> Any additional + parameters, as defined by the Authorization Server. +</DD> +</DL></BLOCKQUOTE> + +<P>The Client may now use the Access Token to access the Protected + Resource per <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_ProtectedResource">Section 4<SPAN> (</SPAN><SPAN>Accessing a Protected Resource</SPAN><SPAN>)</SPAN></A>. +</P> +<A name="0.2_anchor19"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.5.2.5"></A><H3>5.2.5. +Unsuccessful Access Token Response from Authorization Server</H3> + +<P>If the assertion is not valid, the Authorization Server MUST + respond with: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> HTTP 401 Unauthorized +</PRE></DIV> +<P>and the HTTP header: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> WWW-Authenticate: WRAP +</PRE></DIV> +<P>The Client MUST obtain a valid assertion by repeating <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p2.assertion">Section 5.2.2<SPAN> (</SPAN><SPAN>Client Obtains Assertion</SPAN><SPAN>)</SPAN></A> before retrying the request. +</P> +<A name="0.2_anchor20"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.5.2.6"></A><H3>5.2.6. +Client Refreshes Access Token</H3> + +<P>Authorization Servers SHOULD issue Access Tokens that expire and + require Clients to refresh them. Upon receiving the HTTP 401 + response when accessing protected resources per <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_ProtectedResource">Section 4<SPAN> (</SPAN><SPAN>Accessing a Protected Resource</SPAN><SPAN>)</SPAN></A>, the Client should request a new + Access Token by repeating <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p2.request">Section 5.2.3<SPAN> (</SPAN><SPAN>Client Requests Access Token</SPAN><SPAN>)</SPAN></A> if the + assertion is still valid, otherwise the Client MUST obtain a new, + valid assertion by repeating <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p2.assertion">Section 5.2.2<SPAN> (</SPAN><SPAN>Client Obtains Assertion</SPAN><SPAN>)</SPAN></A>. +</P> +<A name="0.2_user.profiles"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6"></A><H3>6. +Acquiring an Access Token: User Delegation Profiles</H3> + +<P>These are the profiles the Client uses when acting on behalf of a + User. +</P> +<A name="0.2_p3"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.1"></A><H3>6.1. +Username and Password Profile</H3> + +<P>This profile is suitable where the Client is an application the + User has installed on their computer and the User uses a username and + password to authenticate to the Authorization Server. This profile + enables a Client to act on behalf of the User without having to + permanently store the User's username and password. +</P> +<A name="0.2_anchor21"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.1.1"></A><H3>6.1.1. +Provisioning</H3> + +<P>Prior to initiating this protocol profile, the Authorization + Server MAY have required the Client to have obtained a Client + Identifier from the Authorization Server. +</P> +<A name="0.2_p3.password"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.1.2"></A><H3>6.1.2. +Client Obtains Username and Password</H3> + +<P>The Client obtains the User's username and password from the + user. The Client MUST discard the username and password once an + Access Token has been obtained. +</P> +<A name="0.2_p3.request"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.1.3"></A><H3>6.1.3. +Client Requests Access Token</H3> + +<P>The Client makes an HTTPS request to the Authorization Server's + Access Token URL using POST. The request contains the following + parameters: +</P> +<P></P> +<BLOCKQUOTE><DL> +<DT>wrap_client_id</DT> +<DD> REQUIRED. The Client + Identifier. +</DD> +<DT>wrap_username</DT> +<DD> REQUIRED. The User's + username. +</DD> +<DT>wrap_password</DT> +<DD> REQUIRED. The User's + password. +</DD> +<DT>wrap_scope</DT> +<DD> OPTIONAL. The Authorization + Server MAY define authorization scope values for the Client to + include. +</DD> +<DT>Additional parameters</DT> +<DD> Any additional + parameters, as defined by the Authorization Server. +</DD> +</DL></BLOCKQUOTE> + +<A name="0.2_anchor22"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.1.4"></A><H3>6.1.4. +Successful Access Token Response from Authorization Server</H3> + +<P>If successful, the Authorization Server returns: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> HTTP 200 OK +</PRE></DIV> +<P>with the Access Token in the response body. The response body + contains the following parameters: +</P> +<P></P> +<BLOCKQUOTE><DL> +<DT>wrap_access_token</DT> +<DD> REQUIRED. The Access + Token. +</DD> +<DT>wrap_access_token_expires_in</DT> +<DD> OPTIONAL. + The lifetime of the Access Token in seconds. For example, 3600 + represents one hour. +</DD> +<DT>Additional parameters</DT> +<DD> Any additional + parameters, as defined by the Authorization Server. +</DD> +</DL></BLOCKQUOTE> + +<P>The Client MUST discard the User's username and password. The + Client securely stores the Refresh Token for later use. The Client + may now use the Access Token to access the Protected Resource per + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_ProtectedResource">Section 4<SPAN> (</SPAN><SPAN>Accessing a Protected Resource</SPAN><SPAN>)</SPAN></A>. +</P> +<A name="0.2_anchor23"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.1.5"></A><H3>6.1.5. +Unsuccessful Access Token Response from Authorization Server</H3> + +<P>The Authorization Server MUST verify User's username and + password. If the verification fails, the Authorization Server MUST + respond with: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> HTTP 401 Unauthorized +</PRE></DIV> +<P>and the HTTP header: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> WWW-Authenticate: WRAP +</PRE></DIV> +<P>The Client needs to obtain a valid username and password from the + User per <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p3.password">Section 6.1.2<SPAN> (</SPAN><SPAN>Client Obtains Username and Password</SPAN><SPAN>)</SPAN></A> before retrying the + request. +</P> +<A name="0.2_anchor24"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.1.6"></A><H3>6.1.6. +Verification URL Response from Authorization Server</H3> + +<P>If the Authorization Server determines that the Client may be + malicious, the Authorization Server MAY require the Client to + instruct the User to visit a Verification URL. The Authorization + Server communicates its requirement by responding to the Client's + Access Token request with the following: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> HTTP 400 Bad Request +</PRE></DIV> +<P>and the body of the Authorization Server response contains the + following parameter: +</P> +<P></P> +<BLOCKQUOTE><DL> +<DT>wrap_verification_url</DT> +<DD>REQUIRED. The + verification URL that the Client MUST either load in the User's + browser, or display for the User to enter into a browser. +</DD> +</DL></BLOCKQUOTE> + +<P>The Client MUST then wait for the User to indicate they have + successfully completed the verification process at the Authorization + Server and attempt to obtain an Access Token Refresh Token per <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p3.request">Section 6.1.3<SPAN> (</SPAN><SPAN>Client Requests Access Token</SPAN><SPAN>)</SPAN></A> again. +</P> +<A name="0.2_anchor25"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.1.7"></A><H3>6.1.7. +CAPTCHA Response from Authorization Server</H3> + +<P>If the Authorization Server determines that the Client may be + malicious, the Authorization Server MAY require the Client to have + the User solve a CAPTCHA Puzzle. The Authorization Server + communicates its requirement by responding to the Client's Access + Token request with the following: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> HTTP 400 Bad Request +</PRE></DIV> +<P>and the body of the Authorization Server response contains the + following parameter: +</P> +<P></P> +<BLOCKQUOTE><DL> +<DT>wrap_captcha_url</DT> +<DD>REQUIRED. The URL to + the CAPTCHA puzzle image. +</DD> +</DL></BLOCKQUOTE> + +<P>The Client MUST present the User with the CAPTCHA puzzle and + prompt for a solution. The Client then MAY attempt to obtain an + Access Token per <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p3.request">Section 6.1.3<SPAN> (</SPAN><SPAN>Client Requests Access Token</SPAN><SPAN>)</SPAN></A> again, including + the following additional parameter: +</P> +<P></P> +<BLOCKQUOTE><DL> +<DT>wrap_captcha_url</DT> +<DD>REQUIRED. The URL to + the CAPTCHA puzzle received from the Authorization Server. +</DD> +<DT>wrap_captcha_solution</DT> +<DD>REQUIRED. The + solution string to the CAPTCHA puzzle as defined by the + Authorization Server. +</DD> +</DL></BLOCKQUOTE> + +<A name="0.2_anchor26"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.1.8"></A><H3>6.1.8. +Client Refreshes Access Token</H3> + +<P>Refreshing an Access Token is the same in <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p3">Section 6.1<SPAN> (</SPAN><SPAN>Username and Password Profile</SPAN><SPAN>)</SPAN></A>, <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p4">Section 6.2<SPAN> (</SPAN><SPAN>Web App Profile</SPAN><SPAN>)</SPAN></A>, and <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p5">Section 6.3<SPAN> (</SPAN><SPAN>Rich App Profile</SPAN><SPAN>)</SPAN></A>. Authorization Servers SHOULD issue Access + Tokens that expire and require Clients to refresh them. Upon + receiving the HTTP 401 response when accessing protected resources + per <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_ProtectedResource">Section 4<SPAN> (</SPAN><SPAN>Accessing a Protected Resource</SPAN><SPAN>)</SPAN></A>, the Client makes an + HTTPS request to the Authorization Server's Refresh Token URL using + POST. The request contains the following parameters: +</P> +<P></P> +<BLOCKQUOTE><DL> +<DT>wrap_refresh_token</DT> +<DD>REQUIRED. The Refresh + Token that was received in <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p3.request">Section 6.1.3<SPAN> (</SPAN><SPAN>Client Requests Access Token</SPAN><SPAN>)</SPAN></A> +</DD> +<DT>Additional parameters:</DT> +<DD>Any additional + parameters, as defined by the Authorization Server. +</DD> +</DL></BLOCKQUOTE> + +<A name="0.2_anchor27"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.1.9"></A><H3>6.1.9. +Successful Access Token Refresh</H3> + +<P>If successful, the Authorization Server returns: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> HTTP 200 OK +</PRE></DIV> +<P>with the Access Token in the response body. The response body + contains the following parameters: +</P> +<P></P> +<BLOCKQUOTE><DL> +<DT>wrap_access_token</DT> +<DD> REQUIRED. The Access + Token. +</DD> +<DT>wrap_access_token_expires_in</DT> +<DD> OPTIONAL. + The lifetime of the Access Token in seconds. For example, 3600 + represents one hour. +</DD> +<DT>Additional parameters</DT> +<DD> Any additional + parameters, as defined by the Authorization Server. +</DD> +</DL></BLOCKQUOTE> + +<A name="0.2_anchor28"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.1.10"></A><H3>6.1.10. +Unsuccessful Access Token Refresh</H3> + +<P>The Authorization Server MUST verify the Refresh Token. If the + verification fails, the Authorization Server MUST respond with +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> HTTP 401 Unauthorized +</PRE></DIV> +<P>and the HTTP header: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> WWW-Authenticate: WRAP +</PRE></DIV> +<P>The Client MUST again request authorization from the User by + prompting for the User's username and password per <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p3.password">Section 6.1.2<SPAN> (</SPAN><SPAN>Client Obtains Username and Password</SPAN><SPAN>)</SPAN></A> before retrying the request. +</P> +<A name="0.2_p4"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.2"></A><H3>6.2. +Web App Profile</H3> + +<P>This profile is suitable when the Client is a web application + calling the Protected Resource on behalf of a User. This profile + enables a Client to act on behalf of the User without acquiring a + User's credentials. +</P> +<A name="0.2_anchor29"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.2.1"></A><H3>6.2.1. +Provisioning</H3> + +<P>Prior to initiating this protocol profile, the Client MUST have + obtained a Client Identifier and Client Secret from the + Authorization Server. The Authorization Server MAY have also + required the Client to register the Callback URL. +</P> +<A name="0.2_p4.authorization"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.2.2"></A><H3>6.2.2. +Client Directs the User to the Authorization Server</H3> + +<P>The Client initiates an authorization request by redirecting the + User's browser to the Authorization Server's User Authorization URL, + with the following parameters: +</P> +<P></P> +<BLOCKQUOTE><DL> +<DT>wrap_client_id</DT> +<DD> REQUIRED. The Client + Identifier. +</DD> +<DT>wrap_callback </DT> +<DD> REQUIRED. The + Callback URL. An absolute URL to which the Authorization Server + will redirect the User back after the User has approved the + authorization request. Authorization Servers MAY require that + the wrap_callback URL match the previously registered value for + the Client Identifier. +</DD> +<DT>wrap_client_state</DT> +<DD>OPTIONAL. An opaque + value that Clients can use to maintain state associated with + this request. If this value is present, the Authorization Server + MUST return it to the Client's Callback URL. +</DD> +<DT>wrap_scope</DT> +<DD> OPTIONAL. The Authorization + Server MAY define authorization scope values for the Client to + include. +</DD> +<DT>Additional parameters</DT> +<DD> Any additional + parameters, as defined by the Authorization Server. +</DD> +</DL></BLOCKQUOTE> + +<A name="0.2_anchor30"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.2.3"></A><H3>6.2.3. +Authorization Server Confirms Authorization Request with User</H3> + +<P>Upon receiving an authorization request from the Client by a + redirection of the User's browser, the Authorization Server + authenticates the user, presents the User with the Protected + Resource access that will be granted to the Client, and prompts the + User to confirm the request. +</P> +<P>If the User denies the request, the Authorization Server MAY + allow the User to return to the Client Callback URL with the + following parameters added: +</P> +<P></P> +<BLOCKQUOTE><DL> +<DT>wrap_error_reason</DT> +<DD> REQUIRED. Value is + user_denied +</DD> +<DT>wrap_client_state</DT> +<DD> REQUIRED if the + Client sent the value in the authorization request in <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p4.authorization">Section 6.2.2<SPAN> (</SPAN><SPAN>Client Directs the User to the Authorization Server</SPAN><SPAN>)</SPAN></A> +</DD> +</DL></BLOCKQUOTE> + +<P>If the User approves the request, the Authorization Server + generates a Verification Code and associates it with the Client + Identifier and Callback URL. +</P> +<A name="0.2_anchor31"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.2.4"></A><H3>6.2.4. +Authorization Server Directs User back to the Client</H3> + +<P>If the User approved the request, the Authorization Server MUST + redirect the User back to the Callback URL, with the following + parameters added: +</P> +<P></P> +<BLOCKQUOTE><DL> +<DT>wrap_verification_code</DT> +<DD> REQUIRED. The + Verification Code. +</DD> +<DT>wrap_client_state</DT> +<DD> REQUIRED if the + Client sent the value in the authorization request in <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p4.authorization">Section 6.2.2<SPAN> (</SPAN><SPAN>Client Directs the User to the Authorization Server</SPAN><SPAN>)</SPAN></A> +</DD> +<DT>Additional parameters:</DT> +<DD>Any additional + parameters, as defined by the Authorization Server. +</DD> +</DL></BLOCKQUOTE> + +<A name="0.2_p4.request"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.2.5"></A><H3>6.2.5. +Client Requests Access Token</H3> + +<P>The Client makes an HTTPS request to the Authorization Server's + Access Token URL, using POST. The request contains the following + parameters in the body of the request: +</P> +<P></P> +<BLOCKQUOTE><DL> +<DT>wrap_client_id</DT> +<DD> REQUIRED. The Client + Identifier +</DD> +<DT>wrap_client_secret</DT> +<DD>REQUIRED. The Client + Secret +</DD> +<DT>wrap_verification_code</DT> +<DD> REQUIRED. The + Verification Code. +</DD> +<DT>wrap_callback</DT> +<DD> REQUIRED. The Callback + URL used to obtain the Verification Code. +</DD> +<DT>Additional parameters:</DT> +<DD>Any additional + parameters, as defined by the Authorization Server. +</DD> +</DL></BLOCKQUOTE> + +<A name="0.2_anchor32"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.2.6"></A><H3>6.2.6. +Successful Access Token Response from Authorization Server</H3> + +<P>After receiving the Access Token request, the Authorization + Server verifies the request as follows: +</P> +<P></P> +<BLOCKQUOTE> +<P>the Client Secret MUST match the Client Identifer +</P> +<P>the Client Identifier MUST match the Client Identifier from + the authorization redirect +</P> +<P>the Verification Code MUST match the Client Identifier from + the authorization redirect +</P> +<P>the Callback URL MUST match the Callback URL from the + authorization redirect +</P> +<P>if the Callback URL or Callback URL pattern was registered + with the Authorization Server, the Callback URL MUST match the + Callback URL or Callback URL pattern as defined by the + Authorization Server +</P> +<P>the Verification Code MUST not have expired +</P> +</BLOCKQUOTE> + +<P>The Authorization Server MAY also require that a Verification + Code is not reused. +</P> +<P>If verification is successful, the Authorization Server + returns: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> HTTP 200 OK +</PRE></DIV> +<P>with the Refresh Token and the Access Token in the response body. + The response body contains the following parameters: +</P> +<P></P> +<BLOCKQUOTE><DL> +<DT>wrap_refresh_token</DT> +<DD> REQUIRED. The + Refresh Token. +</DD> +<DT>wrap_access_token</DT> +<DD> REQUIRED. The Access + Token. +</DD> +<DT>wrap_access_token_expires_in</DT> +<DD> OPTIONAL. + The lifetime of the Access Token in seconds. For example, 3600 + represents one hour. +</DD> +<DT>Additional parameters</DT> +<DD> Any additional + parameters, as defined by the Authorization Server. +</DD> +</DL></BLOCKQUOTE> + +<P>The Client securely stores the Refresh Token for later use. The + Client may now use the Access Token to access the Protected Resource + per <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_ProtectedResource">Section 4<SPAN> (</SPAN><SPAN>Accessing a Protected Resource</SPAN><SPAN>)</SPAN></A>. +</P> +<A name="0.2_anchor33"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.2.7"></A><H3>6.2.7. +Unsuccessful Access Token Response from Authorization Server</H3> + +<P>The Authorization Server MUST first verify the Client Identifier + and Client Secret. If they are invalid, the Authorization Server + MUST respond with: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> HTTP 401 Unauthorized +</PRE></DIV> +<P>and the HTTP header: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> WWW-Authenticate: WRAP +</PRE></DIV> +<P>The Client MUST obtain a valid Client Identifier and Client + Secret before retrying the request. +</P> +<P>The Authorization Server MUST then verify that the Callback URL + and Verification Code are associated with the Client Identifier. If + the verification fails, the Authorization Server MUST respond + with: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> HTTP 400 Bad Request +</PRE></DIV> +<P>and the body of the Authorization Server response contains the + following parameters: +</P> +<P></P> +<BLOCKQUOTE><DL> +<DT>wrap_error_reason</DT> +<DD>OPTIONAL. If all the + parameters are valid except that the Verification Code has + expired or been revoked, then it is RECOMMENDED that this + parameter be included and if so, then the value MUST be: +</DD> +<DT> +<DD><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> expired_verification_code +</PRE></DIV> +</DD> +<DT> +<DD>This enables the Client to detect it needs a new Verification + Code and to direct the User to the Authorization Server per + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p4.authorization">Section 6.2.2<SPAN> (</SPAN><SPAN>Client Directs the User to the Authorization Server</SPAN><SPAN>)</SPAN></A> +</DD> +<DT> +<DD>If the Callback URL is invalid, the value MUST be: +</DD> +<DT> +<DD><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> invalid_callback +</PRE></DIV> +</DD> +<DT>Additional parameters</DT> +<DD> Any additional + parameters, as defined by the Authorization Server. +</DD> +</DL></BLOCKQUOTE> + +<A name="0.2_anchor34"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.2.8"></A><H3>6.2.8. +Client Refreshes Access Token</H3> + +<P>Refreshing an Access Token is the same in <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p3">Section 6.1<SPAN> (</SPAN><SPAN>Username and Password Profile</SPAN><SPAN>)</SPAN></A>, <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p4">Section 6.2<SPAN> (</SPAN><SPAN>Web App Profile</SPAN><SPAN>)</SPAN></A>, and <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p5">Section 6.3<SPAN> (</SPAN><SPAN>Rich App Profile</SPAN><SPAN>)</SPAN></A>. Authorization Servers SHOULD issue Access + Tokens that expire and require Clients to refresh them. Upon + receiving the HTTP 401 response when accessing protected resources + per <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_ProtectedResource">Section 4<SPAN> (</SPAN><SPAN>Accessing a Protected Resource</SPAN><SPAN>)</SPAN></A>, the Client makes an + HTTPS request to the Authorization Server's Refresh Token URL using + POST. The request contains the following parameters: +</P> +<P></P> +<BLOCKQUOTE><DL> +<DT>wrap_refresh_token</DT> +<DD>REQUIRED. The Refresh + Token that was received in <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p4.request">Section 6.2.5<SPAN> (</SPAN><SPAN>Client Requests Access Token</SPAN><SPAN>)</SPAN></A> +</DD> +<DT>Additional parameters:</DT> +<DD>Any additional + parameters, as defined by the Authorization Server. +</DD> +</DL></BLOCKQUOTE> + +<A name="0.2_anchor35"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.2.9"></A><H3>6.2.9. +Successful Access Token Refresh</H3> + +<P>If successful, the Authorization Server returns: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> HTTP 200 OK +</PRE></DIV> +<P>with the Access Token in the response body. The response body + contains the following parameters: +</P> +<P></P> +<BLOCKQUOTE><DL> +<DT>wrap_access_token</DT> +<DD> REQUIRED. The Access + Token. +</DD> +<DT>wrap_access_token_expires_in</DT> +<DD> OPTIONAL. + The lifetime of the Access Token in seconds. For example, 3600 + represents one hour. +</DD> +<DT>Additional parameters</DT> +<DD> Any additional + parameters, as defined by the Authorization Server. +</DD> +</DL></BLOCKQUOTE> + +<A name="0.2_anchor36"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.2.10"></A><H3>6.2.10. +Unsuccessful Access Token Refresh</H3> + +<P>The Authorization Server MUST verify the Refresh Token. If the + verification fails, the Authorization Server MUST respond with +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> HTTP 401 Unauthorized +</PRE></DIV> +<P>and the HTTP header: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> WWW-Authenticate: WRAP +</PRE></DIV> +<P>The Client MUST again request authorization from the User per + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p4.authorization">Section 6.2.2<SPAN> (</SPAN><SPAN>Client Directs the User to the Authorization Server</SPAN><SPAN>)</SPAN></A>. +</P> +<A name="0.2_p5"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.3"></A><H3>6.3. +Rich App Profile</H3> + +<P>This profile is suitable where the Client is an application the + User has installed on their computer and there is a browser available + for the Client to launch. This profile enables a Client to act on + behalf of the User regardless of how the User authenticates to the + Server and without access to the User's credentials. +</P> +<A name="0.2_anchor37"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.3.1"></A><H3>6.3.1. +Provisioning</H3> + +<P>Prior to initiating this protocol profile, the Client MAY be + required to register the Client Identifier and/or the Callback URL + with the Server. +</P> +<A name="0.2_p5.authorization"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.3.2"></A><H3>6.3.2. +Client Directs the User to the Authorization Server</H3> + +<P>The Client initiates an authorization request by opening the + User's browser with the Server's User Authorization URL, and + including the following parameters: +</P> +<P></P> +<BLOCKQUOTE><DL> +<DT>wrap_client_id</DT> +<DD> REQUIRED. The Client + Identifier. +</DD> +<DT>wrap_callback </DT> +<DD> OPTIONAL. A Callback + URL where the Authorization Server MAY redirect the User's + browser after the User responds to the authorization + request. +</DD> +<DT>wrap_client_state</DT> +<DD>OPTIONAL. An opaque + value that Clients can use to maintain state associated with + this request. If this value is present, the Authorization Server + MUST return it to the Client's Callback URL. +</DD> +<DT>wrap_scope</DT> +<DD> OPTIONAL. The Authorization + Server MAY define authorization scope values for the Client to + include. +</DD> +<DT>Additional parameters</DT> +<DD> Any additional + parameters, as defined by the Authorization Server. +</DD> +</DL></BLOCKQUOTE> + +<A name="0.2_anchor38"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.3.3"></A><H3>6.3.3. +Authorization Server Confirms Authorization Request with User</H3> + +<P>Upon receiving an authorization request from the Client by way of + the User's browser, the Authorization Server authenticates the user, + presents the User with the Protected Resource access that will be + granted to the Client, and prompts the User to confirm the request. + If the User approves the request, the Authorization Server generates + a Verification Code. If the User denied access, the Authorization + Server MAY set the Verification Code to the reserved value: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> user_denied +</PRE></DIV> +<P>It is RECOMMENDED the Verification Code be single use, and expire + within minutes of issue. There are a number of mechanisms for the + Authorization Server to transmit the Verification Code to the + Client, specified below. +</P> +<P>Rich Application interaction with the User and the Authorization + Server is an area of active research and development. If the Rich + Application is able to retrieve the verifier directly from the + callback URL returned by the Authorization Server, an improved user + experience is possible. However, not all applications are able to + interact with the Authorization Server in this manner. +</P> +<A name="0.2_anchor39"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.3.3.1"></A><H3>6.3.3.1. +Applications with Callback URLs</H3> + +<P>Rich Applications may be able to receive callback URLs in any + of several ways. For example, the Rich Application may register a + custom protocol handler with the application platform so that the + application will be invoked when the browser is redirected to the + callback URL. Alternatively, the callback URL may point to a web + site with which the Rich Application has a trust relationship. The + web site can then pass the Callback URL down to the Rich + Application for processing. Finally, the Callback URL may point to + a web site that will display the Callback URL to the screen along + with instructions for the user to enter the Verification Code into + the application. +</P> +<P>For Rich Applications with a Callback URL, the Authorization + Server MUST redirect the User back to the Callback URL, with the + following parameters added: +</P> +<P></P> +<BLOCKQUOTE><DL> +<DT>wrap_verification_code</DT> +<DD> REQUIRED. The + Verification Code +</DD> +<DT>wrap_client_state</DT> +<DD> REQUIRED if the + Client sent the value in the authorization request in <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p5.authorization">Section 6.3.2<SPAN> (</SPAN><SPAN>Client Directs the User to the Authorization Server</SPAN><SPAN>)</SPAN></A> +</DD> +<DT>Additional parameters</DT> +<DD> Any + additional parameters, as defined by the Authorization + Server. +</DD> +</DL></BLOCKQUOTE> + +<P>If the User denied access, the Server MAY redirect the User's + browser to the Callback URL with the Verification Code set to the + reserved value: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> user_denied +</PRE></DIV> +<A name="0.2_anchor40"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.3.3.2"></A><H3>6.3.3.2. +Applications without Callback URLs</H3> + +<P>Rich Applications without Callback URLs need to receive the + verification code in other ways. For Rich Applications without a + Callback URL, the Authorization Server MUST present the + Verification Code on the web page and instruct the user to enter + it into the Client. +</P> +<P>The Server MAY also append the Verification Code to the title + of the HTML page so that Clients that have access to the title of + the browser's current page can obtain the Verification Code + without requiring the User enter the Verification Code into the + Client. The Client can parse the title looking for "code=" and + then the rest of the title is the Verification Code. If adding the + Verification Code to the title of the HTML page, the Server MUST + also include the wrap_client_state parameter if sent from the + Client as the "state=" parameter. +</P> +<P>Eg. For <A href="http://example.com/" target="_blank">example.com</A> where the Verification Code = WF34F7HG and + Client State = NMMGFJJ, the Server would set the title of the page + to something like: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> <title>Successful delegation, code=WF34F7HG +state=NMMGFJJ</title></PRE></DIV> +<P>If the User denied access, the Server MAY append + code=user_denied to the title of the HTML page so that the Client + can detect that the User has denied access. +</P> +<A name="0.2_p5.request"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.3.4"></A><H3>6.3.4. +Client Requests Access Token</H3> + +<P>The Client makes an HTTPS request to the Server's Access Token + URL using POST. The request contains the following parameters: +</P> +<P></P> +<BLOCKQUOTE><DL> +<DT>wrap_client_id</DT> +<DD> REQUIRED. The Client + Identifier +</DD> +<DT>wrap_verification_code</DT> +<DD> REQUIRED. The + Verification Code. +</DD> +<DT>Additional parameters:</DT> +<DD>Any additional + parameters, as defined by the Authorization Server. +</DD> +</DL></BLOCKQUOTE> + +<A name="0.2_p5.verification"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.3.5"></A><H3>6.3.5. +Successful Access Token Response from Authorization Server</H3> + +<P>The Server checks the Verification Code was previously issued to + the same Client Identifier, has not expired and has not been used. + If these conditions are met, the Server marks the Verification Code + as being used and returns: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> HTTP 200 OK +</PRE></DIV> +<P>with the Refresh Token and an Access Token in the response body. + The response body contains the following parameters: +</P> +<P></P> +<BLOCKQUOTE><DL> +<DT>wrap_refresh_token</DT> +<DD> REQUIRED. The + Refresh Token. +</DD> +<DT>wrap_access_token</DT> +<DD> REQUIRED. The Access + Token. +</DD> +<DT>wrap_access_token_expires_in</DT> +<DD> OPTIONAL. + The lifetime of the Access Token in seconds. For example, 3600 + represents one hour. +</DD> +<DT>Additional parameters</DT> +<DD> Any additional + parameters, as defined by the Authorization Server. +</DD> +</DL></BLOCKQUOTE> + +<P>The Client securely stores the Refresh Token for later use. The + Client may now use the Access Token to access the Protected Resource + per <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_ProtectedResource">Section 4<SPAN> (</SPAN><SPAN>Accessing a Protected Resource</SPAN><SPAN>)</SPAN></A>. +</P> +<A name="0.2_anchor41"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.3.6"></A><H3>6.3.6. +Unsuccessful Access Token Response from Authorization Server</H3> + +<P>The Authorization Server MUST first verify the Client Identifier + and Client Secret per <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p5.verification">Section 6.3.5<SPAN> (</SPAN><SPAN>Successful Access Token Response from Authorization Server</SPAN><SPAN>)</SPAN></A>. If + they are invalid, the Authorization Server MUST respond with: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> HTTP 401 Unauthorized +</PRE></DIV> +<P>and the HTTP header: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> WWW-Authenticate: WRAP +</PRE></DIV> +<P>The Client needs to obtain a new Verification Code per <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p5.authorization">Section 6.3.2<SPAN> (</SPAN><SPAN>Client Directs the User to the Authorization Server</SPAN><SPAN>)</SPAN></A>. +</P> +<A name="0.2_anchor42"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.3.7"></A><H3>6.3.7. +Client Refreshes Access Token</H3> + +<P>Refreshing an Access Token is the same in <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p3">Section 6.1<SPAN> (</SPAN><SPAN>Username and Password Profile</SPAN><SPAN>)</SPAN></A>, <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p4">Section 6.2<SPAN> (</SPAN><SPAN>Web App Profile</SPAN><SPAN>)</SPAN></A>, and <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p5">Section 6.3<SPAN> (</SPAN><SPAN>Rich App Profile</SPAN><SPAN>)</SPAN></A>. Authorization Servers SHOULD issue Access + Tokens that expire and require Clients to refresh them. Upon + receiving the HTTP 401 response when accessing protected resources + per <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_ProtectedResource">Section 4<SPAN> (</SPAN><SPAN>Accessing a Protected Resource</SPAN><SPAN>)</SPAN></A>, the Client makes an + HTTPS request to the Authorization Server's Refresh Token URL using + POST. The request contains the following parameters: +</P> +<P></P> +<BLOCKQUOTE><DL> +<DT>wrap_refresh_token</DT> +<DD>REQUIRED. The Refresh + Token that was received in <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p5.request">Section 6.3.4<SPAN> (</SPAN><SPAN>Client Requests Access Token</SPAN><SPAN>)</SPAN></A> +</DD> +<DT>Additional parameters:</DT> +<DD>Any additional + parameters, as defined by the Authorization Server. +</DD> +</DL></BLOCKQUOTE> + +<A name="0.2_anchor43"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.3.8"></A><H3>6.3.8. +Successful Access Token Refresh</H3> + +<P>If successful, the Authorization Server returns: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> HTTP 200 OK +</PRE></DIV> +<P>with the Access Token in the response body. The response body + contains the following parameters: +</P> +<P></P> +<BLOCKQUOTE><DL> +<DT>wrap_access_token</DT> +<DD> REQUIRED. The Access + Token. +</DD> +<DT>wrap_access_token_expires_in</DT> +<DD> OPTIONAL. + The lifetime of the Access Token in seconds. For example, 3600 + represents one hour. +</DD> +<DT>Additional parameters</DT> +<DD> Any additional + parameters, as defined by the Authorization Server. +</DD> +</DL></BLOCKQUOTE> + +<A name="0.2_anchor44"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.6.3.9"></A><H3>6.3.9. +Unsuccessful Access Token Refresh</H3> + +<P>The Authorization Server MUST verify the Refresh Token. If the + verification fails, the Authorization Server MUST respond with +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> HTTP 401 Unauthorized +</PRE></DIV> +<P>and the HTTP header: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> WWW-Authenticate: WRAP +</PRE></DIV> +<P>The Client MUST again request authorization from the User per + <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_p5.authorization">Section 6.3.2<SPAN> (</SPAN><SPAN>Client Directs the User to the Authorization Server</SPAN><SPAN>)</SPAN></A>. +</P> +<A name="0.2_ParamCon"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.7"></A><H3>7. +Parameter Considerations</H3> + +<A name="0.2_anchor45"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.7.1"></A><H3>7.1. +Authorization Server Request / Response Parameter Encoding</H3> + +<P>All requests made directly to the Authorization Server use the HTTP + POST method and the parameters MUST be in the body of the message and + formatted as application/x-www-form-<WBR>urlencoded per <A href="http://www.w3.org/TR/1999/REC-W3C.REC-html40-19980424-19991224/interact/forms.html#h-17.13.4.1" target="_blank">17.13.4</A> + of <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_W3C.REC-html40-19980424">HTML 4.01<SPAN> (</SPAN><SPAN>Hors, A., Jacobs, I., and D. Raggett, “HTML 4.0 Specification,” April 1998.</SPAN><SPAN>)</SPAN></A> [W3C.REC‑html40‑19980424]. +</P> +<P>Any parameters in the response from the Authorization Server MUST + be in the body of the message and formatted as + application/x-www-form-<WBR>urlencoded per <A href="http://www.w3.org/TR/1999/REC-W3C.REC-html40-19980424-19991224/interact/forms.html#h-17.13.4.1" target="_blank">17.13.4</A> + of <A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_W3C.REC-html40-19980424">HTML 4.01<SPAN> (</SPAN><SPAN>Hors, A., Jacobs, I., and D. Raggett, “HTML 4.0 Specification,” April 1998.</SPAN><SPAN>)</SPAN></A> [W3C.REC‑html40‑19980424]. +</P> +<A name="0.2_anchor46"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.7.2"></A><H3>7.2. +Parameter Size</H3> + +<P></P> +<BLOCKQUOTE><DL> +<DT>HTTP Headers</DT> +<DD> Web servers often impose a + maximum on the combined size of all HTTP headers ranging from 8KB + to 16KB. The size of the Access Token should be small enough to + ensure the total size of the HTTP headers does not exceed the + limits of web servers. +</DD> +<DT>URLs</DT> +<DD> Web servers and browsers often + impose a maximum on the total length of the URL of as low as 2083 + bytes. The length of URLs exposed by the Authorization Server and + the length of parameters passed on a URL should be minimized so + that the total length does not exceed this limit. +</DD> +</DL></BLOCKQUOTE> + +<A name="0.2_anchor47"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.7.3"></A><H3>7.3. +Access Token Format</H3> + +<P>OAuth WRAP does not specify the format of the Access Token. The + format is mutually agreed to by the Authorization Server and the + Protected Resource and is opaque to the Client. The Access Token + format MUST consist of legal characters in an HTTP header per + [Reference needed] +</P> +<P>The Simple Web Token (SWT) and JSON Web Token (JWT) are possible + Access Token formats. +</P> +<P>[TBD: entropy recommendations for Access Token so that it remains + secure during its lifetime] +</P> +<A name="0.2_anchor48"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.7.4"></A><H3>7.4. +Refresh Token Format</H3> + +<P>OAuth WRAP does not specify the format of the Refresh Token. The + Refresh Token is both generated and consumed by the Authorization + Server and is opaque to the Client and never exposed to the Protected + Resource. The Refresh Token is a long lived credential, and should + contain enough entropy that it cannot be guessed. The size limitations + of the Access Token are not applicable to the Refresh Token as the + Refresh Token is always in the body of an HTTP message. +</P> +<A name="0.2_anchor49"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.7.5"></A><H3>7.5. +Additional Authorization Server Parameters</H3> + +<P>The Authorization Server may define additional parameters to be + included in are returned from calls to the Access Token URL or User + Authorization URL. Parameters that start with wrap_ are reserved and + may not be used. +</P> +<A name="0.2_anchor50"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.7.6"></A><H3>7.6. +Parameter Names and Order</H3> + +<P>All parameter names are case sensitive. The parameters my appear in + any order. Unrecognized parameters are allowed, but MUST be + ignored. +</P> +<A name="0.2_IANA"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.8"></A><H3>8. +IANA Considerations</H3> + +<P>This memo includes no request to IANA. +</P> +<A name="0.2_Security"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.9"></A><H3>9. +Security Considerations</H3> + +<P>TBD: need to put in all the security considerations for + implementors. +</P> +<A name="0.2_rfc.references"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.10"></A><H3>10. +References</H3> + +<A name="0.2_rfc.references1"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<H3>10.1. Normative References</H3> +<TABLE width="99%" border="0"> +<TBODY><TR><TD valign="top"><A name="0.2_RFC2119">[RFC2119]</A></TD> +<TD><A href="mailto:sob@harvard.edu" target="_blank">Bradner, S.</A>, “<A href="http://tools.ietf.org/html/rfc2119" target="_blank">Key words for use in RFCs to Indicate Requirement Levels</A>,” BCP 14, RFC 2119, March 1997 (<A href="ftp://ftp.isi.edu/in-notes/rfc2119.txt" target="_blank">TXT</A>, <A href="http://xml.resource.org/public/rfc/html/rfc2119.html" target="_blank">HTML</A>, <A href="http://xml.resource.org/public/rfc/xml/rfc2119.xml" target="_blank">XML</A>).</TD></TR> +<TR><TD valign="top"><A name="0.2_RFC2606">[RFC2606]</A></TD> +<TD><A href="mailto:dee3@us.ibm.com" target="_blank">Eastlake, D.</A> and <A href="mailto:buglady@fuschia.net" target="_blank">A. Panitz</A>, “<A href="http://tools.ietf.org/html/rfc2606" target="_blank">Reserved Top Level DNS Names</A>,” BCP 32, RFC 2606, June 1999 (<A href="ftp://ftp.isi.edu/in-notes/rfc2606.txt" target="_blank">TXT</A>).</TD></TR> +<TR><TD valign="top"><A name="0.2_RFC2617">[RFC2617]</A></TD> +<TD><A href="mailto:john@math.nwu.edu" target="_blank">Franks, J.</A>, <A href="mailto:pbaker@verisign.com" target="_blank">Hallam-Baker, P.</A>, <A href="mailto:jeff@AbiSource.com" target="_blank">Hostetler, J.</A>, <A href="mailto:lawrence@agranat.com" target="_blank">Lawrence, S.</A>, <A href="mailto:paulle@microsoft.com" target="_blank">Leach, P.</A>, Luotonen, A., and <A href="mailto:stewart@OpenMarket.com" target="_blank">L. Stewart</A>, “<A href="http://tools.ietf.org/html/rfc2617" target="_blank">HTTP Authentication: Basic and Digest Access Authentication</A>,” RFC 2617, June 1999 (<A href="ftp://ftp.isi.edu/in-notes/rfc2617.txt" target="_blank">TXT</A>, <A href="http://xml.resource.org/public/rfc/html/rfc2617.html" target="_blank">HTML</A>, <A href="http://xml.resource.org/public/rfc/xml/rfc2617.xml" target="_blank">XML</A>).</TD></TR> +<TR><TD valign="top"><A name="0.2_W3C.REC-html40-19980424">[W3C.REC-html40-19980424]</A></TD> +<TD>Hors, A., Jacobs, I., and D. Raggett, “<A href="http://www.w3.org/TR/1998/REC-html40-19980424" target="_blank">HTML 4.0 Specification</A>,” World Wide Web Consortium Recommendation REC-html40-<WBR>19980424, April 1998 (<A href="http://www.w3.org/TR/1998/REC-html40-19980424" target="_blank">HTML</A>).</TD></TR> +</TBODY></TABLE> + +<A name="0.2_rfc.references2"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<H3>10.2. Informative References</H3> +<TABLE width="99%" border="0"> +<TBODY><TR><TD valign="top"><A name="0.2_I-D.narten-iana-considerations-rfc2434bis">[I-D.narten-iana-<WBR>considerations-rfc2434bis]</A></TD> +<TD>Narten, T. and H. Alvestrand, “<A href="http://www.ietf.org/internet-drafts/draft-narten-iana-considerations-rfc2434bis-09.txt" target="_blank">Guidelines for Writing an IANA Considerations Section in RFCs</A>,” draft-narten-iana-<WBR>considerations-rfc2434bis-09 (work in progress), March 2008 (<A href="http://www.ietf.org/internet-drafts/draft-narten-iana-considerations-rfc2434bis-09.txt" target="_blank">TXT</A>).</TD></TR> +<TR><TD valign="top"><A name="0.2_OASIS.saml-core-2.0-os">[OASIS.saml-core-2.0-os]</A></TD> +<TD><A href="mailto:cantor.2@osu.edu" target="_blank">Cantor, S.</A>, <A href="mailto:John.Kemp@nokia.com" target="_blank">Kemp, J.</A>, <A href="mailto:rphilpott@rsasecurity.com" target="_blank">Philpott, R.</A>, and <A href="mailto:eve.maler@sun.com" target="_blank">E. Maler</A>, “<A href="http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf" target="_blank">Assertions and Protocol for the OASIS Security Assertion Markup Language + (SAML) V2.0</A>,” OASIS Standard saml-core-2.0-os, March 2005.</TD></TR> +<TR><TD valign="top"><A name="0.2_OAuth Core 1.0">[OAuth Core 1.0]</A></TD> +<TD>Hammer-Lahav, E., “<A href="http://tools.ietf.org/html/draft-hammer-oauth-08" target="_blank">OAuth Core 1.0 Protocol</A>.”</TD></TR> +</TBODY></TABLE> + +<A name="0.2_anchor53"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.A"></A><H3>Appendix A. +Client Account and Password Profile Example</H3> + +<P>In this example, <A href="http://crm.example.com/" target="_blank">crm.example.com</A> is an application server that has a + Protected Resource at <A href="https://crm.example.com/data" target="_blank">https://crm.example.com/data</A>. DataDumper is an + application acting as a Client that periodically calls + <A href="https://crm.example.com/data" target="_blank">https://crm.example.com/data</A>. The Protected Resource trusts the + Authorization Server <A href="http://auth.example.net/" target="_blank">auth.example.net</A> to determine if a Client has + access. +</P> +<A name="0.2_anchor54"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.A.1"></A><H3>A.1. +Provisioning</H3> + +<P>The Authorization Server documentation defines the Access Token URL + as: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> <A href="https://auth.example.net/access_token" target="_blank">https://auth.example.net/<WBR>access_token</A> +</PRE></DIV> +<P>The Authorization Server has defined that the parameter Audience be + included in calls to the Access Token URL. +</P> +<P>The Client has been provisioned with the following: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> Client Account: datadumper Client Password: j2hw7GPsl0 +</PRE></DIV> +<P>The Protected Resource and the Authorization Server have agreed to + use a Simple Web Token (SWT) for the Access Token with the reserved + attributes Issuer, Audience, ExpiresOn and the public attribute + net.example.auth.account and have exchanged the following HMAC key + value (expressed in base 64): +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE>3iK5ZYAoBQuOqSgF/<WBR>YqlDw70HKRmbyXkrl5f4SJ4Toc= +</PRE></DIV> +<A name="0.2_anchor55"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.A.2"></A><H3>A.2. +Client Requests Access Token</H3> + +<P>The Client makes an HTTPS POST to: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE><A href="https://auth.example.net/access_token" target="_blank">https://auth.example.net/<WBR>access_token</A> +</PRE></DIV> +<P>With the following message body: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE>wrap_name=datadumper&wrap_<WBR>password=j2hw7GPsl0&Audience=<A href="http://crm.example.com/" target="_blank">c<WBR>rm.example.com</A> +</PRE></DIV> +<A name="0.2_anchor56"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.A.3"></A><H3>A.3. +Successful Access Token Response from Authorization Server</H3> + +<P>The Authorization Server checks that the Client Password j2hw7GPsl0 + is associated with the Client Name datadumper and that the Client is + authorized to access <A href="http://crm.example.com/" target="_blank">crm.example.com</A>. The Authorization Server notes + the time is 2010-02-03T04:05:06Z, which is 1265198706 seconds since + 1970-01-01T0:0:0Z. The Authorization Server would like the Access + Token to expire in an hour, so 3600 is added to the current time. The + Authorization Server then uses the values: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE>net.example.auth.account: +datadumper ExpiresOn: 1265202306 (1265198706 + 3600) +Audience: <A href="http://crm.example.com/" target="_blank">crm.example.com</A> +Issuer: <A href="http://auth.example.net/" target="_blank">auth.example.net</A> +</PRE></DIV> +<P>and the agreed HMAC key to generate the following SWT: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE>net.example.auth.account=<WBR>datadumper&ExpiresOn=<WBR>1265202306&Audience=crm. +<A href="http://example.com/" target="_blank">example.com</A>&Issuer=<A href="http://auth.example.net/" target="_blank">auth.<WBR>example.net</A>&HMACSHA256=N9%2F%<WBR>2F0tSos78Me36%2Bi +oBH0sFKfd7eCsURlEIheoUbCJk%3D +</PRE></DIV> +<P>The Authorization Server then responds to the Clients HTTPS request + with: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE>HTTP 200 OK +</PRE></DIV> +<P>and the Access Token and lifetime of the Access Token as + application/x-www-form-<WBR>urlencoded data in the body of the message as + such: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE>wrap_access_token=net.example.<WBR>auth.account%3Ddatadumper%<WBR>26ExpiresOn%3D +1265202306%26Audience%<A href="http://3dcrm.example.com/" target="_blank">3Dcrm.<WBR>example.com</A>%26Issuer%<A href="http://3dauth.example.net/" target="_blank">3Dauth.<WBR>example.net</A>%26 +HMACSHA256%3DN9%252F%<WBR>252F0tSos78Me36%<WBR>252BioBH0sFKfd7eCsURlEIheoUbCJ<WBR>k%2 +53D&wrap_access_token_expires_<WBR>in=3600</PRE></DIV> +<A name="0.2_anchor57"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.A.4"></A><H3>A.4. +Client Calls Protected Resource</H3> + +<P>The Client now has an Access Token valid for an hour. The Client + makes an API call to: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE><A href="https://crm.example.com/data" target="_blank">https://crm.example.com/data</A> +</PRE></DIV> +<P>including the following HTTP header: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE>Authorization: WRAP access_token="net.example.<WBR>auth.account=datadumper& +ExpiresOn=1265202306&Audience=<A href="http://crm.example.com/" target="_blank"><WBR>crm.example.com</A>&Issuer=<A href="http://auth.example.net/" target="_blank">auth.<WBR>example.net</A>& +HMACSHA256=N9%2F%<WBR>2F0tSos78Me36%<WBR>2BioBH0sFKfd7eCsURlEIheoUbCJk%<WBR>3D" +</PRE></DIV> +<P>The Protected Resources verifies the SWT and performs the Client's + request per the authorization attributes in the SWT. +</P> +<A name="0.2_anchor58"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.B"></A><H3>Appendix B. +Web App Profile Example</H3> + +<P>In this example, Jane, the User, listens to music from + <A href="http://music.example.com/" target="_blank">music.example.com</A> and updates her status at <A href="http://status.example.com/" target="_blank">status.example.com</A>. When + listening to music, Jane would like her status to be updated at the + start of each song. From an OAuth WRAP perspective, the Client is + <A href="http://music.example.com/" target="_blank">music.example.com</A>, the Protected Resource is + <A href="https://status.example.com/update" target="_blank">https://status.example.com/<WBR>update</A>, and <A href="http://auth.example.com/" target="_blank">auth.example.com</A> is the + Authorization Server trusted by <A href="http://status.example.com/" target="_blank">status.example.com</A>. +</P> +<A name="0.2_anchor59"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.B.1"></A><H3>B.1. +Provisioning</H3> + +<P>The Authorization Server documentation defines the following + URLs: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE> User Authorization URL: <A href="https://auth.example.com/user_authorization" target="_blank">https://auth.example.com/user_<WBR>authorization</A> + Access Token URL: <A href="https://auth.example.com/access_token" target="_blank">https://auth.example.com/<WBR>access_token</A> + Refresh Token URL: <A href="https://auth.example.com/refresh_token" target="_blank">https://auth.example.com/<WBR>refresh_token</A> +</PRE></DIV> +<P>The Authorization Server has defined that if the Client wants + authorization to update a User's status, that the Client include the + wrap_scope parameter with the value status_update when requesting + authorization. +</P> +<P>The Client has been provisioned with: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE>Client Identifier: <A href="http://music.example.com/" target="_blank">music.example.com</A> +Client Secret: 7F2986DF2342914A +</PRE></DIV> +<P>The Client has registered the Callback URL: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE><A href="https://music.example.com/auth_callback" target="_blank">https://music.example.com/<WBR>auth_callback</A> +</PRE></DIV> +<P>The Protected Resource and the Authorization Server have agreed to + use a Simple Web Token (SWT) for the Access Token with the reserved + attributes Issuer, Audience, ExpiresOn and the public attributes + com.example.auth.account, com.example.auth.client and + com.example.auth.scope. They have exchanged the following HMAC key + value (expressed in base 64): +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE>Zt9JlL1QvPYRSCK9PgSjrxRUBWe7lb<WBR>EYsZCdM+sJCF4= +</PRE></DIV> +<A name="0.2_anchor60"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.B.2"></A><H3>B.2. +Client Directs the User to the Server</H3> + +<P>Jane informs <A href="http://music.example.com/" target="_blank">music.example.com</A> that she would like her status at + <A href="http://status.example.com/" target="_blank">status.example.com</A> to be updated when a new song starts playing. The + <A href="http://music.example.com/" target="_blank">music.example.com</A> website maintains user sessions with a URL parameter + named session which has the value Vn3IG2FRALSEQX2Nxr at this time for + Jane. The Client will use wrap_client_state to maintain the session + value. The Client redirects Jane's browser to the Authorization + Server's User Authorization URL appending parameters for the Client + Identifier, Callback URL, Client state and authorization scope. +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE><A href="https://auth.example.com/user_authorization?wrap_client_id=music.example.com&wrap_callback=http%3A%2F%2Fmusic.example.com%2Fauth_callback&wrap_client_state=Vn3IG2FRALSEQX2Nxr&wrap_scope=status_update" target="_blank">https://auth.example.com/user_<WBR>authorization?wrap_client_id=<WBR>music.examp +le.com&wrap_callback=http%3A%<WBR>2F%2Fmusic.example.com%2Fauth_<WBR>callback&wr +ap_client_state=<WBR>Vn3IG2FRALSEQX2Nxr&wrap_scope=<WBR>status_update</A> +</PRE></DIV> +<A name="0.2_anchor61"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.B.3"></A><H3>B.3. +Authorization Server Confirms Delegation Request with User</H3> + +<P>The Authorization Server verifies the supplied Client Identifier + <A href="http://music.example.com/" target="_blank">music.example.com</A> has been registered and has the Callback URL + <A href="https://music.example.com/auth_callback" target="_blank">https://music.example.com/<WBR>auth_callback</A>. The Authorization Server + authenticates that the User it is dealing with is Jane, and then asks + Jane to authorize <A href="http://music.example.com/" target="_blank">music.example.com</A> to update Jane's status at + <A href="http://status.example.com/" target="_blank">status.example.com</A>. Jane approves the request and the Authorization + Server generates a Verification Code with the value 46YEXQjVit6T3nQ8, + stores it with the Client Identifier, Callback URl and the current + time. +</P> +<A name="0.2_anchor62"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.B.4"></A><H3>B.4. +Server Directs User back to the Client</H3> + +<P>The Server redirects Jane back to the Client's Callback URL with + the Verification Code and Client State appended: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE><A href="https://music.example.com/auth_callback?wrap_verification_code=46YEXQjVit6T3nQ8&wrap_client_state=Vn3IG2FRALSEQX2Nxr" target="_blank">https://music.example.com/<WBR>auth_callback?wrap_<WBR>verification_code=46YEXQj +Vit6T3nQ8&wrap_client_state=<WBR>Vn3IG2FRALSEQX2Nxr</A> +</PRE></DIV> +<A name="0.2_anchor63"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.B.5"></A><H3>B.5. +Client Requests Access Token</H3> + +<P>The Client makes an HTTPS POST request to: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE><A href="https://auth.example.com/access_token" target="_blank">https://auth.example.com/<WBR>access_token</A> +</PRE></DIV> +<P>With the following message body: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE>wrap_client_id=<A href="http://music.example.com/" target="_blank">music.example.<WBR>com</A>&wrap_client_secret=<WBR>7F2986DF2342914A&w +rap_verification_code=<WBR>46YEXQjVit6T3nQ8&wrap_<WBR>callback=http%3A%2F%2Fmusi +<A href="http://c.example.com/" target="_blank">c.example.com</A>%2Fauth_callback +</PRE></DIV> +<A name="0.2_anchor64"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.B.6"></A><H3>B.6. +Successful Access Token Response from Authorization Server</H3> + +<P>The Authorization Server verifies that the Verification Code is + still valid, has not been used, and is associated with the Client ID, + Client Secret and Callback URL Password. The Authorization Server then + generates a Refresh Token with the value: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE>MfdWTc+v9MXhpc+d/<WBR>csrKFMPfj1RySm6CzIjmTBGN6w= +</PRE></DIV> +<P>The Authorization Server notes the time is 2010-01-02T03:04:05Z, + which is 1262430245 seconds since 1970-01-01T0:0:0Z. The Authorization + Server then uses the values: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE>com.example.auth.scope: status_updatea +com.example.auth.account: Jane +com.example.auth.client: <A href="http://music.example.com/" target="_blank">music.example.com</A> +ExpiresOn: 1262433845 (1262430245 + 3600 seconds later) +Audience: <A href="http://status.example.com/" target="_blank">status.example.com</A> +Issuer: <A href="http://auth.example.com/" target="_blank">auth.example.com</A> +</PRE></DIV> +<P>and the agreed HMAC key to generate the following SWT: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE>com.example.auth.scope=status_<WBR>update&com.example.auth.<WBR>account=Jane&com +.example.auth.client=<A href="http://music.example.com/" target="_blank">music.<WBR>example.com</A>&ExpiresOn=<WBR>1262433845&Audience=s +<A href="http://tatus.example.com/" target="_blank">tatus.example.com</A>&Issuer=<A href="http://auth.example.com/" target="_blank">auth.<WBR>example.com</A>&HMACSHA256=<WBR>3xZAYzJRtYCQgkAF3 +iqElp1DhyKkPhq947j04NcDocQ%3D +</PRE></DIV> +<P>The Authorization Server then responds to the Clients HTTPS request + with: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE>HTTP 200 OK +</PRE></DIV> +<P>and the Refresh Token, Access Token and lifetime of the Access + Token as application/x-www-form-<WBR>urlencoded data in the body of the + message as such: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE>wrap_refresh_token=MfdWTc%<WBR>2Bv9MXhpc%2Bd%<WBR>2FcsrKFMPfj1RySm6CzIjmTBGN6w%3 +D&wrap_access_token=com.<WBR>example.auth.scope%3Dstatus_<WBR>update%26com.examp +le.auth.account%3DJane%26com.<WBR>example.auth.client%<A href="http://3dmusic.example.com/" target="_blank">3Dmusic.<WBR>example.com</A>%2 +6ExpiresOn%3D1262433845%<WBR>26Audience%<A href="http://3dstatus.example.com/" target="_blank">3Dstatus.example.<WBR>com</A>%26Issuer%3Daut +<A href="http://h.example.com/" target="_blank">h.example.com</A>%26HMACSHA256%<WBR>3D3xZAYzJRtYCQgkAF3iqElp1DhyKk<WBR>Phq947j04NcDo +cQ%253D&wrap_access_token_<WBR>expires_in=3600 +</PRE></DIV> +<P>The Client now has a Refresh Token and Access Token valid for an + hour. The Client stores the Refresh Token for later use. +</P> +<A name="0.2_anchor65"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.B.7"></A><H3>B.7. +Client Calls Protected Resource</H3> + +<P>A few minutes later, <A href="http://music.example.com/" target="_blank">music.example.com</A> starts playing a new song + for Jane. The Client updates Jane's status at <A href="http://status.example.com/" target="_blank">status.example.com</A> by + making an API call to: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE><A href="https://status.example.com/update" target="_blank">https://status.example.com/<WBR>update</A> +</PRE></DIV> +<P>including the following HTTP header: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE>Authorization: WRAP access_token="com.example.<WBR>auth.scope=status_update +&com.example.auth.account=<WBR>Jane&com.example.auth.client=<WBR>music.example.c +om&ExpiresOn=1262433845&<WBR>Audience=<A href="http://status.example.com/" target="_blank">status.example.com</A>&<WBR>Issuer=auth.exampl +<A href="http://e.com/" target="_blank">e.com</A>&HMACSHA256=<WBR>3xZAYzJRtYCQgkAF3iqElp1DhyKkPh<WBR>q947j04NcDocQ%3D" +</PRE></DIV> +<P>The Protected Resources verifies the SWT, confirms the + authorization contained in the SWT, and updates Jane's status. +</P> +<A name="0.2_anchor66"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<A name="0.2_rfc.section.B.8"></A><H3>B.8. +Client Refreshes Access Token</H3> + +<P>An hour passes by and <A href="http://music.example.com/" target="_blank">music.example.com</A> starts playing another new + song for Jane. The Client again makes an API call to + <A href="http://status.example.com/" target="_blank">status.example.com</A> including the same HTTP Authorization header. + Unlike previous calls where the status update was performed, the + Protected Resource returns the following error response: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE>HTTP 401 Unauthorized +</PRE></DIV> +<P>and the HTTP header: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE>WWW-Authenticate: WRAP +</PRE></DIV> +<P>The Client determines it probably needs a new Access Token, + retrieves the Refresh Token and makes an HTTPS POST to: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE><A href="https://auth.example.com/refresh_token" target="_blank">https://auth.example.com/<WBR>refresh_token</A> +</PRE></DIV> +<P>including the Client Identifier, Client Secret and Refresh Token in + the message body as: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE>wrap_client_id=<A href="http://music.example.com/" target="_blank">music.example.<WBR>com</A>&wrap_client_secret=<WBR>7F2986DF2342914A&w +rap_refresh_token=MfdWTc%<WBR>2Bv9MXhpc%2Bd%<WBR>2FcsrKFMPfj1RySm6CzIjmTBGN6w%<WBR>3D +</PRE></DIV> +<P>The Authorization Server looks up the data associated with the + Refresh Token, determines <A href="http://music.example.com/" target="_blank">music.example.com</A> is still authorized to + update Jane's status, and determines it will generate a new Access + Token for the Client that expires in an hour. The time is now + 2010-01-02T04:15:23Z, which results in an Access Token expiry time of + 1262438123 seconds since 1970-01-01T0:0:0Z. The Authorization Server + generates a new Access Token and returns it in the body of the message + as: +</P><DIV style="display:table;width:0;margin-left:3em;margin-right:auto"><PRE>wrap_access_token=com.example.<WBR>auth.scope=status_update&com.<WBR>example.aut +h.account=Jane&com.example.<WBR>auth.client=<A href="http://music.example.com/" target="_blank">music.example.com</A>&<WBR>ExpiresOn=126 +2438123&Audience=<A href="http://status.example.com/" target="_blank">status.<WBR>example.com</A>&Issuer=<A href="http://auth.example.com/" target="_blank">auth.<WBR>example.com</A>&HMACSHA256 +=<WBR>AT4TFChHgyylItEWAjK7MFRJuvUS3W<WBR>LVzO%2F68gvIRQI%3D&wrap_<WBR>access_token_ex +pires_in=3600 +</PRE></DIV> +<P>The Client takes the new Access Token and uses it to successfully + update Jane's status at <A href="http://status.example.com/" target="_blank">status.example.com</A>. +</P> +<A name="0.2_rfc.authors"></A><BR><HR> +<TABLE summary="layout" cellpadding="0" cellspacing="2" align="right"><TBODY><TR><TD><A href="https://mail.google.com/mail/?ui=2&ik=c5d0d94d4a&view=att&th=12634202598d2cea&attid=0.2&disp=inline&realattid=f_g4hjnq761&zw#0.2_toc"> TOC </A></TD></TR></TBODY></TABLE> +<H3>Authors' Addresses</H3> +<TABLE width="99%" border="0" cellpadding="0" cellspacing="0"> +<TBODY><TR><TD> </TD> +<TD>Dick Hardt (editor)</TD></TR> +<TR><TD> </TD> +<TD>Microsoft</TD></TR> +<TR><TD align="right">Email: </TD> +<TD><A href="mailto:dick.hardt@gmail.com" target="_blank">dick.hardt@gmail.com</A></TD></TR> +<TR cellpadding="3"><TD> </TD><TD> </TD></TR> +<TR><TD> </TD> +<TD>Allen Tom</TD></TR> +<TR><TD> </TD> +<TD>Yahoo!</TD></TR> +<TR><TD align="right">Email: </TD> +<TD><A href="mailto:atom@yahoo-inc.com" target="_blank">atom@yahoo-inc.com</A></TD></TR> +<TR cellpadding="3"><TD> </TD><TD> </TD></TR> +<TR><TD> </TD> +<TD>Brian Eaton</TD></TR> +<TR><TD> </TD> +<TD>Google</TD></TR> +<TR><TD align="right">Email: </TD> +<TD><A href="mailto:beaton@google.com" target="_blank">beaton@google.com</A></TD></TR> +<TR cellpadding="3"><TD> </TD><TD> </TD></TR> +<TR><TD> </TD> +<TD>Yaron Goland</TD></TR> +<TR><TD> </TD> +<TD>Microsoft</TD></TR> +<TR><TD align="right">Email: </TD> +<TD><A href="mailto:yarong@microsoft.com" target="_blank">yarong@microsoft.com</A></TD></TR> +</TBODY></TABLE> +</DIV> + +</BODY></HTML>
\ No newline at end of file |