Fwd: [OAUTH-WG] OAuth 2.0 / Charter

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
> [2] http://bit.ly/oauth-wrap
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth