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-boun...@ietf.org [mailto:oauth-boun...@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-boun...@ietf.org [mailto:oauth-boun...@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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
