Re: [OAUTH-WG] Versioning

[Marius Scurtescu <[e-mail]>]

On Fri, Jul 16, 2010 at 9:13 AM, William Mills <[e-mail]> 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: [e-mail] [mailto:[e-mail]]
>> On Behalf Of Rob Richards
>> Sent: Friday, July 16, 2010 2:34 AM
>> To: Marius Scurtescu
>> Cc: [e-mail]
>> 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<[e-mail]>  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<[e-mail]>  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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>