W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

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

From: Scott Wilson <scott.bradley.wilson@gmail.com>
Date: Fri, 22 May 2009 10:17:26 +0100
Cc: public-webapps <public-webapps@w3.org>
Message-Id: <6834B9FE-A131-4623-B409-3B1F74AEE513@gmail.com>
To: Arthur Barstow <art.barstow@nokia.com>
Is there a particular preferred format for submitting use cases?


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:53 UTC