Subject: Re: [OAUTH-WG] OAuth Bearer Token draft

From: "William J. Mills" <[email-masked]>
Date: Thu, 10 Mar 2011 11:37:10 -0800 (PST)

If people are doign a one-poff internal solution they can do whatever they want, that doesn't mean it shoudl be part of a security related standard.

________________________________
From: "Richer, Justin P." <[email-masked]>
To: Phil Hunt <[email-masked]>
Cc: William J. Mills <[email-masked]>; Lukas Rosenstock <[email-masked]>; OAuth WG <[email-masked]>
Sent: Thursday, March 10, 2011 10:30 AM
Subject: RE: [OAUTH-WG] OAuth Bearer Token draft

What about temporary credentials across a local link between controlled systems? My point is just that there are cases where the usual leakage culprits (browsers, proxies, caches, logs) don't apply. 

It's also a bad idea to not use two-way TLS, and it's arguably a bad idea to look at anything on the web without using TLS to begin with, but we still do. It's all about the tradeoff between security of a system and the usability and usefulness of a system. There's an old adage that the most secure computer is powered off and unplugged. :)

I think it's very important to strike an appropriate balance.

-- Justin
________________________________________
From: Phil Hunt [[email-masked]]
Sent: Thursday, March 10, 2011 1:15 PM
To: Richer, Justin P.
Cc: William J. Mills; Lukas Rosenstock; 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
[email-masked]

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 [[email-masked]]
> 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." <[email-masked]>
> To: Lukas Rosenstock <[email-masked]>; William J. Mills <[email-masked]>
> Cc: Brian Eaton <[email-masked]>; OAuth WG <[email-masked]>
> 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 [[email-masked]<mailto:[email-masked]>]
> 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 <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 10 Mar 2011 14:41:12 -0500

The entire purpose of a standard is to codify the one-off solutions out there into best practices in different contexts.

 -- Justin
________________________________________
From: William J. Mills [[email-masked]]
Sent: Thursday, March 10, 2011 2:37 PM
To: Richer, Justin P.; Phil Hunt
Cc: Lukas Rosenstock; OAuth WG
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft

-- Justin
From: Phil Hunt [[email-masked]<mailto:[email-masked]>]

Phil
[email-masked]<mailto:[email-masked]>

On 2011-03-10, at 10:07 AM, Richer, Justin P. wrote:

> From: William J. Mills [[email-masked]<mailto:[email-masked]>]
> From: "Richer, Justin P." <[email-masked]<mailto:[email-masked]>>
> To: Lukas Rosenstock <[email-masked]<mailto:[email-masked]>>; William J. Mills <[email-masked]<mailto:[email-masked]>>
> Cc: Brian Eaton <[email-masked]<mailto:[email-masked]>>; OAuth WG <[email-masked]<mailto:[email-masked]>>
> From: Lukas Rosenstock [[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>]
> 2011/3/9 William J. Mills <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>><mailto:[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>>
> [email-masked]<mailto:[email-masked]>