-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Phil Hunt
Sent: Thursday, March 10, 2011 10:15 AM
To: Richer, Justin P.
Cc: OAuth WG
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
-1. It is a BAD security practice to pass credentials in URLs. Avoid it.
Phil
phil.h...@oracle.com
On 2011-03-10, at 10:07 AM, Richer, Justin P. wrote:
Ah, here we run into the classic argument of usability vs. security, in which
usability will win every single time in practice. If we don't define at least a
reasonable way to do this within the scope of OAuth, that's not going to stop
people from doing it. It's just going to make people do it in a million
different
ways, each with their own unique problems that nobody's thought of. At
least this way, we can enable it and have a real discussion about the security
considerations. There are valid and valuable places where putting credentials
in the URL is a reasonable security tradeoff. Not everything functions over
the public internet as well, and the security considerations are different in
these other environments.
In short: yes, it's necessary and good to do this.
-- Justin
________________________________________
From: William J. Mills [wmi...@yahoo-inc.com]
Sent: Thursday, March 10, 2011 12:59 PM
To: Richer, Justin P.; Lukas Rosenstock
Cc: Brian Eaton; OAuth WG
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
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<mailto: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:wmills@yahoo-
inc.com><mailto: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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth