> But in my opinion JSONRequest or XDR would be good starting points for > cross-site > request technology that would have the right security characteristics and > meet the > requirements. As I have said several times before, AC has the wrong > fundamental
I believe JSONRequest and XDR have the wrong fundamental approach because they do not have any opt-in mechanism prior to allowing requests to be sent. With both of these approaches the opt-in is for allowing the response to be read by the client code, but nothing limits the actual requests. This means that both JSONRequest and XDR basically have absolute limits on what they can allow to be sent, neither can allow any requests that are not already permissible on the web or they would be opening new attack vectors (They do create slightly requests because they have different headers and JSONRequest attaches a different content type, but this is negligible). There will be no XDR2 or JSONRequest2 that supports PUT, DELETE, extra headers, cookies, and so forth, because they have no mechanism for opt-in to authorize requests actually being sent, they only authorize response handling. XDR and JSONRequest are already as permissible as they possibly can be, there is no hope of evolving these technologies (unless they adopt an AC-like opt-in capability). This is the wrong foundation. On the otherhand, XHR/AC does have the right foundation, with server opt-in for otherwise unsafe requests. I am in agreement that we want convergence and we want simplicity, and XHR/AC could definitely be simplified. However, we must start with the right foundation of authorization for unsafe requests or otherwise we will end up in a corner with no room to evolve. > approach because it puts allow/deny processing on the client rather than > having the > server do this. First, this is not fundmental to the AC approach. This could certainly be removed and it would not fundmentally alter the AC proposal, IMO. And once again, the client does not make allow/deny decisions in XHR/AC, the deputy (the browser) makes these decisions, the client (JavaScript) plays no part in this processing. It is critical to differentiate the roles of the client and deputy for security analysis in this area. > The server already knows what policy it wants to enforce since it > sends down the Access-Control header or PI. Because of the client-side > allow/deny > processing, AC has grown to be much more complicated than either JSONRequest > or XDR. I'm on board with you here. While deputy policy enforcement is fine from a security perspective, I am in favor of any efforts to simplify AC. If nothing else, removing some of the deputy processing (surely we could live without XML PIs too) for the sake of simplificiation could be the sacrificial lamb to make it AC more widely palatable to the masses. Kris
