Re: [OAUTH-WG] Which draft to use as a starting point for 'using a token'?

Like a lot of people, I think, things are moving along and we're trying to keep up. I do have a few more basic questions.

Like it or not, the concept of a "consumer key" and "access token" is hard-wired into many developers' perceptions of OAuth, and a major difference between the two specs is that "ietf-oauth-authentication" retains both tokens and "http-token-auth" does not.

Given that today's OAuth-based applications are relying on having two tokens on each request, how would this work if "ietf-oauth-authentication" were to be adopted? If a developer or API provider wishes to include some sort of "consumer key" on each request in addition to the token, how should that be accomplished?

One option would be to simply say, "we don't care -- just make it an additional request parameter and call it what you want". But I think if that's the case then that has to be spelled out in the "release notes" for the new specs somehow. (And no, I don't know what the right mechanism is for that in IETF.)

For instance, in a number of APIs I've been involved with recently, the "consumer key" from OAuth 1.0 is NOT an "equivalent to a username" as described in "ietf-oauth-authentication." Rather, it's used to uniquely identify the application that is calling an API. API providers usually wish to track not only the user making a request (which can be inferred from the token), but also which application was used and which developer wrote that application. A sophisticated back-end app can of course infer this information too from the token, but I don't know what kind of back-end changes would be required to make that happen for an existing API, nor do I know whether your typical API provider wishes to store that much state.

Finally, I personally like "draft-hammer-http-token-auth" better because it is more straightforward in that there is only one token and no need to mess around with signing it by constructing a key made out of two keys, and so forth. I also like that there is some structure around the "WWW-Authenticate" response, and the option to sign the entire request body or leave it unsigned.

Finally, finally this time, would it be possible to have a link to "draft-hammer-http-token-auth" on the main OAuth IETF page? Google works fine but still it'd help.

			greg

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Tuesday, February 09, 2010 11:16 AM
To: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Which draft to use as a starting point for 'using a token'?

No one cares?

EHL

> -----Original Message-----
> From: Eran Hammer-Lahav
> Sent: Thursday, February 04, 2010 11:29 PM
> To: OAuth WG (oauth@ietf.org)
> Subject: Which draft to use as a starting point for 'using a token'?
> 
> On the call today I clarified what is going on with all the different drafts. In
> brief:
> 
> draft-hammer-oauth - documentation of the OAuth 1.0 Rev A (with changes)
> protocol. This is done and should be approved by the IESG shortly for
> publication.
> 
> draft-ietf-oauth-authentication - the part of OAuth 1.0 dealing with 'how to
> use a token after you obtain it'.
> draft-ietf-oauth-web-delegation - the part of OAuth 1.0 rev A dealing with
> 'getting a token'.
> 
> draft-hammer-http-token-auth - an alternative proposal (meant to replace
> draft-ietf-oauth-authentication) which builds on top of OAuth 1.0 but cleans
> up the structure and removes the client credentials when accessing
> protected resources. It also changes how the request is normalized into a
> string before signing.
> 
> We have three options for moving forward with 'how to use a token'. Start
> with:
> 
> 1. draft-ietf-oauth-authentication
> 2. draft-hammer-http-token-auth
> 3. something else*
> 
> * Do not suggest something else unless you are going to submit a proposal. It
> doesn't have to be an I-D, I am happy to do the editorial work but I will need
> a detailed proposal that is enough to turn into a specification.
> 
> Pick.
> 
> EHL

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth