On Fri, Jul 16, 2010 at 9:13 AM, William Mills <wmi...@yahoo-inc.com> wrote: > 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?
I think so. I don't think we have to decide if silent upgrade should always be used or not, just that it is a valid option. Marius > >> -----Original Message----- >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@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<rricha...@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<sdro...@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 >> > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
