Good point. No error required. EHL
> -----Original Message----- > From: Torsten Lodderstedt [mailto:[email protected]] > Sent: Thursday, July 01, 2010 3:05 PM > To: Eran Hammer-Lahav > Cc: Marius Scurtescu; Justin Richer; [email protected] > Subject: Re: [OAUTH-WG] Support for query/body parameters (Was Re: > Versioning) > > ok sounds good. But AFAIK "authentication required" is already the meaning > of status code 401. So why another error parameter? > > regards, > Torsten. > > Am 01.07.2010 23:54, schrieb Eran Hammer-Lahav: > > 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
