Also, there's a big difference between "can keep secrets" and "can be
packed/shipped with secrets". Many native apps fit into the former
category but not the latter, which makes storage of refresh tokens and
other long-term credentials reasonable, but not server-issued client
secrets.
-- Justin
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
A major difference is now there is a scheme name that is differentiating. You
no longer have to parse the entire variable set to figure out what is going
on. Now the scheme name determines things. Now that we have schemes I don't
see re-using parameter names as a problem.
_
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 there is a scheme name that is
> differentiating. You no longer have to parse t
That's because I'm focused on my use case, which is using the Authorization
header. In query args/form parameters we definitely need better
differentiation.
From: Justin Richer
To: William J. Mills
Cc: Brian Eaton ; OAuth WG
Sent: Tuesday, March 8, 2011 8:4
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.
From: Justin Ri
> 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
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 put next to it.
EHL
From: "William J. Mills" mailto:wmi...@yahoo-inc.com>>
Reply-To: "W
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 deliver
If there was an actual reason to think more of these will be needed.
The only attractive feature of bearer tokens are their simplicity. There can be
nothing simpler. And as such, sending them over in a query parameter has
obvious benefits inline with this simplicity (with the well-known security
To clarify, when I say "can keep secrets" I mean "can be packed/shipped with
secrets." Good point.
I assume all OAuth clients can keep secrets in the more general sense you
implied. Otherwise, even bearer tokens would be useless.
On Mar 8, 2011, at 6:26 AM, Justin Richer wrote:
> Also, there
Your 2.0 home page http://oauth.net/2/ has a typo: "is can"
The latest version of the spec is can be found at:
-Doug
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
In my opinion the protocol has serious problems.
The authorization code is a credential that provides access to
protected resources via the client, as well as user authentication
when OAuth is used for social login. If an attacker observes or
intercepts the authorization code, the attacker can pr
Except that we're also infringing on service provider namespaces for our other
endpoints as well. Not every service provider can or will create a pristine
endpoint for tokens or authorizations, but this working group has had no
problems putting all kinds of parameters into that space. Unless we
No.
There is a huge difference between adding parameters to protected
resources and defining parameter for OAuth specific endpoints (which may
create conflicts with existing frameworks).
One is an invasion of the provider's namespace where OAuth has no business
messing around. The other is a pote
I simply don't agree that there's much difference in practice for 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-WG] OAuth
This has been proven true in our deployment as well.
On Tue, Mar 8, 2011 at 4:16 PM, Richer, Justin P. wrote:
> I simply don't agree that there's much difference in practice for many people.
>
> -- justin
>
> From: Eran Hammer-Lahav [e...@hueniverse.com]
What exactly?
On Mar 8, 2011, at 18:25, "Brian Eaton" wrote:
> This has been proven true in our deployment as well.
>
> On Tue, Mar 8, 2011 at 4:16 PM, Richer, Justin P. wrote:
>> I simply don't agree that there's much difference in practice for many
>> people.
>>
>> -- justin
>> __
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
19 matches
Mail list logo
