That's where the error parameter will be (the only supported place in -09 for a failed protected resource response).
EHL > -----Original Message----- > From: Torsten Lodderstedt [mailto:[email protected]] > Sent: Thursday, July 01, 2010 2:51 PM > To: Eran Hammer-Lahav > Cc: Marius Scurtescu; Justin Richer; [email protected] > Subject: Re: [OAUTH-WG] Support for query/body parameters (Was Re: > Versioning) > > I essentially agreed, except in 3. the server should send back status code 401 > with a WWW-Authenticate header. > > regards, > Torsten. > > Am 01.07.2010 22:28, schrieb Eran Hammer-Lahav: > > I think all servers must support the header. I don't think we can demand all > servers to support query or post parameters as that can conflict with their > existing namespace or architecture. I suggest we: > > > > 1. Make the "Token" scheme required in all resource servers 2. Allow > > resource servers to support the URI query or response body 3. Specify > > that when a request comes without the header to a server only supporting > the header, the server should respond with error=authentication_required > to inform the client this form of authentication is not supported. > > > > EHL > > > > > >> -----Original Message----- > >> From: [email protected] [mailto:[email protected]] On > >> Behalf Of Marius Scurtescu > >> Sent: Thursday, July 01, 2010 12:48 PM > >> To: Justin Richer > >> Cc: [email protected] > >> Subject: Re: [OAUTH-WG] Versioning > >> > >> On Thu, Jul 1, 2010 at 12:38 PM, Justin Richer<[email protected]> wrote: > >> > >>>>> OAuth tokens as a form-encoded element in a post body? Yes. Keep > it. > >>>>> > >>>> Just curious. What use case would require that the access token is > >>>> put in the post body as opposed to an http header when accessing a > >>>> protected resource? > >>>> > >>> If nothing else, it parallels the use case of a GET-style query > >>> parameter. It makes sense to have it be valid in both ways to allow > >>> developers to put the token in with whatever other parameters > >>> they're passing along. I've got plenty of use cases here for the > >>> query > >>> parameters: it's needed for cases where your client can't get any > >>> deeper into HTTP than "hey go fetch me this URL". > >>> > >> You can still use query parameters with POST. > >> > >> > >> > >>> What use case says we shouldn't do POST parameters like that? A > >>> server wanting to do early-dispatch of a request was brought up, but > >>> that was only in the case of handling OAuth 1 and 2 simultaneously > >>> as I understood it. If a server's going to be doing dispatch on auth > >>> headers and query parameters already, it seems that it's got the > >>> wherewithal to parse a form-encoded body, too. > >>> > >> Parsing the body is not trivial. Some filters do not have access to > >> it (apache mod_redirect for example), some frameworks will allow you > >> to access it once and then commit to a format, a decision that cannot > >> be made by a filter (in Java see ServletRequest: getInputStream vs > getReader vs getParameter). > >> > >> > >> 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
