Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)

from my understanding, the assertion you explained in your scenario 
represent the authorization of end-users (not client applications) to 
access feeds. Thus I see them as a kind of user credentials and would 
send them as request parameter. Authorization headers will be used for 
client authentication only.

regards,
Torsten.

Am 13.05.2010 22:51, schrieb Yaron Goland:
> But in federation scenarios the client credentials are an assertion.
>
> For example, Microsoft has a service called Dallas that lets entities purchase access to proprietary data feeds. A common scenario we run into with Dallas is that a company will purchase access to a feed for its employees. But the company doesn't want to have to individually specify to Dallas who can and cannot use the feed. Instead they want to agree on a key with Dallas and use that key to sign assertions sent to Dallas saying "let this person in". The OAuth flow would be:
>
> 1. A Dallas client of an employee of 'the company' issues a request to 'the company's ticket issuer asking for a security token it can send to Dallas.
> 2. 'The Company's ticket issuer generates a signed assertion stating that the bearer has the right to use 'The Company's subscription to a particular feed.
> 3. The Dallas client then forwards that security token to Dallas's ticket issuer asking for an access token to actually talk to Dallas's front end.
> 4. Dallas validates the security token (e.g. checks the signature, makes sure it has the right claims, etc.) and if successful then issues an access token to the Dallas client.
>
> So in step 3 the client credential was a full-fledged security token of potentially arbitrary size.
>
> BTW, just to make sure I'm properly following along, we are talking about section 3.9?
>
> 		Yaron
>
>
>    
>> -----Original Message-----
>> From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
>> Sent: Tuesday, May 11, 2010 4:37 PM
>> To: Yaron Goland; Torsten Lodderstedt
>> Cc: OAuth WG (oauth@ietf.org)
>> Subject: RE: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)
>>
>> No one was suggesting putting the assertion in the header. Just the client
>> credentials...
>>
>> EHL
>>
>>      
>>> -----Original Message-----
>>> From: Yaron Goland [mailto:yarong@microsoft.com]
>>> Sent: Tuesday, May 11, 2010 4:24 PM
>>> To: Torsten Lodderstedt
>>> Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
>>> Subject: RE: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)
>>>
>>> Actually it's server side that's the problem. Many servers limit the
>>> size of the HTTP request headers they will accept. Apache 2.2, for
>>> example, uses the LimitRequestFieldSize Directive
>>> (http://httpd.apache.org/docs/2.2/mod/core.html). Its default size is
>>> 8190 bytes. IIS, I Believe, defaults to around 16K. But SAML
>>> assertions can easily clock in at 30 or 40k without even trying.
>>>
>>> So as a practical matter we need a way to allow clients to assert
>>> their right to a token using the request body so as to not need to
>>> artificially limit the size of the token that is being submitted.
>>>
>>> 		Yaron
>>>
>>>        
>>>> -----Original Message-----
>>>> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
>>>> Sent: Monday, May 10, 2010 10:47 PM
>>>> To: Yaron Goland
>>>> Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
>>>> Subject: Re: [OAUTH-WG] Open Issues: Group Survey (respond by 5/13)
>>>>
>>>> Am 11.05.2010 01:43, schrieb Yaron Goland:
>>>>          
>>>>>            
>>>>>> ---
>>>>>>
>>>>>> 2. Client Authentication (in flows)
>>>>>>
>>>>>> How should the client authenticate when making token requests?
>>>>>> The current draft defines special request parameters for sending
>>>>>> client credentials. Some have argued that this is not the correct
>>>>>> way, and that the client should be using existing HTTP
>>>>>> authentication schemes to accomplish that such as Basic.
>>>>>>
>>>>>> A. Client authenticates by sending its credentials using special
>>>>>> parameters (current draft) B. Client authenticated by using HTTP
>>>>>> Basic (or other schemes supported by the server such as Digest)
>>>>>>
>>>>>>
>>>>>>              
>>>>> [Yaron Goland] A is needed at a minimum because there are physical
>>>>>            
>>>> limitations to how many bytes can go into an authorization header.
>>>>          
>>>>>            
>>>> As far as I know, 4KB is the minimum size for headers that must be
>>>> supported by user agents, which should suffice from my point of view.
>>>> Moreover, other HTTP authentication mechanisms need much more than
>>>> 4KB, For example, SPNEGO authentication headers can be up to 12392
>>>>          
>>> bytes.
>>>        
>>>> regards,
>>>> Torsten.
>>>>
>>>>          
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>>            
>>>>
>>>>          
>>      
>    