Re: [OAUTH-WG] OAuth 2.0 / Charter

Some more notes here:

http://radar.oreilly.com/2010/01/whats-going-on-with-oauth.html


On Sun, Nov 29, 2009 at 11:24 AM, Dan Brickley <danbri@danbri.org> wrote:

>
> Important crossroads for OAuth...
>
> Dan
>
>
>
> Begin forwarded message:
>
> *From:* Eran Hammer-Lahav <eran@hueniverse.com>
> *Date:* 29 November 2009 08:59:21 CET
> *To:* "Peter Saint-Andre (stpeter@stpeter.im)" <stpeter@stpeter.im>, "Lisa
> Dusseault (lisa.dusseault@gmail.com)" <lisa.dusseault@gmail.com>
> *Cc:* "OAuth WG \(oauth@ietf.org\)" <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>
> http://tools.ietf.org/html/draft-hammer-oauth
> [2] <http://bit.ly/oauth-wrap>http://bit.ly/oauth-wrap
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>