Re: ACTION-340: CORS, UMP and XHR2

John Kemp wrote:
> Hi Mark,
> 
> On May 20, 2010, at 12:00 PM, Mark S. Miller wrote:
> 
>> On Thu, May 20, 2010 at 7:57 AM, John Kemp <john@jkemp.net> wrote:
>>
>>
>> It should be noted that because UMP suggests a new model, it does not
>> yet support the same set of use-cases supported by CORS.
>>
>>  
>> UMP does support the use cases listed in the CORS doc, and virtually all use cases anyone has thrown at us. Also, CORS does not support many of the use cases supported by UMP. This pair of facts seem worth mentioning.
> 
> My statement comes from reading the requirements section of the UMP specification: http://www.w3.org/TR/UMP/#requirements where it says:
> 
> "Note: These requirements are taken from the CORS specification. A note indicates those requirements that could not be fully satisfied."
> 
> and, for requirement 10 in that list:
> 
> "Note: To retain compatibility with deployed implementations, support for POSTs of arbitrary media types is deferred to a future Uniform Messaging Policy, Level Two specification."
> 
> Requirements 12, 16 and 17 have similar notes.
> 
> I believe that UMP also supports use-cases, and meets requirements _not_ listed in the CORS spec. 
> 
>>   
>> In summary, both CORS and UMP support cross-domain requests. CORS
>> utilizes existing origin- and cookie-based approaches for access
>> control, but doesn't completely prevent XSRF/Clickjacking. UMP allows
>> the complete prevention of such attacks, but relies upon
>> relatively non-standard mechanisms for authenticating cross-site requests in
>> order to do so.
>>
>> As we explain in the "Security Considerations" of UMP, websites must already use some kind of unguessable token (i.e., the CSRF token) to protect themselves from CSRF anyway. So UMP does not rely on "relatively non-standard mechanisms". Am I missing something?
> 
> Are any of the "unguessable token" mechanisms you mention widely supported by websites? If so, which one(s), and by whom are they supported?

For what it's worth, there is one kind of 'unguessable token' that works 
with either CORS or UMP, namely HTTPS with client side certificates 
(where that unguessable token would be the private key which stays on 
the client), this can also be tied rather nicely to identity and access 
control as illustrated by FOAF+SSL.

Additionally, after quite a lot of reviewing CORS seemed to do the 
trick, it's already supported by many clients, and the only addition I 
personally saw a strong need for was the addition of a CORS version of 
UMP's "Uniform-Headers" (perhaps better named as Expose-Headers or 
similar) this would allow a server to specify additional response 
Headers which implementing clients should allow (such as 
Content-Location, Location, Link which are currently stripped).

It is worth noting that currently CORS only allows the following:
- Cache-Control
- Content-Language
- Content-Type
- Expires
- Last-Modified
- Pragma

Best,

Nathan

Received on Thursday, 20 May 2010 16:40:26 UTC