Re: FW: VoiceXML 2.1 and PI issue

Reforwarding to www-voice.  I'm doing my best to write up the explanation and look forward to your full review or a personal discussion.

Thank you!
Brad



Dan Connolly wrote:

On Tue, 2004-10-12 at 12:34, Dave Raggett wrote:
[...]
  

I am interested to see what comments Dan Connolly may have on this,
    

I haven't seen anything that says why a PI should be used
rather than an element or attribute.

(but I've just been skimming; I prefer to discuss technical
matters in public fora; in this case, www-voice).


  

--- Begin Message ---

Subject:	Re: FW: VoiceXML 2.1 and PI issue

Hi Dave and Dan,

I'll give a brief write-up of the data security model and the use of the PI.  With respect to various alternatives and how to proceed, I personally find phone discussions to be more conducive to brainstorming possible resolutions. 

The <data/> tag allows for fetching and inspection of the contents of any XML document.  Being effectively a "file open" command on any XML, proper sandboxing needs to be enforced.  A VoiceXML application, like an HTML application or an untrusted Java applet should not have unrestricted "file open" access. 

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.
   
   
5. 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.  Enveloping the content in an XML security envelope may also prove valuable, but since there isn't a known security enveloping standard today 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



MattO wrote:

-----Original Message-----
From: Dave Raggett [mailto:dsr@xxxxxx] 
Sent: Monday, October 11, 2004 10:54 AM
To: matto@xxxxxxxxxx
Cc: jim@xxxxxxxxxxxxxxx; scott.mcglashan@xxxxxx
Subject: VoiceXML 2.1 and PI issue


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Matt,

I just had a quick chat with Dan Connolly about the PI issue. Dan and I
would like to see either a justification of why a special PI (XML processing
instruction) is needed for VoiceXML 2.1, or the adoption of of an
alternative solution such as a new attribute or element. If this is the only
issue before moving the CR, then things should be pretty quick.

To move to CR, we will need an updated spec plus the implementation 
report plan. We then have to schedule a meeting with W3C Management 
to review the request to advance to CR. Would you be willing to attend the
meeting to deal with any questions that come up? We will be asked to review
the disposition of comments and it is important that all comments have been
dealt with. Commentators need to have confirmed that their issues have been
addressed even if the result isn't always what they wanted. This applies to
Dan too.

Regards,
- -- 
 Dave Raggett <dsr@xxxxxx>  W3C lead for voice and multimodal.
http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)
 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBasjab3AdEmxAsUsRAiWBAKCWjuAIwdelaVXttv2/3RPV/BxT9QCbBKHa
UdrFLm+nLn3M3o1adHMJFZU=
=A/qU
-----END PGP SIGNATURE-----


  

--- End Message ---