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 protected] [mailto:[email protected]] On Behalf Of Eran
Hammer-Lahav
Sent: Tuesday, February 09, 2010 11:16 AM
To: OAuth WG ([email protected])
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 ([email protected])
> 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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
