Re: [OAUTH-WG] Call for Consensus on Document Split

This was the proposal posted to the group earlier.

In the past you have strongly promoted separate schemes for each token type, as well as rejected the idea of a single scheme framework with sub-typing. How would you suggest we define a general purpose www-authenticate header that does not have a matching request header?

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Manger, James H
> Sent: Thursday, October 14, 2010 4:20 PM
> To: Blaine Cook; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Call for Consensus on Document Split
> 
> Blaine,
> 
> I am in favour of splitting the specification, but the right dividing line is not
> the whole of section 5 "Accessing a Protected Resource".
> 
> The core OAuth spec needs to keep a section defining a WWW-Authenticate
> response header with which to tell a client that the OAuth "get a token"
> flows can be used to get access to a resource. This is a bit like section 5.2 "The
> WWW-Authenticate Response Header Field".
> 
> Error codes [section 5.2] like "expired_token" or "insufficient_scope" only
> make sense in a spec that defines the flows to renew a token or change its
> scope. I assume that will be the core OAuth spec, not the bearer token spec.
> For comparison, the HTTP BASIC spec does not tell you how to change your
> password or register for a password.
> 
> 
> My suggestion for the editorial split:
> * Remove 5, 5.1, 5.1.1, 5.1.2, and 5.1.3.
> * Keep 5.2, and 5.2.1.
> 
> 
> --
> James Manger
> 
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Blaine Cook
> Sent: Thursday, 14 October 2010 11:32 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Call for Consensus on Document Split
> 
> Over the past few weeks, the working group debated the issues around the
> introduction of signatures and the structure of the specification.
> The working group seems to endorse the proposal to split the current
> specification into two parts: one including section 5 (bearer token) and the
> other including the rest (how to obtain a token), with an additional
> specification covering signature use cases.
> 
> This serves as a call for consensus on the proposed editorial work.
> Before we proceed with the changes, the chairs would like to ask if anyone
> has any concerns or objections against this proposal.
> 
> In addition, the chairs are seeking a volunteer to take over the bearer token
> specification (section 5) as editor.
> 
> Please submit your comments by Wednesday, October 20th.
> 
> - The OAuth Working Group Chairs
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth