- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Tue, 02 Mar 2010 22:51:02 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/policy-reqs
In directory hutz:/tmp/cvs-serv20905
Modified Files:
Overview.html
Log Message:
Add use cases section, provided by Paddy Byers
Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/policy-reqs/Overview.html,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -d -r1.15 -r1.16
--- Overview.html 2 Mar 2010 02:26:04 -0000 1.15
+++ Overview.html 2 Mar 2010 22:51:00 -0000 1.16
@@ -21,7 +21,7 @@
This document includes common use cases and security, privacy
and policy requirements for device APIs.
</section>
-
+
<section class='informative'>
<h2>Introduction</h2>
<p>
@@ -43,29 +43,29 @@
<dl>
<dt>Application</dt>
<dd>Code that may make use of DAP Device APIs. Application
- code can be widgets or web
+ code can be widgets or web
applications running in a browser, for example. </dd>
<dt>Device API</dt>
<dd>A Device API is a collection of Javascript interfaces
- structured in
+ structured in
terms of methods and properties. Device APIs are used by
- applications to access Device
+ applications to access Device
Capabilities.
</dd>
<dt>Device Capability</dt>
<dd>A Device Capability is a device resource or device functionality, which may
- require access
+ require access
control.</dd>
<dd> Examples of device capabilities are the ability to
- read a local
+ read a local
file, or to discover nearby Bluetooth devices, or to send an
- SMS
+ SMS
message. Device Capabilities may be defined
- in a way that is
+ in a way that is
independent of the specific Device APIs that an application
- uses to access
- them.
+ uses to access
+ them.
</dd>
<dd>
Although there are simple Device APIs that provide access only to
@@ -92,10 +92,190 @@
</section>
<section class='informative'>
- <h2>Use Cases</h2>
- <p>Example widget use cases, to give examples of the types of
- policy that might be expressed:</p>
+ <h2>Policy Use Cases</h2>
+ <p>
+ This section proposes a set of specific use cases to assist in the definition
+ and validation of a policy framework.
+ </p>
+ <p>
+ Use cases are organised into three categories:
+ </p>
+ <ul>
+ <li>use cases relating to the definition and management of policy;</li>
+ <li>use cases relating to the interoperability of policy;</li>
+ <li>use cases relating to the contents of the policy itself.</li>
+ </ul>
+ <p>
+ The use cases are not claimed to be exhaustive, but illustrative.
+ </p>
+ <h3>Policy management</h3>
+ <p>
+ These use cases relate to how a policy is created, configured and maintained.
+ </p>
+ <p>
+ Use cases vary according to:
+ </p>
+ <ul>
+ <li>
+ who the authority for the policy is: either the user, or an external
+ authority such as an enterprise, or a combination;
+ </li>
+ <li>
+ the nature of the initial policy configuration (eg whether it is a universal
+ default, or is a specific policy determined by the authority to support a
+ specific objective);
+ </li>
+ <li>
+ the nature of the policy maintenance and update.
+ </li>
+ </ul>
+ <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>
+ <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
+ behaviour, 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>
+ <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 acces 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>
+ <h3>Policy interoperability</h3>
+ <p>
+ These use cases relate to reading and writing of policy definitions in an
+ interoperable format.
+ </p>
+ <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>
+ <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>
+ <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>
+ <h3>Policy contents</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
@@ -105,7 +285,7 @@
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
+ <code>weather.example.com</code> without
notifying the user, except when roaming.
</li><li>
All widgets with a reliably identified author can save data
@@ -201,7 +381,7 @@
<h3>Issues</h3>
<p class="issue">
Features defined according to CRUD, one feature for Create,
- Read, Update, Delete?
+ Read, Update, Delete?
</p>
<p class="issue">
Feature parameters to avoid explosion of capabilities and
@@ -224,7 +404,7 @@
<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
+ security configuration choices and interactive policy
decisions using the policy markup language format.</li>
</ul>
</section>
@@ -257,7 +437,7 @@
has a choice to perform them and doing so implies consent to
use the associated Device Capabilities. Such implicit consent
eliminates the need for a security access dialog for that
- action since it is implicit in the application semantics.
+ action since it is implicit in the application semantics.
</p><p>
Device APIs may also be defined such that implicit consent is not
implied. Examples are a camera API that takes a photograph without
@@ -266,28 +446,28 @@
user dialogs may be required.
</p><p>
It is important to note that modal prompts (i.e. prompts
- that block all other user
- interaction until
+ 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 runtime (e.g.
at the time a sensitive action is attempted) can be
- non-modal if the API
+ non-modal if the API
that initiates it is asynchronous. DAP APIs MUST be designed
- so that all
+ so that all
operations that could potentially trigger a prompt are
- asynchronous.
+ asynchronous.
</p>
<p>
If user decisions
- are themselves expressible in the policy language, then they can be
+ 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
+ way of creating
an initial policy configuration, but can be the sole and complete
representation of the access control configuration at any time.
</p>
@@ -348,32 +528,32 @@
</section> <!-- user control -->
<section>
<h2>Privacy considerations</h2>
-<p>Privacy considerations are important to Device APIs, since misuse of
-information can have financial, physical safety, and reputation
-impacts, among others. Privacy needs a systemic solution, including
-functional requirements on user agents, web sites and other components
-of the system, since any opportunity for misuse of private information
-is a risk. Addressing privacy may include functional requirements in
-the technical standards, laws and regulations, and best practices.
-When privacy concerns are not appropriately met, legal remedies in the
-courts may be required after the fact. Thus it is important that
+<p>Privacy considerations are important to Device APIs, since misuse of
+information can have financial, physical safety, and reputation
+impacts, among others. Privacy needs a systemic solution, including
+functional requirements on user agents, web sites and other components
+of the system, since any opportunity for misuse of private information
+is a risk. Addressing privacy may include functional requirements in
+the technical standards, laws and regulations, and best practices.
+When privacy concerns are not appropriately met, legal remedies in the
+courts may be required after the fact. Thus it is important that
privacy is addressed appropriately up-front.
</p>
<p>[[PRIVACY-ISSUES-GEO]] raises several aspects that APIs that
expose user private data should take into consideration.
-In general these concerns apply to all APIs, though the impact of
-privacy risks may vary with individual API. For example, inappropriate
-disclosure of contacts or location information could have serious
+In general these concerns apply to all APIs, though the impact of
+privacy risks may vary with individual API. For example, inappropriate
+disclosure of contacts or location information could have serious
personal safety issues, while other system type information
- disclosures might
+ disclosures might
have fewer issues.
-</p>
+</p>
<section>
- <h3>Minimization</h3>
- <p>To reduce the risks of over-exposing users data, it is helpful to design APIs so that Web developers can request as little information as they need to accomplish their goals.</p>
- <p>To that end:</p>
- <ul>
- <li><p>APIs SHOULD make it easy to request as little information as required for the intended usage.</p>
+ <h3>Minimization</h3>
+ <p>To reduce the risks of over-exposing users data, it is helpful to design APIs so that Web developers can request as little information as they need to accomplish their goals.</p>
+ <p>To that end:</p>
+ <ul>
+ <li><p>APIs SHOULD make it easy to request as little information as required for the intended usage.</p>
<p>For instance, an API call should require specific parameters to be set to obtain more information, and should default to little or no information.</p>
</li>
<li><p>APIs SHOULD make it possible for user agents to convey the breadth of
@@ -383,23 +563,23 @@
<li><p>APIs SHOULD make it possible for user agents to let the user select
and filter information before it is shared with the requester.</p>
<p>The user agent can then act as a broker for trusted data, and will only transmit data to the requester that the user has explicitly allowed.</p></li>
- </ul>
+ </ul>
</section>
<section>
- <h3>Appropriateness</h3>
- <p>When making a decision about sharing or not some private data, the user needs to understand how these data will be used by the requester.</p>
- <p class="issue">Should the APIs have a hook to convey the intended usage of the data? If they do, should it be a required parameter? And how can this information be conveyed without misleading the user in the trustiness of that information?</p>
+ <h3>Appropriateness</h3>
+ <p>When making a decision about sharing or not some private data, the user needs to understand how these data will be used by the requester.</p>
+ <p class="issue">Should the APIs have a hook to convey the intended usage of the data? If they do, should it be a required parameter? And how can this information be conveyed without misleading the user in the trustiness of that information?</p>
- </section>
- <section>
- <h3>User consent</h3>
- <p>See <a href="#user-control-over-decisions">User Control over Decisions</a>.</p>
</section>
<section>
- <h3>Data storage and redistribution</h3>
- <p>Once the data have been made available to the requester, the requester is in a position to store and redistribute these data, with or without the user consent.</p>
- <div class="issue"><p>Attaching policy rules to the data that get shared can provide a legal basis for enhancing the control users have over their data once they are shared; but doing so create the following challenges:</p>
- <ul><li>getting the user to understand and set rules on sharing their
+ <h3>User consent</h3>
+ <p>See <a href="#user-control-over-decisions">User Control over Decisions</a>.</p>
+ </section>
+ <section>
+ <h3>Data storage and redistribution</h3>
+ <p>Once the data have been made available to the requester, the requester is in a position to store and redistribute these data, with or without the user consent.</p>
+ <div class="issue"><p>Attaching policy rules to the data that get shared can provide a legal basis for enhancing the control users have over their data once they are shared; but doing so create the following challenges:</p>
+ <ul><li>getting the user to understand and set rules on sharing their
information is hard;</li>
<li>if users set their preferences in the user agent, they will expect the
user agent to enforce these preferences while it cannot actually control
@@ -407,18 +587,18 @@
<li>developers are very likely to ignore policy rules sent along with the
data they're actually interested in, and may not be in a position to act
upon these policies even if they wanted to</li>
- </ul>
- </div>
+ </ul>
+ </div>
</section>
<section>
- <h3>Notice, Transparency and Feedback</h3>
- <p>When a requestor needs data, is the user informed how the data
+ <h3>Notice, Transparency and Feedback</h3>
+ <p>When a requestor needs data, is the user informed how the data
will be used, and in general how to access the privacy policy? Can
the user specify rules on the use of their data, taking an active
role in managing their privacy? Can
the user access a log to determine how their information was used
and by whom?</p>
- <div class="issue"><p>Is it possible to provide an indicator that
+ <div class="issue"><p>Is it possible to provide an indicator that
personal information is being used, and enable follow up action
from the user to determine how it is being used? (e.g. visual
indicator and means to access log)
@@ -492,7 +672,7 @@
</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?
+ at the device capability level adequate?
</p>
</section>
<section class='informative'>
@@ -516,7 +696,7 @@
<h2>Acknowledgements</h2>
<p>
The editors would like to extend special thanks to Nokia, OMTP
- BONDI, and PhoneGap for providing
+ BONDI, and PhoneGap for providing
the foundation of the working group's requirements discussion.
</p>
</section>
Received on Tuesday, 2 March 2010 22:51:04 UTC