[Openid-specs-ab] Offline access discussion

[George Fletcher]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120522/3563ddd8/attachment.html>