- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Tue, 27 Oct 2009 00:02:14 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/policy-reqs
In directory hutz:/tmp/cvs-serv32723
Added Files:
Overview.html
Log Message:
initial draft of policy requirements
--- NEW FILE: Overview.html ---
<!DOCTYPE html>
<html>
<head>
<title>Device API Policy Requirements</title>
<meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
<script src='../ReSpec.js/js/respec.js' class='remove'></script>
<script class='remove'>
var respecConfig = {
specStatus: "ED",
shortName: "dap-policy-reqs",
// publishDate: "2009-10-23",
// previousPublishDate: "1977-03-15",
edDraftURI: "http://dev.w3.org/2009/dap/policy-reqs/",
// lcEnd: "2009-08-05",
};
</script>
<script src='../common/configPolicy.js' class='remove'></script>
</head>
<body>
<section id='abstract'>
These are the requirements for the Policy work undertaken by the
DAP WG.
</section>
<section class='informative'>
<h2>Introduction</h2>
<p>
This document is an editors draft and currently does not
reflect consensus of the WG but rather is a starting point for
further work. It is based on input documents and list
discussion.
</p>
</section>
<section class='informative'>
<h2>Definitions</h2>
<p>The following definitions are used in this document.</p>
<dl>
<dt>application</dt>
<dd>Code that may make use of DAP APIs. This can be widgets, web
applications running in a browser, for example. </dd>
<dt>API<dt>
<dd>Collection of interfaces structured in terms of methods and
properties used by applications to access device
functionality. Related interfaces may be grouped into
modules. Interfaces may be defined using WebIDL. Note that
interfaces, by themselves, are not necessarily associated with a specific
device capability. For example, a Stream interface (providing serial read,
write and seek functionality) may be used to interact with a local file, or
a Bluetooth connection. Similarly, the DCCI API could be used to access a
wide range of different device capabilities through a common set of
interfaces.
</dd>
<dt>device capability</dt>
<dd>device resource or functionality requiring access
control. Examples of device capabilities are the ability to read a local
file, or to discover nearby Bluetooth devices, or to send an SMS
message. In principle, device capabilities can be defined in a way that is
independent of the specific APIs that an application uses to access
them. Note that a given API may require different
capabilities, as in this JavaME example:
Connector.open("file://sdcard/my_dog.jpg");
would use a "local filesystem" feature, whereas
Connector.open("btspp://<hostname>:<parameters>");
would use a "Bluetooth serial port profile" feature.
</dd>
<dt>feature</dt>
<dd> is ability to use capability for a specific API</dd>
</dl>
</section>
<section>
<h2>Out of Scope</h2>
<p>
</p>
<ul>
<li>The management of security policies ... is out of scope
(charter)</li>
<li>Identity Revocation</li>
</ul>
</section>
<section>
<h2>Security Framework</h2>
<section>
<h3>Requirements</h3>
<p>
</p>
<ul>
<li>The DAP security framework MUST NOT preclude different
authorities defining the security policy.
</li>
<li>Security Framework MUST be separable from policy
statements. Note that this may be a consequence of declarative
policy statements.</li>
<li>The Security Framework MUST allow multiple instantiations of a web
runtime with independent security decisions</li>
<li>The Security Framework MUST be application language
independent</li>
<li>The Security Framework MUST be Javascript capable and
define a Javascript binding</li>
<li>It MUST be possible to have separate policy decision and
enforcement points</li>
<li>The DAP security model SHOULD be compatible with the HTML 5
security model.</li>
</ul>
</section>
<section class='informative'>
<h3>Rationale</h3>
<p>
These may be considered assumptions, but affect the design
decision.
</p>
</section>
<section class='informative'>
<h3>Issues</h3>
<p>
</p>
</section>
</section>
<section>
<h2>Policy Definition</h2>
<section>
<h3>Requirements</h3>
<p>
</p>
<ul>
<li>Access control policy MUST be stated in declarative manner.</li>
<li>The DAP security framework MUST allow a flexible choice of
policy decisions for device capability and feature
access.</li>
<li>It MUST be possible to declare policy in XML
language</li>
<li>The DAP policy language MUST define an XML syntax for
that language.</li>
<li>It MUST be possible to provide integrity protection and
source authentication for policy.</li>
</ul>
</section>
<section class='informative'>
<h3>Rationale</h3>
<p>
These may be considered assumptions, but affect the design
decision.
</p>
</section>
<section class='informative'>
<h3>Issues</h3>
<p class="issue">
Features defined according to CRUD, one feature for Create,
Read, Update, Delete?
</p>
<p class="issue">
Feature parameters to avoid explosion of capabilities and
features? e.g. file open with either read or write
parameter.
( see
http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/att-0120/minutes-2009-10-07.html#item03 )
</p>
</section>
</section>
<section>
<h2>User Control over Decisions</h2>
<section>
<h3>Requirements</h3>
<p>
</p>
<ul>
<li>User Agents MUST NOT present modal dialogs to prompt users for security
decisions</li>
<li>Users SHOULD have control over general configuration of security
decisions</li>
</ul>
</section>
<section class='informative'>
<h3>Rationale</h3>
<p>
Prompts should be eliminated whenever possible. Many prompts do not provide
any meaningful security because:
<ul>
<li>they don't provide the user with the information needed to make an
informed security decision;</li>
<li>the user is inclined simply to dismiss the prompt and permit the operation
just because that's what's needed for the application to
continue.</li>
</ul>
</p><p>
If prompts are shown and dismissed as a matter of routine, then the user is
less inclined to take any security decision seriously, which further
undermines the effectiveness of a user-driven access control system.
</p><p>
There will unavoidably be situations, however, where the user is required to
make access control decisions when web applications wish to use sensitive
APIs. The key issue remains, therefore, and DAP needs to ensure a framework
is provided that allows it to happen, and maximizes its effectiveness,
rather than seeking to eliminate it altogether.
</p><p>
Modal prompts (i.e. prompts that block all other user interaction until
dismissed) seriously compromise user experience and are avoidable.
</p><p>
Any prompt or dialog that requests a user security decision at runtime (e.g.
at the time a sensitive action is attempted) can be non-modal if the API
that initiates it is asynchronous. DAP APIs must be designed so that all
operations that could potentially trigger a prompt are asynchronous.
</p><p>
If a sensitive operation requires some user interaction to initiate it (such
as choosing a file to upload, or pressing the shutter on a camera), then
this interaction can be arranged so that it is an implicit user
authorization. Whether or not this is possible depends on the operation or
API in question.
</p><p>
Given the wide range of possible valid means of eliciting user security
decisions, DAP should be minimally prescriptive about the user experience,
and should not assume that the same user experience is appropriate for every
API.
</p>
</section>
<section class='informative'>
<h3>Open Issues for Resolution</h3>
<ul>
<li> <p class='issue'>User authorization vs other policy authority</p>
<p>
<p class='issue'>
Support for trust models other than user security decisions needed?
</p>
This issue is who makes security decisions; in particular whether the user
is the sole authority for decisions (whether by configuration of settings,
or responses to prompts, or both) or there is another authority that
determines the rights given to an application.
</p><p>
Many existing ecosystems for mobile applications are based on a trust model
in which a particular distributor (such as a network operator) certifies an
application as trustworthy, eliminating run-time user prompts. This approach
avoids the disadvantages of prompts, but at the expense of taking legitimate
control away from the user. Other approaches, such as BONDI, do not
hard-code this type of trust model, but nonetheless provide for a policy
authority to determine an access control policy, and this policy can require
that certain decisions are made without reference to the user.
</p><p>
Although the role of any access control policy, and authority over it, are
beyond the scope of this particular issue, DAP's approach to prompting must
take these possibilities into account.
</li>
<li>Granularity of user decisions
<p class='issue'>
What is the correct granularity of security decisions presented to
user? Perhaps this should be stated in policy. What is the linkage to
application logic?
</p><p>
This issue is whether the user is presented with a single security decision
that covers multiple operations, or independent prompts for individual
operations. Blanket authorization for an application to use multiple APIs,
as often as required, eliminates run-time prompts but also may leave the
user without the context required to make a meaningful security decision.
Also, a user may not be prepared to give blanket approval for a certain
operation but may instead wish to give permission in specific circumstances
only.
</p><p>
DAP should not presuppose that an approach involving blanket permissions
only (e.g. implicit granting of blanket permission by allowing installation to
occur, or an explicit blanket permission given when the application is first
run) is the right answer. Both approaches have advantages for different use
cases and we should try to define a system that supports all use cases
effectively.
</p>
</li>
<li>Application control vs user agent control
<p class='issue'>
Does application or user agent or both determine which prompts are
presented to user?
</p>
<p>
This issue is whether the application, or the user agent, or both, have a
role in determining the extent to which prompts may appear, and at what
time.
</p><p>
Usually an application itself knows whether or not the user has implicitly
given permission for a particular operation. For example, after a user as
explicitly clicked the "send email now" button, he should not be faced with
a dialog saying "this application wishes to connect to the
network ....".
The user agent, by itself, cannot tell if the application has earned the
right to perform an operation without further explicit user acknowledgment,
so there is an argument for the application being able to influence whether
or not the UA intervenes with a prompt. This, of course, requires greater
trust in the application than would be necessary if the UA intervened
unconditionally.
</p><p>
DAP should determine whether or not there is a role that the application
itself can play in how and when security decisions are elicited explicitly
from the user.
</p>
</li>
</ul>
</section> <!-- open issues -->
</section> <!-- user control -->
<section>
<h2>Identification</h2>
<section>
<h3>Requirements</h3>
<p>
</p>
<ul>
<li>Capabilities MUST be defined for all sensitive device resources
and functionality.
</li>
<li>The security framework MUST support identifying device
capabilities
independently of API using IRIs.
</li>
<li>The security framework MUST support access control
decisions based on device capabilities,
independent of API
</li>
<li>The security framework MUST support access control
decisions based on device features (one or more capabilities
bound to a device API).
</li>
<li>The security framework MUST support sufficient granularity
for sensible access control decisions.
</li>
</ul>
</section>
<section class='informative'>
<h3>Rationale</h3>
<p>
Examples of device capabilities independent of API include the "read
local filesystem" device capability or the "geolocation" device
capability. A corresponding access control decision based on
capability alone is a policy stating that an application shall have
no access to geolocation, regardless of API used.
Examples of feature access control include a messaging API that permits
files to be attached to messages using
the "read local filesystem" device capability, or a camera API that
permits captured photos to be geotagged, using the
"geolocation" device capability.
</p>
<p>
Capabilities need to be defined portably. Examples of
granularity - a shared file needs to be distinguishable from an
application's private file, and a Bluetooth port needs to be distinguishable
from a USB serial port.
</p>
<p>Using IRIs to identify capabilities and features allows the
definition to be decentralized, allowing extensibility.
</p>
</p>
</section>
<section class='informative'>
<h3>Open Issues for Resolution</h3>
<p>
</p>
<p class='issue'>
Is access control at the feature level required or is access control
at the device capability level adequate?
</p>
<p class='issue'>
Define features by IRI and capabilities by string? e.g. BONDI identifies features by IRI, but defines a separate
namespace, centrally managed, for device capabilities (e.g.
device.io.file.read).
</p>
</section>
</section>
<section class='appendix'>
<h2>Acknowledgements</h2>
<p>
The editors would like to extend special thanks to Nokia, OMTP
BONDI, and PhoneGap for providing
the foundation of the working group's requirements discussion.
</p>
</section>
</body>
</html>
Received on Tuesday, 27 October 2009 00:02:15 UTC