VBWG official response to last call issue

Dear Janina, et al,

The Voice Browser Working Group (VBWG) has almost finished resolving the
issues raised during the last call review of the 28 July 2004 working draft
of VoiceXML 2.1 [1]. Our apologies that it has taken so long to respond.

Please indicate before March 14th, 2005 if you are satisfied with the VBWG's
resolutions, if you think there has been a misunderstanding, or if you wish
to register an objection. If you will be unable to respond before March
14th, please let me know. The Director will appreciate a response whether or
not you agree with the resolutions.

Below you will find:

 1) More information follows about the process we are following.
 2) A summary of the VBWG's response to your issues.

Thank you,

Matt Oshry
Chief Editor, VoiceXML 2.1

-----------------------------------------------
1) Process requirement to address last call issues
-----------------------------------------------

Per section 7.2 [2] of the 5th February 2004 Process Document, in order for
the VoiceXML 2.1 specification to advance to the next state (Candidate
Recommendation), the Working Group must "Formally address all issues raised
about the document since the previous step." 
Section 3.3.3 of the Process Document [3] sets expectations about what
constitutes a formal response:

  "In the context of this document, a group has formally addressed an issue 
  when it has sent a substantive response to the reviewer who raised the
issue. 
  A substantive response is expected to include rationale for decisions 
  (e.g., a technical explanation, a pointer to charter scope, or a pointer 
  to a requirements document). The adequacy of a response is measured
against 
  what a W3C reviewer would generally consider to be technically sound. 
  If a group believes that a reviewer's comments result from a
misunderstanding, 
  the group SHOULD seek clarification before reaching a decision."

If you feel that the response is based on a misunderstanding of the original
issue, you are encouraged to restate and clarify the issue until there is
agreement about the issue, so that the Working Group may prepare its
substantive response.

If the response shows understanding of the original issue but does not
satisfy the reviewer, you may register a formal objection with the Working
Group that will be carried forward with the relevant deliverables. 

[1] http://www.w3.org/TR/2004/WD-voicexml21-20040728/
[2] http://www.w3.org/2004/02/Process-20040205/tr.html#transition-reqs
[3] http://www.w3.org/2004/02/Process-20040205/policies.html#formal-address

-----------------------------------------------
2) Issues you raised and responses
-----------------------------------------------
In http://lists.w3.org/Archives/Public/www-voice/2004JulSep/0058.html you
raised the following issue which was registered as change request R106. Our
response is given inline:

"On behalf of the Protocols and Formats Working Group (WAI):

We are concerned that the security provisions specified in Appendix E:
Securing access to <data>

http://www.w3.org/TR/2004/WD-voicexml21-20040728/#sec-data-security

would negatively impact accessibility.

*	It is reasonable to believe that various agencies and service
*	organizations might create specialized scripts to better meet
*	the interface needs of certain populations of persons with
*	disabilities who cannot directly use a voice-based service
*	without special accomodation. Indeed, we believe such enhanced
*	interfaces could provide access to information and services were
*	it does not exist today. Protecting this opportunity is
*	important.

*	The mechanism outlined in Appendix E, however, tends to limit
*	access to organizations known to the organization hosting the
*	VoiceXML application. Agencies serving persons with
*	disabilities, however, are likely to be unknown and of lesser
*	commercial impact. It is likely, therefore, that agencies
*	serving persons with disabilities would find it dificult to be
*	listed.

*	Furthermore, the mechanism specified in Appendix E would require
*	agencies serving persons with disabilities to seek listing with
*	every VoiceXML application host individually. This is burdensome
*	and likely to result in spotty accessibility support at best.

We would suggest the security control provisions be reconsidered to provide
for a authenticated access vouched and certified by a third-party trust
broker. While such services may not be commonplace today, we believe
numerous use case scenarios exist for such services--beyond the current
instance."

VBWG Response: Accepted

The purpose of the security model defined in Appendix E is to assert that
browsers should support content sandboxing. In particular, because the data
element is effectively a "file open" command for arbitrary XML content at
any URL accessible to the browser, it represents a potential security risk. 

Without this security model, a browser running inside a corporate firewall,
for example, would permit an application running on that browser to access
internal corporate documents and to potentially submit that data back to
another web server. 

Web standards should be designed to support the most conservative security
environment. In particular, malicious VoiceXML content should not have
arbitrary access to any network-accessible XML resource. The browser is the
agent entrusted to preserve application-to-application sandboxing. 

The working group evaluated a number of solutions that would enable data
providers to secure their data against unauthorized access. The working
group decided to keep an informative description of the access-control PI in
the spec to educate browser implementors and data providers about one
possible mechanism for enforcing data security. This mechanism has the
benefit of being lightweight and straightforward for data providers and
platform vendors to implement.

Received on Wednesday, 9 March 2005 01:51:44 UTC