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

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

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]>
To: Brian Eaton <[email-masked]>
Cc: OAuth WG <[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]> 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]
> >
> >
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Tue, 8 Mar 2011 11:41:19 -0500

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