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

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.

> 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

> (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".

> (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.

> 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.

> 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.

> 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.

> 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.

> 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.

> 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.

> 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.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Received on Friday, 9 April 2010 00:21:24 UTC