+1 for all updates<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 5, 2012 at 6:24 AM, George Fletcher <span dir="ltr"><<a href="mailto:gffletch@aol.com" target="_blank">gffletch@aol.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">I've updated issue #539
(offline_access and refresh_tokens) with the following proposed
resolution. This propose does not prescribe a strict behavior for
when (or when not) to issue refresh_tokens. However, it does
provide a solution for the 'offline_access' concept and should
support all the behaviors current in the Google implementation.<br>
<br>
Thanks,<br>
George<br>
<br>
Here is the URL to the issue:
<a href="https://bitbucket.org/openid/connect/issue/539/messages-0-add-scope-for-offline-access#comment-1630027" target="_blank">https://bitbucket.org/openid/connect/issue/539/messages-0-add-scope-for-offline-access#comment-1630027</a><br>
<br>
Here is the text of the update:<br>
<br>
</font>
<div>
<p>Updates to Messages draft:</p>
<p>2.1.2 add a new value for the scope list offline_access
OPTIONAL. This scope value requests that access to the user's
data / services be granted to the client even when the user is
not present (no active authentication session).</p>
<p>Updates to Standard draft:</p>
<p>2.3.1 add 'offline_access' to the list of scopes provided in
the description of the scope parameter</p>
<p>Description of offline_access behavior</p>
<p>If the client has requirements to access the user's
data/services when the user is not present (no active
authentication session), then the client must request
'offline_access' as one of the scope values and set the prompt
parameter to 'consent'. A user MUST always explicitly consent to
the return of an access token that contains the 'offline_access'
scope. A previously saved user consent is not sufficient to
grant the 'offline_access' scope.</p>
<p>At receipt of a scope parameter containing the 'offline_access'
value, the Authorization Server:</p>
<ul>
<li>MUST ensure that the prompt parameter contains 'consent'. If
the prompt parameter is does not contain 'consent' then ignore
the 'offline_access' request and and return a scope list to
the client that does NOT contain the 'offline_access' scope
(per the OAuth2 spec)
</li>
<li>MUST ignore the request for 'offline_access' if the client
is using the "Implicit Flow", and return a scope list to the
client that does NOT contain the 'offline_access' scope (per
the OAuth2 spec).
</li>
<li>MUST explicitly receive user consent for all clients where
the registered 'application_type' is set to 'web' [Discovery
section 2.1]
</li>
<li>SHOULD explicitly receive user consent for all clients where
the registered 'application_type' is set to 'native'
[Discovery section 2.1]
</li>
</ul>
<p>Offline access is granted to the client in the form of a
refresh_token that enables the client to request new
access_tokens even when the user does not have an active
authentication session as per the OAuth2 spec. The use of
refresh_tokens is not exclusive to the 'offline_access' use case
and the Authorization Service MAY grant refresh_tokens in other
contexts as well.</p>
<p>My rationale for this approach:</p>
<ol>
<li>No need to add "auto" and "force" to the prompt parameter as
prompt already has an allowed value of 'consent' which should
suffice for the 'force' option. I believe 'auto' should be the
default and not explicitly requested.
</li>
<li>Add 'offline_access' to the scope list as this is also
needed for pure OAuth2 use cases and most authorization
servers implementing OpenID Connect will also want to support
this use case for OAuth2 as well.
</li>
<li>Does not prescribe a strict behavior on when refresh_tokens
are issued. This allows the AS to determine if it wants to
issue refresh_tokens in the online use case as well as the
offline use case.
</li>
<li>Explicit user consent is a SHOULD because there are some
native client use cases where it's not necessary. For example,
a client created by the same company as the AS which the user
must download and install into the device. In this case, the
user has given "consent" by downloading and installing the
application. Requesting explicit user consent in this case is
not necessary. The AS is responsible for ensuring that only
those clients that meet the security requirements are enabled
for this behavior.
</li><span class="HOEnZb"><font color="#888888">
</font></span></ol><span class="HOEnZb"><font color="#888888">
</font></span></div><span class="HOEnZb"><font color="#888888">
<br>
<pre cols="72">--
Chief Architect AIM: gffletch
Identity Services Engineering Work: <a href="mailto:george.fletcher@teamaol.com" target="_blank">george.fletcher@teamaol.com</a>
AOL Inc. Home: <a href="mailto:gffletch@aol.com" target="_blank">gffletch@aol.com</a>
Mobile: <a href="tel:%2B1-703-462-3494" value="+17034623494" target="_blank">+1-703-462-3494</a> Blog: <a href="http://practicalid.blogspot.com" target="_blank">http://practicalid.blogspot.com</a>
Office: <a href="tel:%2B1-703-265-2544" value="+17032652544" target="_blank">+1-703-265-2544</a> Twitter: <a href="http://twitter.com/gffletch" target="_blank">http://twitter.com/gffletch</a>
</pre>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>--Breno<br>
</div>