RE: VBWG official response to last call issue

Al, Janina, Protocols and Formats WG,

Thanks for taking the time to discuss this issue further and for providing
your thoughtful response.

Sincerely,
Matt Oshry

-----Original Message-----
From: Al Gilman [mailto:Alfred.S.Gilman@ieee.org] 
Sent: Wednesday, April 06, 2005 12:33 PM
To: MattO
Cc: www-voice@w3.org; w3c-wai-pf@w3.org; janina@concerto.rednote.net
Subject: 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 19:55:59 UTC