Re: [OAUTH-WG] OAuth 2.0 / Charter

SWT is one.

http://groups.google.com/group/oauth-wrap-wg

EHL

From: Greg Brail [mailto:gbrail@sonoasystems.com]
Sent: Monday, November 30, 2009 9:35 AM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: RE: OAuth 2.0 / Charter

Thanks for the clarification.

I do think that a standard token structure would be a good thing for the Internet in general. Is there another effort I should be following regarding the token structure itself?

________________________________
From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Monday, November 30, 2009 2:36 AM
To: Greg Brail
Cc: OAuth WG (oauth@ietf.org)
Subject: RE: OAuth 2.0 / Charter

Keep in mind that we are not going to include token structure in scope. We are simply proposing a method in which the token is a string, leaving it up to other efforts to give it structure if needed.

EHL

From: Greg Brail [mailto:gbrail@sonoasystems.com]
Sent: Sunday, November 29, 2009 9:05 PM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: RE: OAuth 2.0 / Charter

I've been following this discussion for a while now as a relative newcomer and I think this is a great idea. Forgive me if all you guys have reached this conclusion already:

Since we all understand OAuth, there are other places where tokens are popping up:

*  As a "more secure" replacement for username / password authentication in web services APIs like Amazon's

*  As a way for the developer of an API to understand which developer's applications are being used against the API, when it is less important to identify the actual user (for instance, the classical "API key" use case, or "two-legged OAuth")

*  As a way for the developer of a mobile app to ensure that only that app can make use of a particular web service, even if it is not important to identify the actual user

*  Lots of others I'm sure I'm missing

The sooner there is some movement towards a standard "token," the sooner we will have token support in a variety of programming environments. Plus, a standard token will reduce the propensity of web services builders to design their own tokens, with varying levels of security.

Plus, the OAuth flow has clearly proven to be useful and it deserves to be a standard that makes use of the standard token.

On the design of the token itself, I hope that it will have a place for one, two, or even more combinations of keys and secrets, so that it can handle simple use cases, more complex use cases such as OAuth, and even those that require three or more separate identifiers for a request.

                                                            greg

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Sunday, November 29, 2009 2:59 AM
To: Peter Saint-Andre (stpeter@stpeter.im); Lisa Dusseault (lisa.dusseault@gmail.com)
Cc: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG] OAuth 2.0 / Charter

With the cleanup of the 1.0 specification [1] and the publication of an informational RFC (pending IESG approval), I no longer see value in a standard closely based on the 1.0 specification, which was the original intention of this WG. This is also reflected by the recent interest in the WRAP proposal [2].

Instead, I think we should develop two specifications that while closely in line with the original plan, represent a significant shift. In other words, I am proposing we develop OAuth 2.0, not 1.1.

The new proposal is to develop two specifications:

1. Token Authorization Method

An RFC 2617 Authorization header called 'Token' for authenticating requests with token-based credentials. Tokens (with optional shared-secret) are usually used in place of other credentials (usernames, etc.) and represent some combination of scope and authorization. The token method will include an extensible signature-based option based on the HMAC-SHA1 method, and a bearer token (with optional secret) option based on the PLAINTEXT method. The RSA option will be dropped.

2. OAuth 2.0

A specification based on the browser-redirection flow described in OAuth 1.0 as well as new methods defined in WRAP (I-D submission pending). OAuth will be redefined to cover the authorization component only, and will no longer be bound to a single authentication method. This will make OAuth immediately useful for other protocols than HTTP (while HTTP will be used to obtain tokens, tokens will be useful in other protocols, not just with the HTTP and Token method).

---

While the current charter allows much of this work, it contradicts its spirit and the understanding reached when we created the working group.

I would like to ask:

- Is this approach favorable by the group?

- Do we need to adjust the language in the charter to support?

EHL

[1] http://tools.ietf.org/html/draft-hammer-oauth

[2] http://bit.ly/oauth-wrap

_______________________________________________

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth