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

[Breno de Medeiros]

+1 for all updates


On Thu, Jul 5, 2012 at 6:24 AM, George Fletcher <gffletch at aol.com> wrote:

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


-- 
--Breno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120706/66f36214/attachment.html>