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

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 9 Feb 2010 09:15:40 -0700

No one cares?

EHL

> -----Original Message-----
> From: Eran Hammer-Lahav
> Sent: Thursday, February 04, 2010 11:29 PM
> To: OAuth WG ([email-masked])
> 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

---

From: "Paul C. Bryan" <[email-masked]>
Date: Tue, 09 Feb 2010 08:41:37 -0800

For me, not so much care as believe I am in a qualified-enough position
to vote on this one. I'm inclined to use
draft-ietf-oauth-authentication.

On Tue, 2010-02-09 at 09:15 -0700, Eran Hammer-Lahav wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Greg Brail <[email-masked]>
Date: Wed, 10 Feb 2010 21:07:22 -0800

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: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Tuesday, February 09, 2010 11:16 AM
To: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Which draft to use as a starting point for 'using a token'?

No one cares?

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 10 Feb 2010 23:14:36 -0700

> From: Greg Brail [mailto:[email-masked]]
> Sent: Wednesday, February 10, 2010 9:07 PM
> To: Eran Hammer-Lahav; OAuth WG ([email-masked])
> Subject: 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.

This was the consensus a few months ago, that is, that when accessing resources, only the token credentials will be used.

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

There are many ways (two you listed below), but the easiest is to simply encode that information into the token itself. For example, if before your application issued a consumer key 'asb432' and token 'ffd4f3', it can issue token using the new scheme 'asb432:ffd4f3' (with or without the colon, in plaintext or encoded, etc.). There is really no difference in how to send this information over (in one parameter or two).

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

Keep in mind that the client credentials can only be trusted in a few select cases. It is being treated by most services as a hint, not as something to rely on. 

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

That's for the chairs.

EHL