Re: [OAUTH-WG] Versioning

For token migration from Oauth 1 to 2 are we ever really going to need
to do that silently for a user in a client?  It's reasonable when the
user gets a new client install that supports a new protocol for them to
have to re-authenticate.  Where I see this happening is in a big server
migration where you're integrating with somone like Google IMAP and you
already have a huge store of tokens for IMAP and you want yo convert to
Oauth 2 but you don't want to prompt all your users.

Do I have this right? 

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] 
> On Behalf Of Rob Richards
> Sent: Friday, July 16, 2010 2:34 AM
> To: Marius Scurtescu
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Versioning
> 
> 
>   On 7/14/10 6:33 PM, Marius Scurtescu wrote:
> > On Wed, Jul 14, 2010 at 11:46 AM, Rob 
> Richards<rrichards@cdatazone.org>  wrote:
> >> Finally getting a chance to catchup and respond to this thread.
> >>
> >> Marius Scurtescu wrote:
> >>> See comments bellow...
> >>>
> >>>
> >>> On Fri, Jul 9, 2010 at 4:27 AM, Stefanie 
> Dronia<sDronia@gmx.de>  wrote:
> >>>
> >>>> Hallo Marius,
> >>>>
> >>>> thanks for your statement.
> >>>> Your idea of a migration flow is quite good and necessary.
> >>>>
> >>>> But I still doubt, if the work and effort should be 
> investigated to 
> >>>> spare the user from some interaction (authentication and 
> user consent).
> >>>>
> >>> It all depends for how many users does the client have 
> OAuth 1 tokens.
> >>> Asking users to re-approve will confuse them and I guess 
> many will 
> >>> not do it,
> >>>
> >> I think the user should not be excluded from this interaction and 
> >> should be required to re-approve. IMO they should be 
> involved as its 
> >> also informational to know that the client they have previously 
> >> authorized is now requesting new credentials under a different 
> >> security scheme. The user should be the one to decide 
> whether or not they want to allow this.
> > Why would you re-prompt the user? The only thing that 
> really changes 
> > is the underlying protocol, something most end users are not made 
> > aware of. How would the new approval page be any different from the 
> > initial one? The user granted a client access to some of its 
> > resources, that stays the same. If the authorization server 
> makes it 
> > explicit on the approval page that OAuth 1 is used, then yes, a 
> > re-approval is needed, but I don't think this normally happens.
> >
> >
> >> When it comes right down to it the only concrete thing I 
> can think of 
> >> when migrating from 1.0 to 2.0 is the need to determine 
> which version 
> >> is being used at the resource endpoint. For most clients 
> moving from 
> >> 1.0 to 2.0 they will most likely just create the next version of 
> >> their client/app with 2.0 support and completely drop 1.0 support 
> >> rather than going through any migration flow.
> > That depends on the client. If the client is a web site that has 
> > several thousand users, and it stores OAuth 1 access tokens for all 
> > these users, then migration totally makes sense. If the 
> client is an 
> > iPhone app with only one user, then maybe you are right. 
> Even in this 
> > case, I am sure the app would prefer not to annoy the user and just 
> > silently move to OAuth 2. If you are the app developer and your app 
> > has a large install base, would you risk losing even a small 
> > percentage of those users simply because you presented them with a 
> > confusing approval page?
> >
> >
> >
> As a user I would say yes, I want to be re-prompted or at 
> least explicitly request the migration of my tokens rather 
> than having something done silently, behind the scenes and 
> unbeknownst to me. The underlying protocol has changed, 
> whether or not I know it, and for all purposes could be the 
> most insure protocol out there. When something this 
> fundamental changes, I would want to have to re-authorize the 
> application because I could just as easily at this point decline. 
> Perhaps I went and read the changelog, the change was made 
> known on the site, or someone discovered the change and made 
> it public. As you can probably tell I lean way more towards 
> the side of the user and personally think it is more 
> responsible of the app or web site in question here to 
> require the re-authorization and risk losing some users (if 
> that is the case then clearly the application is not worth 
> the users time in the first place) than to silently change 
> the protocol on me.
> 
> Rob
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 