[Openid-specs-ab] Updated issue #539 with proposed text

[George Fletcher]

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.

Thanks,
George

Here is the URL to the issue: 
https://bitbucket.org/openid/connect/issue/539/messages-0-add-scope-for-offline-access#comment-1630027

Here is the text of the update:

Updates to Messages draft:

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).

Updates to Standard draft:

2.3.1 add 'offline_access' to the list of scopes provided in the 
description of the scope parameter

Description of offline_access behavior

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.

At receipt of a scope parameter containing the 'offline_access' value, 
the Authorization Server:

  * 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)
  * 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).
  * MUST explicitly receive user consent for all clients where the
    registered 'application_type' is set to 'web' [Discovery section 2.1]
  * SHOULD explicitly receive user consent for all clients where the
    registered 'application_type' is set to 'native' [Discovery section
    2.1]

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.

My rationale for this approach:

 1. 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.
 2. 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.
 3. 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.
 4. 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.


-- 
Chief Architect                   AIM:  gffletch
Identity Services Engineering     Work: george.fletcher at teamaol.com
AOL Inc.                          Home: gffletch at aol.com
Mobile: +1-703-462-3494           Blog: http://practicalid.blogspot.com
Office: +1-703-265-2544           Twitter: http://twitter.com/gffletch

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120705/9de94f03/attachment.html>