: Mike Jones; oauth-boun...@ietf.org; OAuth WG
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
+1
Phil
phil.h...@oracle.com<mailto:phil.h...@oracle.com>
On 2011-03-21, at 8:50 AM, George Fletcher wrote:
+1
On 3/11/11 2:56 AM, tors...@lodderstedt.net<mailto:tors...@lodderstedt.net>
regards,
>> Torsten.
>> Gesendet mit BlackBerry® Webmail von Telekom Deutschland
>>
>> -Original Message-
>> From: Mike Jones
>> Sender: oauth-boun...@ietf.org
>> Date: Fri, 11 Mar 2011 01:54:00
>> To: OAuth WG
>> Subject: Re: [OAUTH-WG
f.org
Date: Fri, 11 Mar 2011 01:54:00
To: OAuth WG
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAut
t]
Sent: Friday, March 11, 2011 3:01 AM
To: Phil Hunt
Cc: Richer, Justin P.; OAuth WG
Subject: AW: Re: [OAUTH-WG] OAuth Bearer Token draft
To scope a refresh token is good practice (IMHO).
I agree with wrt URI query parameters. This should be used carefully and only
if no other option exists.
R
RE: [OAUTH-WG] OAuth Bearer Token draft
Justin Richer said: "Since all formats are optional,..."
No they aren't.
draft-ietf-oauth-v2-bearer-03 says
"Resource servers MUST accept [the Authorization header], and MAY support [body
& qu
-WG] OAuth Bearer Token draft
Gesendet: 10. Mrz. 2011 23:31
In theory yes, sometimes a token has limited scope. But since a token will
often have unlimited scope, it carries the same potential for risk.
I would say one-time use tokens (e.g. grant codes) are really the only things
that should be
ubject: Re: [OAUTH-WG] OAuth Bearer Token draft
___
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
Justin Richer said: "Since all formats are optional,..."
No they aren't.
draft-ietf-oauth-v2-bearer-03 says
"Resource servers MUST accept [the Authorization header], and MAY support [body
& query parameters]"
--
James Manger
___
OAuth mailing list
OAu
: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
George Fletcher
Sent: Thursday, March 10, 2011 4:28 PM
To: Phil Hunt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
I'm not crazy about the compromise either, but it's not possible for a site
using JSON
...@oracle.com]
Sent: Thursday, March 10, 2011 2:01 PM
To: Richer, Justin P.
Cc: Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
Well, for one if you promote this, it becomes general technique. Now you have
uid/passwords in browser history etc potentially accessible to j
and password -- we're talking about tokens here. The cost
>>> of a leaked temporary token (even a straight bearer token) is much, much
>>> lower.
>>>
>>> -- Justin
>>> ________________
>>> From: Phil Hunt [phil.h...@or
r, Justin P.
Cc: Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
Well, for one if you promote this, it becomes general technique. Now you have
uid/passwords in browser history etc potentially accessible to javascript and
could be leaked/hacked in any number of ways.
Al
To: Richer, Justin P.; Phil Hunt
Cc: Lukas Rosenstock; OAuth WG
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
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.
___
t SSL; a very bad idea, but
conforms to most of the spec (PLAIN now says you must use SSL).
From: "Richer, Justin P."
To: Phil Hunt
Cc: OAuth WG
Sent: Thursday, March 10, 2011 11:18 AM
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
Nobody said U
: Lukas Rosenstock; OAuth WG
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
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."
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&
lower.
>
> -- Justin
>
> From: Phil Hunt [phil.h...@oracle.com]
> Sent: Thursday, March 10, 2011 2:01 PM
> To: Richer, Justin P.
> Cc: Eran Hammer-Lahav; OAuth WG
> Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
>
> Well, for one if you promote this, it becomes general
icher, Justin P.
Cc: Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
Well, for one if you promote this, it becomes general technique. Now you have
uid/passwords in browser history etc potentially accessible to javascript and
could be leaked/hacked in any number of
ate it from the spec and
never speak of this again.
-- Justin
From: Eran Hammer-Lahav [e...@hueniverse.com]
Sent: Thursday, March 10, 2011 1:29 PM
To: Phil Hunt; Richer, Justin P.
Cc: OAuth WG
Subject: RE: [OAUTH-WG] OAuth Bearer Token draft
There are
_
> From: Eran Hammer-Lahav [e...@hueniverse.com]
> Sent: Thursday, March 10, 2011 1:29 PM
> To: Phil Hunt; Richer, Justin P.
> Cc: OAuth WG
> Subject: RE: [OAUTH-WG] OAuth Bearer Token draft
>
> There are a few issues to consider.
>
> 1. Should the spec support send
; Richer, Justin P.
Cc: OAuth WG
Subject: RE: [OAUTH-WG] OAuth Bearer Token draft
There are a few issues to consider.
1. Should the spec support sending bearer token in a query parameter?
- The argument that there are many use cases for this is unproven. JSON-P is
one valid example (though JSON-P
;s very important to strike an appropriate balance.
-- Justin
From: Phil Hunt [phil.h...@oracle.com]
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.
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
; 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?
>
> ___
mi...@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 i
11 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 format
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
JSON-P (callback) works with
though not to the
same level).
-bill
From: Brian Eaton
To: "Richer, Justin P."
Cc: Eran Hammer-Lahav ; William J. Mills
; OAuth WG
Sent: Tuesday, March 8, 2011 6:25 PM
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
This has been proven true
many
>> people.
>>
>> -- justin
>>
>> From: Eran Hammer-Lahav [e...@hueniverse.com]
>> Sent: Tuesday, March 08, 2011 7:08 PM
>> To: Richer, Justin P.; William J. Mills
>> Cc: OAuth WG
>> Subject: Re: [OAUTH
ahav [e...@hueniverse.com]
> Sent: Tuesday, March 08, 2011 7:08 PM
> To: Richer, Justin P.; William J. Mills
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
>
> No.
>
> There is a huge difference between adding parameters to protected
> resources and de
tin
>
>From: Eran Hammer-Lahav [e...@hueniverse.com]
>Sent: Tuesday, March 08, 2011 1:02 PM
>To: William J. Mills; Richer, Justin P.
>Cc: OAuth WG
>Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
>
>I hope this will be the last time we
_
>From: Eran Hammer-Lahav [e...@hueniverse.com]
>Sent: Tuesday, March 08, 2011 1:02 PM
>To: William J. Mills; Richer, Justin P.
>Cc: OAuth WG
>Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
>
>I hope this will be the last time we define a query parameter fo
Richer, Justin P.
Cc: OAuth WG
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
I hope this will be the last time we define a query parameter for delivering
what should be sent via a request header field. Infringing on a service's
namespace is always a bad idea, no matter what prefix we
t;
Cc: OAuth WG mailto:oauth@ietf.org>>
Sent: Tuesday, March 8, 2011 10:02 AM
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
I hope this will be the last time we define a query parameter for delivering
what should be sent via a request header field. Infringing on a service's
name
Then a single extra reservation is preferable to N, yes?
From: Eran Hammer-Lahav
To: William J. Mills ; Justin Richer
Cc: OAuth WG
Sent: Tuesday, March 8, 2011 10:02 AM
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
I hope this will be the last time we define a query parameter for
.com>>
Reply-To: "William J. Mills" mailto:wmi...@yahoo-inc.com>>
Date: Tue, 8 Mar 2011 10:11:46 -0700
To: Justin Richer mailto:jric...@mitre.org>>
Cc: OAuth WG mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
So is a different namespace for ea
> So is a different namespace for each new mechanism right, or should a
> parameter be added to parallel the authorization scheme name? Seems like it
> would be clean to define oauth_scheme and use the same value as defined for
> the auth scheme name.
I'd much rather do it this way. There is val
Richer
To: William J. Mills
Cc: Brian Eaton ; OAuth WG
Sent: Tuesday, March 8, 2011 8:41 AM
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
I don't understand this comment. If you're using query/form parameters,
there are no schemes involved in the process.
-- Justin
On Tue, 2011-0
8, 2011 8:41 AM
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
I don't understand this comment. If you're using query/form parameters,
there are no schemes involved in the process.
-- Justin
On Tue, 2011-03-08 at 11:27 -0500, William J. Mills wrote:
> A major difference is now
__
> From: Justin Richer
> To: Brian Eaton
> Cc: OAuth WG
> Sent: Tuesday, March 8, 2011 7:11 AM
> Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
>
> Very strongly agree, repeat my suggestion to name the parameter
> "oauth2_token".
>
>
oblem.
From: Justin Richer
To: Brian Eaton
Cc: OAuth WG
Sent: Tuesday, March 8, 2011 7:11 AM
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
Very strongly agree, repeat my suggestion to name the parameter
"oauth2_token".
-- Justin
On Fri, 2011-02-25 at 14:49 -0500, Br
Very strongly agree, repeat my suggestion to name the parameter
"oauth2_token".
-- Justin
On Fri, 2011-02-25 at 14:49 -0500, Brian Eaton wrote:
> My two cents:
>
> We've already taken three user visible outages because the OAuth2 spec
> reused the "oauth_token" parameter in a way that was not c
oauth@ietf.org
> Subject: RE: [OAUTH-WG] OAuth bearer token draft ready for working group
> last call
>
> I personally think the error code registry is a good idea, and the resourse
> parameter registry is a very very bad idea. I also didn't see anything
> approaching consensus on
f.org [oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav [e...@hueniverse.com]
Sent: Monday, February 28, 2011 4:13 PM
To: Mike Jones; Hannes Tschofenig; Blaine Cook
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth bearer token draft ready for working group last
call
I am opposed to all th
osoft.com]
Sent: Monday, February 28, 2011 1:34 PM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: RE: [OAUTH-WG] OAuth bearer token draft ready for working group last
call
I realize that we disagree. Unless you change your position, it seems that the
working group will need to decide whether re
anism for extending error codes ]".)
-- Mike
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Monday, February 28, 2011 1:27 PM
To: Mike Jones
Cc: oauth@ietf.org
Subject: RE: [OAUTH-WG] OAuth bearer token draft ready f
e use cases, requirements, and examples for each of your new
proposals?
---
Did I miss a reply?
EHL
From: Mike Jones [mailto:michael.jo...@microsoft.com]
Sent: Monday, February 28, 2011 1:25 PM
To: Eran Hammer-Lahav; Hannes Tschofenig; Blaine Cook
Cc: oauth@ietf.org
Subject: RE: [OAUTH-WG] OAut
-boun...@ietf.org] On Behalf Of Mike
Jones
Sent: Monday, February 28, 2011 12:51 PM
To: Hannes Tschofenig; Blaine Cook
Cc: oauth@ietf.org
Subject: [OAUTH-WG] OAuth bearer token draft ready for working group last call
As editor, having received no comments on the normative content of
draft-ietf
: Monday, February 28, 2011 12:51 PM
To: Hannes Tschofenig; Blaine Cook
Cc: oauth@ietf.org
Subject: [OAUTH-WG] OAuth bearer token draft ready for working group last call
As editor, having received no comments on the normative content of
draft-ietf-oauth-v2-bearer-03, and having made no breaking
As editor, having received no comments on the normative content of
draft-ietf-oauth-v2-bearer-03, and having made no breaking changes since draft
-01, other than one change voted upon by the working group, I believe that
draft-ietf-oauth-v2-bearer-03 is ready for working group last call.
I'll n
I agree with your point of view.
Consequentely, the parameter name should be something like "bearer_token"?
regards,
Torsten.
Am 25.02.2011 20:49, schrieb Brian Eaton:
My two cents:
We've already taken three user visible outages because the OAuth2 spec
reused the "oauth_token" parameter in a
> -Original Message-
> From: Brian Eaton [mailto:bea...@google.com]
> Sent: Friday, February 25, 2011 3:26 PM
> To: Eran Hammer-Lahav
> Cc: Phil Hunt; Mike Jones; OAuth WG
> Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
>
> On Fri, Feb 25, 2011 at 3:03 PM, Er
On Fri, Feb 25, 2011 at 3:03 PM, Eran Hammer-Lahav wrote:
> ‘oauth_token’ is limited to bearer tokens only. It is not suitable for
> anything else.
Except that OAuth 1.0 already went out using oauth_token for signed requests.
___
OAuth mailing list
OAut
.@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Phil
Hunt
Sent: Friday, February 25, 2011 2:41 PM
To: Mike Jones
Cc: OAuth WG
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
Mike,
Thanks, I just noticed you addressed the change to "BEARER" in draft 03 (just
published).
I could live wit
at specification time,
> rather than at spec usage time.
>
> Best wishes,
> -- Mike
>
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
> Phil Hunt
> Sent: Friday, Februar
rom: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Phil
Hunt
Sent: Friday, February 25, 2011 11:38 AM
To: OAuth WG
Subject: [OAUTH-WG] OAuth Bearer Token draft
There was some discussion on the type for the authorization header being OAUTH
/ MAC / BEARER etc. Did we have a resol
My two cents:
We've already taken three user visible outages because the OAuth2 spec
reused the "oauth_token" parameter in a way that was not compatible
with the OAuth1 spec.
Luckily they were all caught before they caused serious damage.
Generic parameter names are not useful. They lead to con
There was some discussion on the type for the authorization header being OAUTH
/ MAC / BEARER etc. Did we have a resolution?
As for section 2.2 and 2.3, should we not have a more neutral solution as well
and use "authorization_token" instead of oauth_token. The idea is that the
parameter corres
59 matches
Mail list logo
