Re: FW: VoiceXML 2.1 and PI issue

Thanks for the detailed response.  Comments inline...

Dan Connolly wrote:

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.
  

Yes, this is basically what the next option is.

     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?
  

Agreed that PIs are harder to use from those places.  In this case, that is arguably a feature not a bug.  In our DOM implementation, we choose not expose the PI through the DOM because the PI allows an XML data provider to list multiple parties that are allowed to access that data.  For instance, a sports score data provider may provide their data to a number of VoiceXML applications but may not want those applications to see the list of applications to whom they have granted access.

XPath and XSLT support aren't perceived as critical because the access-control header is not designed to be rendered in any fashion, but is purely envelope. 

  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/
  

Thanks, I will go review these.  If they seem appropriate to the task, then I can present these back to the group.

Brad

 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