- From: Dan Connolly <connolly@w3.org>
- Date: Tue, 12 Oct 2004 15:30:17 -0500
- To: Brad Porter <brad@tellme.com>
- Cc: Dave Raggett <dsr@w3.org>, MattO <matto@tellme.com>, 'Michael Bodell' <bodell@tellme.com>, www-voice@w3.org
- Message-Id: <1097613016.30433.11.camel@dirk>
On Tue, 2004-10-12 at 13:23, Brad Porter wrote: [...] > There are a variety of sandboxing solutions to this: > 1. Most common is to allow "file open" access only to XML files > that reside in the same domain as the requesting document. > The browser must be trusted to perform the DNS/IP restrictions > appropriately. > > 2. Put the burden on the web server to validate HTTP_REFERER > headers and not serve that XML content back to untrusted > sites. The browser must be trusted to provide proper > HTTP_REFERER information. > > 3. Encode access rights as an X-Header of HTTP and have the > browser enforce access only to the allowed domains. > > 4. Encode access rights as a PI in the XML document and have the > browser enforce access to that XML content only to the allowed > domains. It seems to me that another option is to use an element here. Have you considered that design? I can't see why it wouldn't work. > 1. Encode access rights as a parent envelope around the enclosed > XML data and have the browser enforce access to that XML > content only to the allowed domains. > The VoiceXML 2.1 specification allows platforms to use any of these as > they feel appropriate. The PI is the commonly implemented technique > today. The PI allows for sandboxing while supporting the ability to > share XML documents beyond just the same domain. > > To those not versed in internal discussions on the future of XML, the > Processing Instruction appears the most appropriate place in an XML > document for instructions to the processor about the security > restrictions. Hmm... I suppose it's partly a matter of taste. But PIs are harder to use from XSLT, XPath, Dom, etc., no? > Enveloping the content in an XML security envelope may also prove > valuable, but since there isn't a known security enveloping standard > today Umm... there's XML Encryption and XML Signature, both done with elements, attributes, and namespaces. http://www.w3.org/TR/xmlenc-core/ http://www.w3.org/TR/xmldsig-core/ > and there isn't group bandwidth to create one, the group has not > undertaken the effort to create one. > > If this isn't sufficient explanation for 2.1, we would still like a > call to be able to better articulate to our working group the > perspectives on why the PI is including in XML 1.1 but out-of-favor > for future standards, and also be able to report on any related > efforts to define a secure envelope standard to support content > sandboxing. > > Thanks, > Brad -- Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Tuesday, 12 October 2004 20:29:39 UTC