Is there a real downside to making them both optional with availability specified by the AS? I have a feeling that's what we're going to end up with in the wild anyway. That is to say, frameworks that can't dig deep enough into HTTP to get to the Basic credentials just won't support that method, even if the spec technically requires it.
-- justin On Mon, 2010-12-06 at 01:39 -0500, Eran Hammer-Lahav wrote: > The argument was, since these are basic credentials, they should be used in > the native HTTP method using the header. But since that is not as simple as a > pair of parameters, we ended up with both. The easy way and the right way. > > From implementing it, my experience has been that it can be hard to deal with > Basic in the context of another authentication class. Since OAuth and Basic > are usually two classes provided by the same authentication layer, having one > use the other can lead to tricky architecture. This trivial to implement in a > clean environment, but a bit messy when adding to an existing framework. > > I am split between doing what is right and what is practical here. > > EHL > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Marius Scurtescu > Sent: Thursday, December 02, 2010 5:35 PM > To: OAuth WG > Subject: [OAUTH-WG] Client Password Credentials > > Currently there are two different ways a client can send credentials, as > specified in section 3.1, and: > "The authorization server MUST accept the client credentials using both the > request parameter, and the HTTP Basic authentication scheme." > > I know there was a long thread on this subject, but I cannot recall the > reasoning. Can someone summarize it? > > How many of the existing OAuth 2 server implementations out there currently > support both methods? > > Thanks, > Marius > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
