- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 23 Jun 2010 16:28:37 +0000
- To: public-dap-commits@w3.org
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
"remembered" 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’s
knowledge. This could be modified from an original safe
widget such as a game. For the malware author, the key
piece to solve is to dupe the user into thinking that the
SMS capability is something that is part of the original
application. Examples of this have been seen in the past,
created from games and this model could be used for
‘diallers’ too (which plagued the desktop world in the
days of dial-up networking). There have been recent
warnings about this kind of abuse from security firms.
</p>
</section> <!-- premium rate Abuse -->
<section id="privacy-breach">
<h3>Abuse Case AC2: Privacy Breach</h3>
<p>An application that gains access to locations, contacts
and gallery, silently uploading the data in the background
to a site owned by the attacker. This is something that
has been a clear goal for attackers already. There have
been numerous high-profile examples in the past in the
mobile world. Celebrities such as Paris Hilton, Miley
Cyrus and Lindsay Lohan have all had private pictures,
phone numbers and voicemails stolen from devices or
networks in clear breach of their privacy. There has been
embarrassment for teachers who had their pictures and
videos copied by the children in their class and spread
around school. The most high-profile case in the UK of a
mobile related privacy breach was that of the News of the
World's use of voicemail hacking to gain access to private
information about Royalty. The Royal editor, Clive Goodman
was jailed for four months and the editor, Andy Coulson
resigned over this blatant privacy breach. Given the
appetite for breaching privacy, users need to be safe in
the knowledge that their personal data will not leak in
any way.
</p>
</section> <!-- privacy-breach -->
<section id="integrity-breach">
<h3>Abuse Case AC3: Integrity Breach</h3>
<p>A widget that replaces the voicemail number with a
premium rate number instead? There are number of reasons
why an attacker would want to breach the integrity of
the device. Simply changing the telephone number of the
voicemail that is stored on the device could be enough
to make an attacker a lot of money. Users usually have a
shortcut key to their voicemail and may not notice for a
long time that anything is wrong. A more sinister use
could be to plant evidence on a device. Pictures, files
and even criminal contacts could potentially be
anonymously planted all without the user's consent or
knowledge. Proving innocence could suddenly become very
difficult.
There are also a number of reasons why somebody would want to steal
data. The contents of corporate e-mails would be very
interesting to a competitor, as would sabotaging data
stored in spreadsheets and presentations on the target
phone.
</p>
</section> <!-- integrity-breach -->
<section id="phishing">
<h3>Abuse Case AC4: Phishing</h3>
<p>A widget that replaces the voicemail number with a
premium rate number instead? There are number of reasons
why an attacker would want to breach the integrity of
the device. Simply changing the telephone number of the
voicemail that is stored on the device could be enough
to make an attacker a lot of money. Users usually have a
shortcut key to their voicemail and may not notice for a
long time that anything is wrong. A more sinister use
could be to plant evidence on a device. Pictures, files
and even criminal contacts could potentially be
anonymously planted all without the user's consent or
knowledge. Proving innocence could suddenly become very
difficult.
There are also a number of reasons why somebody would want to steal
data. The contents of corporate e-mails would be very
interesting to a competitor, as would sabotaging data
stored in spreadsheets and presentations on the target
phone.
</p>
</section> <!-- phishing -->
</section> <!-- Abuse -->
<section>
<h2>Capabilities</h2>
<p>
Declarative policy is used for access control decisions for various
capabilities, such as actions that may be performed, as invoked by
specific API calls for example.
</p>
<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>
<section id="policy-capability-requirements">
<h2>Capability Requirements</h2>
<ul>
<li>Capabilities MUST be defined for all sensitive device resources
and functionality.
</li>
<li>Capabilities MUST be identified by strings associated
with API definitions produced by the DAP WG.
</li>
</ul>
</section>
<section>
<h3>Issue - Features, relationship to capabilities, CRUD</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
<a href="http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/att-0120/minutes-2009-10-07.html#item03">discussions in minutes of October 7 call</a> )
</p>
</section> <!-- Policy Definition Requirements issues -->
</section>
<section id="framework">
<h2>Security Framework</h2>
<section id="framework-rqmts">
<h2>Security Framework Requirements</h2>
<section id="policy-integrity-requirements">
<h2>Policy Integrity Requirements</h2>
<p>It should be possible for policy to be integrity protected during
various points in its life-cycle.</p>
<ul>
<li>It MUST be possible to provide integrity protection and
source authentication for policy.</li>
</ul>
</section>
<ul>
<li>The DAP security framework MUST NOT preclude different
authorities defining the security policy.
</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
same origin policy.</li>
</ul>
</section> <!-- security framework requirements -->
<section>
<h2>Access Control Requirements</h2>
<ul>
<li>Access control decisions may be made at both the
granularity of Features
and Device Capabilities.
</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 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>
<p class='issue'>
( see <a href="http://www.w3.org/2009/dap/track/issues/21">ISSUE-21 - OPEN</a> ) Is access control at the feature level required or is access control
at the device capability level adequate?
</p>
</section> <!-- access control requirements -->
</section> <!-- requirements -->
<section>
<h3>Examples of statements or rules that may be expressed in a policy</h3>
<p>
These use cases are specific examples of statements or rules that may be
expressed in a policy.
</p>
<ul>
<li>
A widget whose signature chains to operator root can read and write
from the PIM databases.
</li><li>
A widget downloaded from <code>weather.example.com</code> can access
geolocation coordinates if the user says it’s OK.
</li><li>
The <code>weather.example.com</code> widget can connect to
<code>weather.example.com</code> without
notifying the user, except when roaming.
</li><li>
All widgets with a reliably identified author can save data
persistently if the user says it’s OK.
</li><li>
No widget can get my location, no matter who trusts it.
</li><li>
No widget can access <code>evil.example.org</code>.
</li><li>
An unsigned widget cannot launch another application without user
consent.
</li>
</ul>
<p>Example web site use cases, to give examples of the types of
policy that might be expressed:</p>
<ul>
<li>
A reliably identified website can access geolocation
coordinates if the
user confirms it’s OK.
</li><li>
Any website in a subdomain
of <code>mynetwork.example.com</code> can read phone
status
properties.
</li><li>
Reliably identified websites can send and receive SMS
except to premium
rate numbers.
</li><li>
<code>evil.example.com</code> cannot access any device APIs.
</li><li>
The <code>weather.example.com</code> <var>foo</var> widget
can access geolocation coordinates but
only if it’s embedded on the <var>foo</var> home page.
</li>
</ul>
</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 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>
Index: FPWD.html
===================================================================
RCS file: /sources/public/2009/dap/policy-reqs/FPWD.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- FPWD.html 16 Jun 2010 19:27:31 -0000 1.1
+++ FPWD.html 23 Jun 2010 16:28:35 -0000 1.2
@@ -6,11 +6,18 @@
- <link href="http://www.w3.org/StyleSheets/TR/W3C-WD" rel="stylesheet" type="text/css" charset="utf-8"></head><body style="display: inherit; "><div class="head"><p><a href="http://www.w3.org/"><img width="72" height="48" src="http://www.w3.org/Icons/w3c_home" alt="W3C"></a></p><h1 class="title" id="title">Device API Access Control Requirements</h1><h2 id="w3c-working-draft-16-june-2010"><acronym title="World Wide Web Consortium">W3C</acronym> Working Draft 16 June 2010</h2><dl><dt>This version:</dt><dd><a href="http://www.w3.org/TR/2010/WD-dap-policy-reqs-20100616/">http://www.w3.org/TR/2010/WD-dap-policy-reqs-20100616/</a></dd><dt>Latest published version:</dt><dd><a href="http://www.w3.org/TR/dap-policy-reqs/">http://www.w3.org/TR/dap-policy-reqs/</a></dd><dt>Latest editor's draft:</dt><dd><a href="http://dev.w3.org/2009/dap/policy-reqs/">http://dev.w3.org/2009/dap/policy-reqs/</a></dd><dt>Editors:</dt><dd>Laura Arribas, <a href="http://vodafone.com/">Vodafone</a></dd><dd>Paddy Byers, <a href="http://apix.com/">Aplix</a></dd><dd>Marcin Hanclik, <a href="http://access-company.com/">ACCESS Co., Ltd.</a></dd><dd>Frederick Hirsch, <a href="http://nokia.com/">Nokia</a></dd><dd>David Rogers, <a href="http://omtp.org/">OMTP</a></dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2010 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium"><acronym title="World Wide Web Consortium">W3C</acronym></acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology"><acronym title="Massachusetts Institute of Technology">MIT</acronym></acronym></a>, <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. <acronym title="World Wide Web Consortium">W3C</acronym> <a href="ttp://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p><hr></div>
+ <link href="http://www.w3.org/StyleSheets/TR/W3C-WD" rel="stylesheet" type="text/css" charset="utf-8"></head><body style="display: inherit; "><div class="head"><p><a href="http://www.w3.org/"><img width="72" height="48" src="http://www.w3.org/Icons/w3c_home" alt="W3C"></a></p><h1 class="title" id="title">Device API Access Control Requirements</h1><h2 id="w3c-working-draft-29-june-2010"><acronym title="World Wide Web Consortium">W3C</acronym> Working Draft 29 June 2010</h2><dl><dt>This version:</dt><dd><a href="http://www.w3.org/TR/2010/WD-dap-policy-reqs-20100629/">http://www.w3.org/TR/2010/WD-dap-policy-reqs-20100629/</a></dd><dt>Latest published version:</dt><dd><a href="http://www.w3.org/TR/dap-policy-reqs/">http://www.w3.org/TR/dap-policy-reqs/</a></dd><dt>Latest editor's draft:</dt><dd><a href="http://dev.w3.org/2009/dap/policy-reqs/">http://dev.w3.org/2009/dap/policy-reqs/</a></dd><dt>Editors:</dt><dd>Laura Arribas, <a href="http://vodafone.com/">Vodafone</a></dd><dd>Paddy Byers, <a href="http://ww.aplix.com/">Aplix</a></dd><dd>Frederick Hirsch, <a href="http://www.nokia.com/">Nokia</a></dd><dd>David Rogers, <a href="http://omtp.org/">OMTP</a></dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2010 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium"><acronym title="World Wide Web Consortium">W3C</acronym></acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology"><acronym title="Massachusetts Institute of Technology">MIT</acronym></acronym></a>, <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. <acronym title="World Wide Web Consortium">W3C</acronym> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability<a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p><hr></div>
<div id="abstract" class="introductory section"><h2>Abstract</h2>
This document defines Device API Access Control Requirements
and the corresponding use cases.
- </div><div id="sotd" class="introductory section"><h2>Status of This Document</h2><p><em>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current <acronym title="World Wide Web Consortium">W3C</acronym> publications and the latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/"><acronym title="World Wide Web Consortium">W3C</acronym> technical reports index</a> at http://www.w3.org/TR/.</em></p><p>This document was published by the <a href="http://www.w3.org/2009/dap/">Device APIs and Policy Working Group</a> as a First Public Working Draft. This document is intended to become a <acronym title="World Wide Web Consortium">W3C</acronym> Recommendation. If you wish to make comments regarding this document, please send them to <a href="mailto:public-device-apis@w3.org">public-device-apis@w3.org</a> (<a href="mailto:public-device-apis-request@w3.org?subject=subscribe">subscribe</a>,<a href="http://lists.w3.org/Archives/Public/public-device-apis/">archives</a>). All feedback is welcome.</p><p>Publication as a Working Draft does not imply endorsement by the <acronym title="World Wide Web Consortium">W3C</acronym> Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.</p><p>This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <acronym title="World Wide Web Consortium">W3C</acronym> Patent Policy</a>. <acronym title="World Wide Web Consortium">W3C</acronym> maintains a <a href="http://www.w3.org/2004/01/pp-impl/43696/status" rel="disclosure">public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes cntains <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the <acronym title="World Wide Web Consortium">W3C</acronym> Patent Policy</a>.</p></div><div id="toc" class="section"><h2 class="introductory">Table of Contents</h2><ul class="toc"><li class="tocline"><a href="#introduction" class="tocxref"><span class="secno">1. </span>Introduction</a></li><li class="tocline"><a href="#definitions" class="tocxref"><span class="secno">2. </span>Definitions</a></li><li class="tocline"><a href="#user-control" class="tocxref"><span class="secno">3. </span>User Managed Access</a><ul class="toc"><li class="tocline"><a href="#use-case-pm1--user-controlled-configuration" class="tocxref"><span class="secno">3.1 </span>Use case PM1: user-controlled configuration</a></li><li class="tocline"><a href="#use-case-pm2--user-delegated-configuratin" class="tocxref"><span class="secno">3.2 </span>Use case PM2: user-delegated configuration</a></li><li class="tocline"><a href="#use-case-pi2--portability-of-user-settings" class="tocxref"><span class="secno">3.3 </span>Use case PI2: portability of user settings</a></li><li class="tocline"><a href="#prompts" class="tocxref"><span class="secno">3.4 </span>Prompts</a></li><li class="tocline"><a href="#user-control-rqmts" class="tocxref"><span class="secno">3.5 </span>User Control Requirements</a></li><li class="tocline"><a href="#portable-policy" class="tocxref"><span class="secno">3.6 </span>Portable Policy</a></li></ul></li><li class="tocline"><a href="#enterprise-managed-access" class="tocxref"><span class="secno">4. </span>Enterprise Managed Access</a><ul class="toc"><li class="tocline"><a href="#use-case-pm3--external-policy-authority" class="tocxref"><span class="secno">4.1 </span>Use case PM3: external policy authority</a></li><li class="tocline"><a href="#use-case-pi1--device-independent-policy-defiition" class="tocxref"><span class="secno">4.2 </span>Use case PI1: device-independent policy definition</a></li><li class="tocline"><a href="#use-case-pi3--policy-provisioning-as-part-of-service-deployment" class="tocxref"><span class="secno">4.3 </span>Use case PI3: policy provisioning as part of service deployment</a></li><li class="tocline"><a href="#policy-interoperability" class="tocxref"><span class="secno">4.4 </span>Policy interoperability</a></li><li class="tocline"><a href="#enterprise-requirements" class="tocxref"><span class="secno">4.5 </span>Enterprise Requirements</a></li></ul></li><li class="tocline"><a href="#abuse-cases" class="tocxref"><span class="secno">5. </span>Abuse Cases</a><ul class="toc"><li class="tocline"><a href="#premium-rate-abuse" class="tocxref"><span class="secno">5.1 </span>Abuse Case AC1: Premium Rate Abuse</a></li><li class="tocline"><a href="#privacy-breach" class="tocxref"><span class="secno">5.2 </span>Abuse Case AC2: Privacy Breach</a></li><li class="tocline"><a hrf="#integrity-breach" class="tocxref"><span class="secno">5.3 </span>Abuse Case AC3: Integrity Breach</a></li><li class="tocline"><a href="#phishing" class="tocxref"><span class="secno">5.4 </span>Abuse Case AC4: Phishing</a></li></ul></li><li class="tocline"><a href="#capabilities" class="tocxref"><span class="secno">6. </span>Capabilities</a><ul class="toc"><li class="tocline"><a href="#policy-capability-requirements" class="tocxref"><span class="secno">6.1 </span>Capability Requirements</a></li><li class="tocline"><a href="#issue---features--relationship-to-capabilities--crud" class="tocxref"><span class="secno">6.2 </span>Issue - Features, relationship to capabilities, CRUD</a></li></ul></li><li class="tocline"><a href="#framework" class="tocxref"><span class="secno">7. </span>Security Framework</a><ul class="toc"><li class="tocline"><a href="#framework-rqmts" class="tocxref"><span class="secno">7.1 </span>Security Framework Requirements</a><ul class="toc"><li class="tocline"><a href="#policy-integrity-equirements" class="tocxref"><span class="secno">7.1.1 </span>Policy Integrity Requirements</a></li></ul></li><li class="tocline"><a href="#access-control-requirements" class="tocxref"><span class="secno">7.2 </span>Access Control Requirements</a></li></ul></li><li class="tocline"><a href="#examples-of-statements-or-rules-that-may-be-expressed-in-a-policy" class="tocxref"><span class="secno">8. </span>Examples of statements or rules that may be expressed in a policy</a></li><li class="tocline"><a href="#out-of-scope" class="tocxref"><span class="secno">9. </span>Out of Scope</a></li><li class="tocline"><a href="#acknowledgements" class="tocxref"><span class="secno">A. </span>Acknowledgements</a></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">B. </span>References</a><ul class="toc"><li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">B.1 </span>Normative references</a></li><li class="tocline"><a href="#informative-references" class="tocxre"><span class="secno">B.2 </span>Informative references</a></li></ul></li></ul></div> <!-- abstract -->
+ </div><div id="sotd" class="introductory section"><h2>Status of This Document</h2><p><em>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current <acronym title="World Wide Web Consortium">W3C</acronym> publications and the latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/"><acronym title="World Wide Web Consortium">W3C</acronym> technical reports index</a> at http://www.w3.org/TR/.</em></p>
+ 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 <acronym title="World Wide Web Consortium">W3C</acronym>
+ Working Group Note.
+ <p>This document was published by the <a href="http://www.w3.org/2009/dap/">Device APIs and Policy Working Group</a> as a First Public Working Draft. If you wish to make comments regarding this document, please send them to <a href="mailto:public-device-apis@w3.org">public-device-apis@w3.org</a> (<a href="mailto:public-device-apis-request@w3.org?subject=subscribe">subscribe</a>, <a href="http://lists.w3.org/Archives/Public/public-device-apis/">archives</a>). All feedback is welcome.</p><p>Publication as a Working Draft does not imply endorsement by the <acronym title="World Wide Web Consortium">W3C</acronym> Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.</p><p>This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <acronym title="World Wide Web Consortium">W3C</acronym> Patent Policy</a. The group does not expect this document to become a <acronym title="World Wide Web Consortium">W3C</acronym> Recommendation. <acronym title="World Wide Web Consortium">W3C</acronym> maintains a <a href="http://www.w3.org/2004/01/pp-impl/43696/status" rel="disclosure">public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the <acronym title="World Wide Web Consortium">W3C</acronym> Patent Policy</a>.</p></div><div id="toc" class="section"><h2 class="introductory">Table of Contents</h2><ul class="toc"><li class="tocline"><a href="#introduction" class="tocxref"><span class="secno">1 </span>Introduction</a></li><li class="tocline"><a href="#definitions" class="tocxref"><span class="secno">2. </span>Definitions</a></li><li class="tocline"><a href="#user-control" class="tocxref"><span class="secno">3. </span>User Managed Access</a><ul class="toc"><li class="tocline"><a href="#use-case-pm1--user-controlled-configuration" class="tocxref"><span class="secno">3.1 </span>Use case PM1: user-controlled configuration</a></li><li class="tocline"><a href="#use-case-pm2--user-delegated-configuration" class="tocxref"><span class="secno">3.2 </span>Use case PM2: user-delegated configuration</a></li><li class="tocline"><a href="#use-case-pi2--portability-of-user-settings" class="tocxref"><span class="secno">3.3 </span>Use case PI2: portability of user settings</a></li><li class="tocline"><a href="#prompts" class="tocxref"><span class="secno">3.4 </span>Prompts</a></li><li class="tocline"><a href="#user-control-rqmts" class="tocxref"><span class="secno">3.5 </span>User Control Requirements</a></li><li lass="tocline"><a href="#portable-policy" class="tocxref"><span class="secno">3.6 </span>Portable Policy</a></li></ul></li><li class="tocline"><a href="#enterprise-managed-access" class="tocxref"><span class="secno">4. </span>Enterprise Managed Access</a><ul class="toc"><li class="tocline"><a href="#use-case-pm3--external-policy-authority" class="tocxref"><span class="secno">4.1 </span>Use case PM3: external policy authority</a></li><li class="tocline"><a href="#use-case-pi1--device-independent-policy-definition" class="tocxref"><span class="secno">4.2 </span>Use case PI1: device-independent policy definition</a></li><li class="tocline"><a href="#use-case-pi3--policy-provisioning-as-part-of-service-deployment" class="tocxref"><span class="secno">4.3 </span>Use case PI3: policy provisioning as part of service deployment</a></li><li class="tocline"><a href="#policy-interoperability" class="tocxref"><span class="secno">4.4 </span>Policy interoperability</a></li><li class="tocline"><a href="#enterprise-requiremnts" class="tocxref"><span class="secno">4.5 </span>Enterprise Requirements</a></li></ul></li><li class="tocline"><a href="#abuse-cases" class="tocxref"><span class="secno">5. </span>Abuse Cases</a><ul class="toc"><li class="tocline"><a href="#premium-rate-abuse" class="tocxref"><span class="secno">5.1 </span>Abuse Case AC1: Premium Rate Abuse</a></li><li class="tocline"><a href="#privacy-breach" class="tocxref"><span class="secno">5.2 </span>Abuse Case AC2: Privacy Breach</a></li><li class="tocline"><a href="#integrity-breach" class="tocxref"><span class="secno">5.3 </span>Abuse Case AC3: Integrity Breach</a></li><li class="tocline"><a href="#phishing" class="tocxref"><span class="secno">5.4 </span>Abuse Case AC4: Phishing</a></li></ul></li><li class="tocline"><a href="#capabilities" class="tocxref"><span class="secno">6. </span>Capabilities</a><ul class="toc"><li class="tocline"><a href="#policy-capability-requirements" class="tocxref"><span class="secno">6.1 </span>Capability Requirements</a></li><li clas="tocline"><a href="#issue---features--relationship-to-capabilities--crud" class="tocxref"><span class="secno">6.2 </span>Issue - Features, relationship to capabilities, CRUD</a></li></ul></li><li class="tocline"><a href="#framework" class="tocxref"><span class="secno">7. </span>Security Framework</a><ul class="toc"><li class="tocline"><a href="#framework-rqmts" class="tocxref"><span class="secno">7.1 </span>Security Framework Requirements</a><ul class="toc"><li class="tocline"><a href="#policy-integrity-requirements" class="tocxref"><span class="secno">7.1.1 </span>Policy Integrity Requirements</a></li></ul></li><li class="tocline"><a href="#access-control-requirements" class="tocxref"><span class="secno">7.2 </span>Access Control Requirements</a></li></ul></li><li class="tocline"><a href="#examples-of-statements-or-rules-that-may-be-expressed-in-a-policy" class="tocxref"><span class="secno">8. </span>Examples of statements or rules that may be expressed in a policy</a></li><li class="tocline"><a href="#ot-of-scope" class="tocxref"><span class="secno">9. </span>Out of Scope</a></li><li class="tocline"><a href="#acknowledgements" class="tocxref"><span class="secno">A. </span>Acknowledgements</a></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">B. </span>References</a><ul class="toc"><li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">B.1 </span>Normative references</a></li><li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">B.2 </span>Informative references</a></li></ul></li></ul></div> <!-- abstract -->
+
+
<div id="introduction" class="section">
<!--OddPage--><h2><span class="secno">1. </span>Introduction</h2>
Received on Wednesday, 23 June 2010 16:28:40 UTC