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