- From: Scott Wilson <scott.bradley.wilson@gmail.com>
- Date: Fri, 22 May 2009 10:17:26 +0100
- To: Arthur Barstow <art.barstow@nokia.com>
- Cc: public-webapps <public-webapps@w3.org>
Is there a particular preferred format for submitting use cases? S On 21 May 2009, at 14:55, Arthur Barstow wrote: > This is a Call for Inputs regarding Use Cases and Requirements for > the Widgets Access Requests spec: > > <http://dev.w3.org/2006/waf/widgets-access/> > > Please submit inputs before the May 28 widgets voice conference. > > -Regards, Art Barstow > > > Begin forwarded message: > >> From: ext Marcos Caceres <marcosc@opera.com> >> Date: May 21, 2009 8:19:12 AM EDT >> To: Thomas Roessler <tlr@w3.org> >> Cc: "Barstow Art (Nokia-CIC/Boston)" <Art.Barstow@nokia.com>, ext >> Robin Berjon <robin@berjon.com>, public-webapps WG <public-webapps@w3.org >> > >> Subject: Re: More complete draft for Widgets: Access Requests >> Reply-To: "marcosc@opera.com" <marcosc@opera.com> >> >> On Thu, May 21, 2009 at 2:01 PM, Thomas Roessler <tlr@w3.org> wrote: >>> On 21 May 2009, at 03:32, Arthur Barstow wrote: >>> >>>> One of the problems that at least Arve, Thomas and others have >>>> raised, is >>>> the lack of clear use case(s) and requirements. I think that >>>> information >>>> should be included in the FPWD. It would not only help the group >>>> work >>>> through the details of the model but would also help others >>>> understand the >>>> rationale and design of the model. >>> >>> Indeed. It'll be important to have a clear description of what >>> the spec is >>> supposed to achieve. That will also help to get proper review of >>> the >>> specificaton, both by the upcoming Deice API WG and externally. >>> >>>> Given BONDI has done some related security work, perhaps they >>>> have use >>>> case and requirements that can be used/leveraged. >>> >> >> For access, you might want to build on the following (from the >> Requirements doc, 52-54). In any case, use cases and requirements >> should go into the requirements doc. >> >> Default Security Policy >> A conforming specification MUST specify a default security policy >> that >> limits the privileges afforded to a widget at runtime. The default >> security policy MUST be specified in such a way that it forces a >> widget package to explicitly request permission to use particular >> device capabilities (see also the Security Declarations requirement). >> >> Motivation: >> Current development practice or industry best-practice and >> security. >> Rationale: >> To make the default behavior of a widget as benign as possible. >> For example, the default security policy might be that a widget >> cannot >> access the network. >> >> Widget Black/White Listing >> >> A conforming specification MAY specify a mechanism that allows a >> remote trusted authority to update black and/or white lists and the >> security policy related to widget packages installed on the widget >> user agent. >> >> Motivation: >> Current development practice or industry best-practice and >> security. >> Rationale: >> To provide the mechanisms that would enable the creation of >> trusted public authorities for widgets. These authorities could serve >> to authorize or revoke widget packages that other members of the >> community have found to exhibit undesirable aspects or malicious >> behavior, which could potentially damage an end-user's device or >> breach their privacy or security. >> >> Security Declarations >> >> A conforming specification MUST specify or recommend a means for >> declaring that an instantiated widget will require access to >> resources >> or services that have to the potential to introduce a security risk >> for an end user. A conforming specification SHOULD also make it >> possible to externalize and associate security declarations with a >> particular widget package (e.g., by allowing security declarations to >> be securely acquired from an external trusted authority over HTTP). >> This MUST include a means of declaring the APIs that a widget expects >> to access. When possible, a conforming specification MUST specify a >> means to verify the authenticity and integrity of security >> declarations included in the widget package (e.g. by using Digital >> Signatures). >> >> Motivation: >> Security, and current development practice or industry best- >> practice. >> Rationale: >> To declare the security intentions of the widget, allowing the >> widget user agent to, for example, confirm with the user before >> installing the widget, or adjust its policies before instantiating >> it. >> Example of security sensitive services that could require >> access-control include accessing end-user's storage device, or >> performing a cross-domain request. >> >> >> -- >> Marcos Caceres >> http://datadriven.com.au > >
Received on Friday, 22 May 2009 09:18:16 UTC