Given that OAuth discovery hasn't been written yet, how would an OAuth 1.0 client know about a 2.0 protected resource in the first place?
On Thu, Jul 15, 2010 at 11:33 AM, John Kemp <j...@jkemp.net> wrote: > On Jul 15, 2010, at 9:07 AM, Eran Hammer-Lahav wrote: > > > I would like people to raise their hand and explain how this will break > actual 1.0 deployments. > > What happens if a 1.0 client receives a WWW-Authenticate header from a 2.0 > protected resource with the 'OAuth' mechanism specified? Might it then > attempt OAuth 1 with a 2.0 token service (and thus just fail without being > able to know what went wrong)? > > - johnk > > > > > EHL > > > > > > > > On Jul 15, 2010, at 1:38, Brian Eaton <bea...@google.com> wrote: > > > >> Draft 10 switched from "Token" scheme in the authorization header to > >> "OAuth". I'd rather we didn't reuse OAuth. 'OAuth2' would be great. > >> "Token" is ugly as sin, but is better than "OAuth". > >> > >> Spec section: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#page-30 > >> > >> The problem with reusing "OAuth" is that there are existing > >> implementations in the wild that have special behavior implemented for > >> OAuth authorization headers. Since OAuth2 headers don't have the same > >> semantics, we're going to break those implementations. We shouldn't > >> reuse "OAuth" for the same reasons we shouldn't reuse "Negotiate", > >> "NTLM", "Digest", or "Basic. > >> > >> Cheers, > >> Brian > >> _______________________________________________ > >> 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 > > _______________________________________________ > 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