[widgets] Call for Input: Use Cases and Requirements for Widgets Access Request spec

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 Thursday, 21 May 2009 13:56:18 UTC