[Openid-specs-ab] Offline access discussion

Breno de Medeiros breno at google.com
Tue May 22 19:40:28 UTC 2012


I think George's assessment of pro's and cons are accurate. If we use new
parameters instead of scopes  we can register them so they ate available
for OAuth2 as well.
On May 22, 2012 12:27 PM, "Nat Sakimura" <sakimura at gmail.com> wrote:

> Thanks George.
>
> Breno, could I hear your opinion?
>
> =nat
>
> On Wed, May 23, 2012 at 4:23 AM, George Fletcher <
> george.fletcher at teamaol.com> wrote:
>
>>  A few comments...
>>
>> 1. You are correct that AOL's implementation requires server side session
>> state. This could be an issue for some IdP implementations.
>>
>> 2. Refreshing tokens via the browser (front-channel) ensures that the
>> browser is still present. This is useful for the case where the user just
>> closes their browser. Any associated RPs will not be able to retrieve an
>> updated access token because there will be no browser present via which to
>> do the "refresh".
>>
>> 3. Given that AOL wants to support the offline_access concept for native
>> OAuth2 authorizations as well and OpenID Connect, I think this needs to
>> stay part of the scope. It seems strange that if a developer is using
>> OpenID Connect they pass the offline_access value in one parameter but then
>> use a different parameter if doing OAuth2.
>>
>> 4. Proxying via the front-channel is somewhat more complex than a simple
>> back channel call be between the RP and the central IdP. At a minimum front
>> channel requires a js library to manage polling of the shared "IdP" to
>> maintain fresh tokens, or to refresh a token. Most likely, this is a code
>> flow which will force the RP to still do a back channel call to actually
>> retrieve the token.
>>
>> Thanks,
>> George
>>
>> On 5/22/12 3:00 PM, Nat Sakimura wrote:
>>
>> In the Yahoo! meeting, we had some discussions around offline access. The
>> discussion did not finish there and we did not have much time to discuss in
>> the IIW to reach the consensus either.
>>
>>  From what I see from the notes in the issue tracker (
>> https://bitbucket.org/openid/connect/issue/539/ ), the following is my
>> take:
>>
>>   So Google and AOL approach does not seem too dissimilar.
>>
>> Both requires explicit user consent for obtaining the refresh token.
>>
>> Differences:
>>
>>    1. In AOL's case, refresh token which is bound to the session is
>>    returned for 'code' case, while Google does not return it. In AOL's case,
>>    the client should send refresh token through the back channel to update the
>>    access token, while in Google's case, prompt=none front channel call should
>>    be used to get the refreshed access token.
>>       1. Advantage of AOL's approach is that it allows simpler
>>       implementation for the proxied clients (e.g., MapQuest-AOL-Google case).
>>       2. Google states that their approach allows "unified button" for
>>       new registration and authentication. (Is this also achievable with AOL's
>>       methodology?)
>>       3. Perhaps Googles approach allows the server to be stateless
>>       while AOL's approach requires it to be stateful?
>>     2. AOL uses scope to indicate the offline access request, while
>>    Google uses a new extension parameter called access_type.
>>       1. AOL's approach is one less extension variable while Google's
>>       approach probably is cleaner than putting everything in the scope bucket.
>>
>>  I do not think we have consensus on this issue yet. Please discuss.
>>
>>  --
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>>
>>
>>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120522/4dfb7244/attachment.html>


More information about the Openid-specs-ab mailing list