Yeah, but there are serious security problems with credentials in the URL, is it really worth it in light of those problems?
________________________________ From: "Richer, Justin P." <jric...@mitre.org> To: Lukas Rosenstock <l...@lukasrosenstock.net>; William J. Mills <wmi...@yahoo-inc.com> Cc: Brian Eaton <bea...@google.com>; OAuth WG <oauth@ietf.org> Sent: Thursday, March 10, 2011 9:49 AM Subject: RE: [OAUTH-WG] OAuth Bearer Token draft Yes, there are many development setups where all you can reasonably access is the URL to get. It's also much simpler to make use of the well-supported syntax helpers for query parameters instead of relying on new, custom formatting for newly-defined headers. The bearer token makes this simple by just having the value of the token, but other schemes have their own name/value pair formats and encodings that will inevitably cause hiccups. -- Justin ________________________________________ From: Lukas Rosenstock [l...@lukasrosenstock.net] Sent: Thursday, March 10, 2011 11:49 AM To: William J. Mills Cc: Brian Eaton; Richer, Justin P.; OAuth WG Subject: Re: [OAUTH-WG] OAuth Bearer Token draft JSON-P (callback) works with <script> tags where no parameters can be set; this is used a lot in web applications that want to consume 3rd party APIs directly on the client side. So, yes, an alternative for the Authorization header is required - a.f.a.i.k this use case was one of the driving forces behind WRAP and bearer tokens. 2011/3/9 William J. Mills <wmi...@yahoo-inc.com<mailto:wmi...@yahoo-inc.com>> Is there really a need going forward for anything beyond using the Authorization header? Do we have clients out there that just can't set that header? Putting bearer tokens in query arguments is a very bad idea for many reasons, and in form variables has it's own set of badness (although not to the same level). -bill
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
