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@w3.org]
>Sent: Monday, October 11, 2004 10:54 AM
>To: matto@tellme.com
>Cc: jim@larson-tech.com; scott.mcglashan@hp.com
>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@w3.org> 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-----
>
>
>
>