Re: More complete draft for Widgets: Access Requests

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