Already in -10. EHL
On Jul 14, 2010, at 14:46, 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. > > 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. More work that they don't need to deal > with so why would they. I can envision a SP providing support for both > 1.0 and 2.0 with an end of life to 1.0 support. This will give the > client developers enough time to migrate and distribute their client/apps. > > As far as the version determination on the endpoint, this is really just > a paragraph of text and seems a bit overkill to put into its own > proposal when it could easily be handled even as an appendix in the core > 2.0 spec. > > 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
