- From: Marcos Caceres <marcosc@opera.com>
- Date: Thu, 21 May 2009 14:19:12 +0200
- To: Thomas Roessler <tlr@w3.org>
- Cc: Arthur Barstow <art.barstow@nokia.com>, ext Robin Berjon <robin@berjon.com>, public-webapps WG <public-webapps@w3.org>
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 Thursday, 21 May 2009 12:20:20 UTC