I think that works. POST body support can even be moved to a separate spec, if anyone really uses it.
Marius On Thu, Jul 1, 2010 at 1:28 PM, Eran Hammer-Lahav <[email protected]> wrote: > 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
