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

From: "William J. Mills" <[email-masked]>
Date: Tue, 8 Mar 2011 20:49:59 -0800 (PST)

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

________________________________
From: Brian Eaton <[email-masked]>
To: "Richer, Justin P." <[email-masked]>
Cc: Eran Hammer-Lahav <[email-masked]>; William J. Mills <[email-masked]>; OAuth WG <[email-masked]>
Sent: Tuesday, March 8, 2011 6:25 PM
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft

This has been proven true in our deployment as well.

On Tue, Mar 8, 2011 at 4:16 PM, Richer, Justin P. <[email-masked]> wrote:
> I simply don't agree that there's much difference in practice for many people.
>
>  -- justin
> ________________________________________
> From: Eran Hammer-Lahav [[email-masked]]
> 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 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 potential deployment issue.
>
> EHL
>
>
> On 3/8/11 3:48 PM, "Richer, Justin P." <[email-masked]> wrote:
>
>>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 want to say that we can't use query or form parameters in
>>specifications ever again, this argument doesn't really hold up.
>>
>> -- Justin
>>________________________________________
>>From: Eran Hammer-Lahav [[email-masked]]
>>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 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"
>><[email-masked]<mailto:[email-masked]>>
>>Reply-To: "William J. Mills"
>><[email-masked]<mailto:[email-masked]>>
>>Date: Tue, 8 Mar 2011 10:11:46 -0700
>>To: Justin Richer <[email-masked]<mailto:[email-masked]>>
>>Cc: OAuth WG <[email-masked]<mailto:[email-masked]>>
>>Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
>>
>>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 Richer <[email-masked]<mailto:[email-masked]>>
>>To: William J. Mills <[email-masked]<mailto:[email-masked]>>
>>Cc: Brian Eaton <[email-masked]<mailto:[email-masked]>>; OAuth WG
>><[email-masked]<mailto:[email-masked]>>
>>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-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 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.
>>>
>>>
>>>
>>>
>>> ______________________________________________________________________
>>> From: Justin Richer <[email-masked]<mailto:[email-masked]>>
>>> To: Brian Eaton <[email-masked]<mailto:[email-masked]>>
>>> Cc: OAuth WG <[email-masked]<mailto:[email-masked]>>
>>> 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, 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 compatible
>>> > with the OAuth1 spec.
>>> >
>>> > Luckily they were all caught before they caused serious damage.
>>> >
>>> > Generic parameter names are not useful.  They lead to confused
>>> > developers and confused code.  If code needs to treat the values
>>> > differently, the names should be different as well.
>>> >
>>> > Cheers,
>>> > Brian
>>> >
>>> > On Fri, Feb 25, 2011 at 11:38 AM, Phil Hunt
>>><[email-masked]<mailto:[email-masked]>>
>>> wrote:
>>> > > 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 corresponds to the authorization header and NOT the
>>> value of
>>> > > it. The value of such a parameter an be an encoded value that
>>> corresponds to
>>> > > the authorization header.  For example:
>>> > > GET /resource?authorization_token=BEARER+vF9dft4qmT HTTP/1.1 Host:
>>> > > server.example.com
>>> > > instead of
>>> > > GET /resource?oauth_token=vF9dft4qmT HTTP/1.1 Host:
>>> server.example.com
>>> > > The concern is that if for some reason you switch to "MAC" tokens,
>>> then you
>>> > > have to change parameter names. Why not keep them consistent?
>>> > > Apologies if this was already resolved.
>>> > > Phil
>>> > > [email-masked]<mailto:[email-masked]>
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > _______________________________________________
>>> > > OAuth mailing list
>>> > > [email-masked]<mailto:[email-masked]>
>>> > > https://www.ietf.org/mailman/listinfo/oauth
>>> > >
>>> > >
>>> > _______________________________________________
>>> > OAuth mailing list
>>> > [email-masked]<mailto:[email-masked]>
>>> > https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [email-masked]<mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Lukas Rosenstock <[email-masked]>
Date: Thu, 10 Mar 2011 17:49:47 +0100

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]>

> 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
>

---

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

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]]
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]>>
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