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:torsten@lodderstedt.net]
>> Sent: Thursday, July 01, 2010 2:51 PM
>> To: Eran Hammer-Lahav
>> Cc: Marius Scurtescu; Justin Richer; oauth@ietf.org
>> 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: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
>>>> Behalf Of Marius Scurtescu
>>>> Sent: Thursday, July 01, 2010 12:48 PM
>>>> To: Justin Richer
>>>> Cc: oauth@ietf.org
>>>> Subject: Re: [OAUTH-WG] Versioning
>>>>
>>>> On Thu, Jul 1, 2010 at 12:38 PM, Justin Richer<jricher@mitre.org>   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
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>          
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>        
>    