Mike, Thanks, I just noticed you addressed the change to "BEARER" in draft 03 (just published).
I could live with the parameter name oauth_token, provided we can sub-type (rather then be generic). E.g. GET /resource?oauth_token=BEARER+vF9dft4qmT Either way, I suspect this is a breaking change unless we specify that no prefix (i.e. as with authorization header) refers to the legacy case. Which I could also live with. If we don't then the value of OAUTH_TOKEN (or authorization_token) becomes unclear. I think this will cause some major issues that some will consider bugs in the spec. Phil phil.h...@oracle.com On 2011-02-25, at 2:24 PM, Mike Jones wrote: > Hi Phil, > > Yes, per the working group vote, we decided on the name “Bearer”. This name > is used in the just-published draft -03. > > This draft did not change the oauth_token parameter name; as editor, I am not > introducing breaking changes at this point unless directed to do so by a vote > of the working group. > > I agree with your consistency goal among the related specs. One step I took > in this draft towards that end in the latest draft was establishing the OAuth > Errors registry and extending the scope of the OAuth Parameters registry; the > goal is that inconsistencies in error and parameter names among related specs > will be more likely to be identified and corrected 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, 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 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 > phil.h...@oracle.com > > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
