W3C home > Mailing lists > Public > www-voice@w3.org > October to December 2004

Re: FW: VoiceXML 2.1 and PI issue

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 October 2006 12:49:00 GMT