Re: [UMP] Subsetting (was: [XHR2] AnonXMLHttpRequest())

Maciej, Tyler - thanks for continuing this discussion. I think it  
would be helpful to have consensus on what we mean by subsetting in  
this context. (Perhaps the agreed definition could be added to the  
CORS and UMP Comparison [1].)

Anne - as Maciej mentioned in another thread [2], it would be good to  
get your feedback on this subject.

-Art Barstow

[1] http://www.w3.org/Security/wiki/Comparison_of_CORS_and_UMP
[2] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/ 
0058.html


On Apr 8, 2010, at 8:51 PM, ext Maciej Stachowiak wrote:

>
> On Apr 8, 2010, at 5:20 PM, Tyler Close wrote:
>
>> On Wed, Feb 3, 2010 at 7:40 PM, Maciej Stachowiak <mjs@apple.com>
>> wrote:
>>> Actually, the other proposal is to provide an XHR-like API that
>>> would use CORS forcing a unique origin as an input parameter -
>>> there is no need to
>>> My hope is that this would be semantically equivalent to using UMP.
>>
>> This unique origin would still need to discard Set-Cookie response
>> headers to prevent the accumulation of credentials associated with  
>> the
>> unique origin. It would also need to prohibit the reuse of a TLS
>> client authenticated connection or NTLM authenticated connection. It
>> would also need to prevent use of cache entries populated by
>> non-uniform requests. The CORS draft is also unclear on what happens
>> with the Referer header.
>
> Good point. It seems like these should all be raised as issues on
> CORS. I will do it if you don't beat me.
>
>
>>
>>> What I'm looking for is a clear and objective way to evaluate the
>>> desired subset properties. Here are some clear-cut subset
>>> properties that I think will give most of the interoperability and
>>> ease of implementation you want:
>>>
>>> (A) Every Uniform Request should also be a valid CORS request.
>> .
>> ...with the same semantics. The goals being:
>> 1) an UMP API can safely and successfully send a uniform request to a
>> CORS resource
>> 2) a CORS API can safely send a request to an UMP resource, which may
>> choose to either fail or allow the request
>
> Sounds good, although I meant this to only be a syntactic criterion -
> (C) is intended to be the semantic / processing requirements  
> criterion.
>
>>
>>> (B) Every Uniform Response should also be a valid CORS response.
>>
>> ...with the same semantics. The goal being:
>> 1) an UMP resource can safely and successfully return a uniform
>> response to a CORS API
>> 2) a CORS resource can safely and successfully return a uniform
>> response to an UMP API
>>
>> Given the above, a developer can read only UMP and ignore CORS and
>> still write safe code that works. That's what I mean by "subset".
>
> Also agree to your clarifications.
>
>>
>>> (C) When a CORS client makes a Uniform Request and receives either
>>> a Uniform Response, or an HTTP response that is neither a Uniform
>>> Response nor a response would allow access under CORS rules, then
>>> the processing requirements under CORS are the same as the
>>> processing requirements under UMP.
>>
>> (C) seems the same as (B) if we assume both CORS and UMP properly
>> reject Same-Origin-only responses.
>
> I'd like to have a rule explicitly about the processing requirements
> rather than have that implied by rules about semantics. "Semantics" is
> not quite clear-cut enough to evaluate objectively.
>
>>
>>> Currently (A) and (C) do not hold. One counter-example to (A): a
>>> request that contains no Origin header at all, not even Origin:
>>> null, may be a Uniform Request but is not a valid CORS request.
>>
>> I think it would be safe for a CORS resource to assume Origin: null
>> when no Origin is provided. I agree the current spec doesn't say so.
>
> Either UMP or CORS could change here, but we have to agree which to
> change and do it. I don't actually know if assuming "Origin: null" in
> the absence of an origin is safe; that's a change to the model that
> would have to be reviewed. I am pretty confident that adding "Origin:
> null" to a Uniform Request does not pose a security risk, though it
> may be seen as unnecessary from the UMP-only perspective. I also do
> not know if this is the only counter-example; I did not do a thorough
> review UMP and CORS against these criteria at the time. I think we
> should review carefully according to these criteria and reconcile all
> violations before either spec goes to CR (and ideally before either
> goes to LC).
>
>>
>>> One counter-example to (C): UMP will follow a redirect that is
>>> neither a Uniform Response nor allows access under CORS; but CORS
>>> will not.
>>
>> This has since been reconciled.
>
> Good news.
>
>>
>>> I am not currently aware of any violations of (B).
>>
>> (B)(2) is currently violated by the difference in response header
>> filtering. This can be reconciled when the current open CORS issue
>> about response headers is closed. It'll be interesting to see how  
>> this
>> issue is resolved since it is potentially very contentious. Banning
>> response headers seriously affects the extensibility of HTTP.
>
> Can you explain more specifically what the (B) violation is?
>
>>
>>> Also, the reason the conditions on (C) are a little funny: I think
>>> it's possible that a CORS implementation could make a Uniform
>>> Request that receives a non-Uniform Response that nontheless allows
>>> access, but I'm actually not sure if this is possible. It's
>>> definitely possible if it is legal to send multiple "Access-Control-
>>> Allow-Origin:" headers in a response, or to send "Access-Control-
>>> Allow-Origin: null". I am not sure if either of these is allowed.
>>> I'm also not sure if there are other possible CORS responses that
>>> would violate the Uniform Request requirements or UMP processing
>>> model. If there are no such conflicts, then we could tighten C to:
>>
>> An UMP resource is only allowed to respond with a single
>> Access-Control-Allow-Origin: *. Other values are undefined by UMP and
>> so don't offer any defined behavior that an UMP resource can rely
>> upon. That's not a violation of (C) through, since (C) says the
>> response is either a uniform response or one rejected by both UMP and
>> CORS.
>>
>>> (C') When a CORS client makes a Uniform Request and receives any
>>> response, then the processing requirements under CORS are the same
>>> as the processing requirements under UMP.
>>
>> CORS defines more kinds of successful responses than does UMP, since
>> it supports additional values for the Access-Control-Allow-Origin
>> header. So (C') would be violated if a non-compliant UMP resource
>> responded with an Access-Control-Allow-Origin header with a value
>> matching the received Origin header.
>
> I am ok with not having (C') as one of the criteria.
>
>>
>>> Also none of this squarely addresses your original point 1: whether
>>> a UMP server would automatically be compatible with a CORS request
>>> that is *not* a Uniform Request. That would require a condition
>>> something like this:
>>>
>>> (D) When a UMP server receives a CORS Request that is not a Uniform
>>> Request, if it would have granted access to the same request with
>>> all user and server credentials removed, it must process the CORS
>>> request in the same way as it would if all credentials had in fact
>>> been omitted.
>>>
>>> I don't think (D) follows from the current requirements, and I'm
>>> not entirely sure if it is practical to enforce through  
>>> requirements.
>>
>> ...or desirable. I can imagine a resource that legitimately wanted to
>> reject all non-uniform requests. For example, there may be a back-end
>> that doesn't trust its front-end to ignore credentials, so it fails
>> all non-uniform requests so that such requests trigger test failures
>> that can be detected.
>
> I agree; I do not think (D) is a useful property to ensure.
>
>>
>>> Whether CORS and UMP satisfy the various subset relations described
>>> here is something that can be determined objectively through review
>>> of both drafts. Relation conditions like "small subset of the
>>> mechanisms" or "automatically compatible" are harder to pin down. I
>>> would like to ensure that CORS and UMP satisfy at least relations
>>> (A), (B) and (C), and if desirable and practical, also (C') and
>>> (D). Note: I'm not making any assumptions here about which of CORS
>>> or UMP should change to address any given violation of the subset
>>> relation.
>>
>> I think (A) and (B) define the subset relationship we should aim for.
>
> I would prefer to still include (C) to the extent that it require
> anything additional on top of (A) and (B).
>
>>
>>> If we satisfy all of these relations, then once we have an API that
>>> allows making requests that satisfy the Uniform Request
>>> requirements via CORS, it will be usable as a UMP API as well.
>>
>> Sure. Whether or not it is desirable to have both living under the
>> same API is still a question though.
>
> Definitely a valid question, but separate from the subset relation, I
> think.
>
> Regards,
> Maciej
>
>

Received on Monday, 12 April 2010 13:50:58 UTC