Re: VBWG official response to last call issue

At 5:51 PM -0800 3/8/05, MattO wrote:
>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.

Let us echo your apologies for not responding faster.

* summary

We accept your resolution of this comment, with a few remarks.

* details (remarks)

We agree that it is important to secure network communication used to bring
partner data into voice browser operations.

In fact, as you can tell from the earlier comment, we would prefer to
get Voice Browser operators up on a more robust and open web of services
as the back-office bus. Stronger security practices allow more fanout
in business relationships and without this it will be problematic for
niche players like those with special-needs-related service offerings
to make it onto the playing field.

But given that the industry is still converging on what the security practices
are for that back-office bus, and there are Voice Browser operators with
successful experience using the techniques in the present appendix, it
makes reasonable sense to use this approach as an example to encourage
your readers to do something about security.

Al

/for [Janina and the rest of] the Protocols and Formats WG

>
>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, 6 April 2005 20:54:40 UTC