Update of /sources/public/2009/dap/policy-reqs
In directory hutz:/tmp/cvs-serv23357
Modified Files:
FPWD.html
Added Files:
FPWD-src.html
Log Message:
update sotd, publication date, fix for Note track
--- NEW FILE: FPWD-src.html ---
<!DOCTYPE html>
<html>
<head>
<title>Device API Access Control Requirements</title>
<meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
<script src='http://dev.w3.org/2009/dap/ReSpec.js/js/respec.js' class='remove'></script>
<script class='remove'>
var respecConfig = {
specStatus: "FPWD",
shortName: "dap-policy-reqs",
publishDate: "2010-06-29",
// previousPublishDate: "1977-03-15",
edDraftURI: "http://dev.w3.org/2009/dap/policy-reqs/",
// lcEnd: "2009-08-05",
noRecTrack: true,
};
</script>
<script src='http://dev.w3.org/2009/dap/common/configPolicy.js' class='remove'></script>
</head>
<body>
<section id='abstract'>
This document defines Device API Access Control Requirements
and the corresponding use cases.
</section> <!-- abstract -->
<section id='sotd'>
This document is expected to be further updated based on both Working
Group input and public comments. The Working Group anticipates to
eventually publish a stabilized version of this document as a W3C
Working Group Note.
</section>
<section id='introduction'>
<h2>Introduction</h2>
<p>
The DAP working group is defining APIs designed to enable
application access to device resources, including personal
contact information such as calendar and contacts information,
system information such as network information, and other
information. Much of this information is sensitive and
potentially misused. For this reason the DAP working group
charter explicitly calls out the need to control access to
this information, such as through the use of policy.
</p>
<p>
This is complicated by constraints in two dimensions, end user
affiliation and application type. </p>
<p>End user affiliation plays a role in determining what a user is
allowed to do. An end user might
be an employee of a corporation or subscriber to
an operator network. In either case, the corporation or
network operator may wish to set constraints on what
applications the user accesses may do, by defining and using
an access control policy. Alternatively a user may not be
acting as an employee and not subject to network operator
constraints (at least for now with many Internet connections),
but may wish to personally control what Internet applications are
allowed to do.
</p>
<p>
Second, there are two types of application under consideration by the
DAP WG. First, there are W3C widgets, applications that are created
with certain constraints, that might be signed by a source, enabling
source authentication. Second are full web applications, which may
come from any web site the user may access. These two types of
applications present different challenges and constraints.
</p>
<p>
Taken together, these two cases provide four different possibilities.
</p>
<table class="simple">
<tr><th>Model/Environment</th><th>Widget</th><th>Web</th></tr>
<tr><td>User Controlled</td><td>Explicit permission by
dialog, policy with trust based on signed widget or secured installation</td><td>Explicit permission by dialog, user
mediated introduction, distributed trust mechanisms like OAuth (?)</td></tr>
<tr><td>Enterprise/Operator</td><td>Policy, Trust based on signed
widget or secured installation</td><td>Policy with trust based on Federated
Identity</td></tr>
</table>
</section> <!-- introduction -->
<section id='definitions'>
<h2>Definitions</h2>
<p>The following definitions are used in this document.</p>
<dl>
<dt>Access Control</dt>
<dd><p>Controlled access to functionality or resources by a
policy enforcement point based on rules defining which
access is permitted. Enforcement can occur at runtime when
supported by the API framework and is supported by
applications declaring needed access.
</p>
</dd>
<dt>Application</dt>
<dd><p>An application is code that may make use of DAP Device
APIs. For the purposes of DAP, such applications are either
Javascript code contained in a web page or a W3C Widget.
</p></dd>
<dt>Device API</dt>
<dd><p>A Device API is a collection of Javascript interfaces
structured in
terms of methods and properties. Device APIs are used by
applications to access Device
Capabilities.</p>
</dd>
<dt>Device Capability</dt>
<dd><p>A Device Capability is device
functionality or device resource(s) exposed by standardized
APIs.
</p></dd>
<dd> Examples of device capabilities are the ability to
read a local
file, or to discover nearby Bluetooth devices, or to send an
SMS
message. Device Capabilities may be defined
in a way that is
independent of the specific Device APIs that an application
uses to access
them.
</dd>
<dd><p>
Although there are simple Device APIs that provide access only to
a single Device Capability, there are also
more complex APIs that expose multiple Device Capabilities; examples
might include a camera API that provides the ability to geotag a photo
with the current location, or a messaging API that provides the
ability to access documents stored locally and attach them to outgoing
messages. Therefore, enabling or disabling access to a specific Device
Capability may not directly correspond to enabling or disabling
access to a single Device API interface.</p>
</dd>
<dt>Consent</dt>
<dd><p>Consent is a user action that indicates that the user agrees
with an action, such as using an API to expose information to an
application. Such consent may be explicit or implicit.
</p></dd>
<dd><p>Explicit consent is a user action directly related to
a query for the user's consent, for an
action to be taken by the application, or for an
application lifecycle
action. An example of explicit consent for an application
action is a
positive user response to a query by the web runtime,
asking whether an
application should be allowed to take a
photograph. Examples of explicit
consent for an application lifecycle action include a positive user
response to a query by:</p>
<ul>
<li>A positive user response to a query by the web runtime upon
application installation, asking whether an explicitly
disclosed set of
API requests by the application should be allowed.</li>
<li>A positive user response to a query by the application
storefront upon application selection and download,
asking whether an
explicitly disclosed set of API requests by the
application should be
allowed.</li>
</ul>
</dd>
<dd><p>Implicit Consent occurs when a user takes an action that
implies their desire to have an action occur, implying
permission for needed resources.
An example is pressing a camera
shutter to take a photograph, implying consent to the act of
taking a photograph.</p></dd>
</dl>
</section> <!-- definitions -->
<section id="user-control">
<h2>User Managed Access</h2>
<p>This section outlines use cases and requirements to support
user controlled access control.</p>
<section>
<h4>Use case PM1: user-controlled configuration</h4>
<p>
In this use-case:
</p>
<ul>
<li>
the user of a device is the sole authority that decides
access rights of
applications;
</li>
<li>
there is a "universal default" initial policy configuration;
</li>
<li>
there is no external policy authority and hence no
externally-triggered
policy update. Policy maintenance occurs only to the extent
that the user
modifies configuration settings interactively via a
"preferences" facility, or
asks the UA to remember certain responses to prompts.
</li>
</ul>
<p>
This use-case is the expected case in most situations where
there is no
external policy authority such as a network operator or enterprise.
</p>
<p>
Although the initial configuration is "empty" (ie it only
contains universal
default rules), it is possible for the policy to be extended
over time as the
cumulative result of explicit user configuration and
persistently remembered
user decisions
</p>
<p>
The configured policy, at any given time, may be stored
locally on the device
or may be stored remotely and be accessible via a network
service, or both.
</p>
</section> <!-- PM1 -->
<section>
<h4>Use case PM2: user-delegated configuration</h4>
<p>
In this use-case:
</p>
<ul>
<li>
the user of a device delegates authority for access control
policy to an
external service provider;
</li>
<li>
the external service provider provides advice on the
trustworthiness of
specific applications, and determines an access control
policy that embodies
that advice. The advice may be based on a knowledgebase of
known trustworthy
and/or malicious applications, or algorithms for detecting malicious
behavior, or both;
</li>
<li>
the policy defined by the external authority is updated
regularly in
response to new information on known threats.
</li>
</ul>
<p>
The policy configuration provided by the external policy
provider may be
supplemented by user control as in PM1.
</p>
<p>
The configured policy, at any given time, may be stored
locally on the device
or may be stored remotely and be accessible via a network
service, or both.
</p>
<p>
This use-case mirrors current practice with products such as
virus scanners or
other malware detectors.
</p>
</section> <!-- PM2 -->
<section>
<h4>Use case PI2: portability of user settings</h4>
<p>
A user may establish a policy configuration (through explicit
configuration of
preferences, and remembered decisions) and there is the option
of reusing this
configuration across multiple devices. A user with multiple
devices may wish
for their security preferences to be consistent (or to at
least have the
option of consistency) across those devices. Rather than have
to manually
configure the preferences on each device, it should be
possible for there to
be a seamless security experience across devices, e.g. by
switching SIM card
between devices and as a result automatically applying a
policy resident on
the SIM card or synchronizing with a network-based policy
management system. A
specific case is the case where a user wishes to transfer a
configuration from
an old device to a new device. This is relevant to Policy
Management use cases
PM1, PM2, PM3.
</p>
</section> <!-- PI2 -->
<section>
<h4>Prompts</h4>
<p>
Prompts should be eliminated whenever possible. Many prompts
do not provide
any meaningful security because:</p>
<ul>
<li>they don't provide the user with the information
needed to make an
informed security decision;</li>
<li>with modal prompts, 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>
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>
It is important to note that modal prompts (i.e. prompts
that block all other user
interaction until
dismissed) seriously compromise the user experience. Modal
security prompts SHOULD be avoided.
</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 user decisions
are themselves expressible in the policy language, then they can be
&quot;remembered&quot; by
adding a policy-set and/or rule to the policy. Similarly, user
configuration settings should be possible in the policy
language. This means that the policy document is not just a
way of creating
an initial policy configuration, but can be the sole and complete
representation of the access control configuration at any time.
</p>
<div class="issue">
<ul>
<li> <p class='issue'>User authorization vs other
policy authority</p>
<p class='issue'>
Support for trust models other than user security
decisions needed?
</p>
<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 in some cases. This approach
avoids the disadvantages of prompts, but at the expense
of taking real-time
control away from the user in those cases. 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.</p>
</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. Different permission granularities have
advantages for different use
cases and we should require a system that supports
all use cases
effectively.
DAP should follow industry practice
in these cases, and provide permission granularities
consistent with
those widely deployed in the mobile market.
</p>
</li>
</ul>
</div>
</section> <!-- prompts -->
<section id='user-control-rqmts'>
<h3>User Control Requirements</h3>
<ul>
<li>The security framework MUST NOT require User Agents to
present modal dialogs to prompt users for security
decisions, while the application is running.
<ul><li>Note: modal dialogs may be required
for security prompts provided during application
installation or invocation.</li></ul>
</li>
<li>The security framework SHOULD allow users to have control
over general configuration of security
decisions</li>
<li>The security policy framework SHOULD make it possible to record
security configuration choices and interactive policy
decisions using the policy markup language format.</li>
</ul>
</section>
<section id="portable-policy">
<h2>Portable Policy</h2>
<p>
It should be possible for policy to be defined in a portable
device-independent manner.
</p>
<ul>
<li>Security Framework MUST be separable from policy
statements. Note that this may be a consequence of declarative
policy statements.</li>
<li>Access control policy MUST be stated in declarative manner.</li>
<li>The DAP policy language MUST define an XML syntax for
that language.</li>
</ul>
<p>
</p>
</section> <!-- portable -->
</section> <!-- user control -->
<section>
<h2>Enterprise Managed Access</h2>
<p>This section outlines use cases and requirements to support
enterprise or network operator managed access control.</p>
<section>
<h4>Use case PM3: external policy authority</h4>
<p>
In this use case:
</p>
<ul>
<li>
an external body has authority over the device and, in particular, security
policy configuration.
</li>
<li>
an initial security policy configuration may be provided by the external
authority, together with any other associated device configuration (such as
root certificates). The configured policy may determine access control policy
without reference to the user, or may refer certain decisions to the user.
</li>
<li>
the policy may be updated periodically under the authority of the policy
authority. Policy maintenance may also occur as the cumulative effect of
certain user decisions being remembered.
</li>
</ul>
<p>
The external policy authority may configure the policy as part of the
commissioning of the device (eg a network operator's configuration applied by
the manufacturer prior to sale, or an enterprise configuring device policy
using a secured device management interface).
</p>
<p>
In determining the policy, the policy authority has the opportunity to define
a policy that supports a specific objective - such as to limit access to APIs
to only those web applications that are themselves distributed by the policy
authority (eg to control its exposure to the financial risk of abuse of device
APIs).
</p>
</section> <!-- PM3 -->
<section>
<h4>Use case PI1: device-independent policy definition</h4>
<p>
In this case case, a single policy authority wishes to define and configure a
security policy for multiple dissimilar devices. A typical network operator's
portfolio many include tens or even hundreds of models, each based on
different platforms, and different UAs. A commonly supported interoperable
format for configuration of a policy dramatically impacts the practicality of
achieving the desired configuration across all devices. This is relevant to
Policy Management use case PM3.
</p>
</section> <!-- PI1 -->
<section>
<h4>Use case PI3: policy provisioning as part of service deployment</h4>
<p>
Configuration of some parts of access control policy may be part of the
overall configuration required to enable a particular application or service.
This, along with many other configuration parameters, may be remotely
configurable via device management. The configuration required to enable a
service may be provided by the service provider as a policy fragment, to be
added to the overall policy by the policy authority. An interoperable
representation of such policy fragments would enable this to be done without
authoring the configuration updates separately for each target device,
platform, or UA.
</p>
</section> <!-- PI3 -->
<section>
<h3>Policy interoperability</h3>
<p>
These use cases relate to reading and writing of policy definitions in an
interoperable format.
</p>
</section>
<section>
<h3>Enterprise Requirements</h3>
<p>
</p>
</section>
</section>
<section>
<h3>Abuse Cases</h3>
<p>
This section outlines some abuse cases for misuse of APIs.
</p>
<p>
The landscape that is being created is the enablement of
cross-platform, cross-device, easy to develop, highly functional
applications based on browser technology that has been proven
repeatedly to be untrustworthy - a perfect recipe for evil. Will
this meet all the criteria for really successful malware on
mobile devices for example?
</p>
<p>
Up until now the measures taken by the mobile industry have
proven highly successful in ensuring no major malware incident
has affected the industry. There have been attempts: the
MMS-spreading Commwarrior is probably the most infamous, along
with the Spyware tool, Flexispy. An additional factor in
ensuring the success of mobile security has been the fact that
mobile platforms have been too fragmented and complex, therefore
not representing an attractive target so far. Existing modus
operandi from technology-related attacks can provide indicators
as to the types of attack and abuse that can be expected on
widgets and web applications as device APIs are opened up.
</p>
<section id="premium-rate-abuse">
<h2>Abuse Case AC1: Premium Rate Abuse</h2>
<p>A widget that seems benign but is actually spewing out
SMSs to premium rate numbers without the user