Outside of what happens based on the newly refreshed conversation
about this, currently this point should be moved to 5.1 rather than
5.1.1 as its not specific to the Authorization header.
Rob
On 7/14/10 6:15 PM, Eran Hammer-Lahav wrote:
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
