<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body 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 class="moz-txt-link-freetext" href="https://bitbucket.org/openid/connect/issue/539/messages-0-add-scope-for-offline-access#comment-1630027">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>
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    <div class="issues-comment edit-comment sane-defaults
      sane-defaults-2" id="1630027">
      <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>
      </ol>
    </div>
    <br>
    <pre class="moz-signature" cols="72">-- 
Chief Architect                   AIM:  gffletch
Identity Services Engineering     Work: <a class="moz-txt-link-abbreviated" href="mailto:george.fletcher@teamaol.com">george.fletcher@teamaol.com</a>
AOL Inc.                          Home: <a class="moz-txt-link-abbreviated" href="mailto:gffletch@aol.com">gffletch@aol.com</a>
Mobile: +1-703-462-3494           Blog: <a class="moz-txt-link-freetext" href="http://practicalid.blogspot.com">http://practicalid.blogspot.com</a>
Office: +1-703-265-2544           Twitter: <a class="moz-txt-link-freetext" href="http://twitter.com/gffletch">http://twitter.com/gffletch</a>
</pre>
  </body>
</html>