We tried something like this approach before but the group consensus was that we should only have a single spec for now. I submitted a draft defining just the Token auth scheme with the expectation that another drafts define the flows, but the group didn't like this approach.
As for using Basic/Digest for flow authentication, that's a proposal made by James Manger which so far received little support (though no hard objections). I don't have a strong preference either way. EHL > -----Original Message----- > From: Robert Sayre [mailto:[email protected]] > Sent: Wednesday, April 21, 2010 8:24 AM > To: Eran Hammer-Lahav > Cc: [email protected] > Subject: Re: [OAUTH-WG] misuse of status code: 400 Bad Request > > On Wed, Apr 21, 2010 at 11:11 AM, Eran Hammer-Lahav > <[email protected]> wrote: > > The reason I used 400 in the flows (section 3) is that a 401 response > requires returning a challenge [1]: > > > > The request requires user authentication. The response MUST include > > a WWW-Authenticate header field. > > > > and we don't have a suitable challenge to return. We can't use the Token > auth scheme here because the flow endpoints are not OAuth-protected > resources. They use a mix of client credentials, user credentials, and > verification codes. > > Yes, well, what the spec calls "flows" look to me like authentication schemes > used to get a token. My (free) advice would be to move all of the flows to > their own specs, perhaps leaving one in the document that works using only > HTTP authentication headers. That way, you'll finish a lot faster, and other > flows can use the base OAuth 2.0 document as a reference. I am willing to > provide text to illustrate this point. > > -- > > Robert Sayre > > "I would have written a shorter letter, but I did not have the time." _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
