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
