- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Thu, 13 Jan 2011 17:30:02 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/policy-reqs
In directory hutz:/tmp/cvs-serv12703
Modified Files:
WD-src.html WD.html
Log Message:
prepare for publication
Index: WD.html
===================================================================
RCS file: /sources/public/2009/dap/policy-reqs/WD.html,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -d -r1.8 -r1.9
--- WD.html 2 Sep 2010 07:26:37 -0000 1.8
+++ WD.html 13 Jan 2011 17:30:00 -0000 1.9
@@ -3,576 +3,126 @@
<head>
<title>Device API Access Control Use Cases and Requirements</title>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8">
- <style type="text/css">
-/*****************************************************************
- * ReSpec CSS
- * Robin Berjon (robin at berjon dot com)
- * v0.05 - 2009-07-31
- *****************************************************************/
-
-
[...1262 lines suppressed...]
</div> <!-- threats -->
<div class="appendix section" id="acknowledgements">
- <!--OddPage--><h2><span class="secno">A. </span>Acknowledgements</h2>
+ <!--OddPage--><h2><span class="secno">B. </span>Acknowledgements</h2>
<p>
The editors would like to extend special thanks to Nokia, OMTP
BONDI, and PhoneGap for providing
@@ -1051,4 +476,9 @@
</div>
-<div id="references" class="appendix section"><!--OddPage--><h2><span class="secno">B. </span>References</h2><div id="normative-references" class="section"><h3><span class="secno">B.1 </span>Normative references</h3><p>No normative references.</p></div><div id="informative-references" class="section"><h3><span class="secno">B.2 </span>Informative references</h3><p>No informative references.</p></div></div></body></html>
+<div id="respec-err" style="position: fixed; width: 350px; top: 10px; right: 10px; border: 3px double #f00; background: #fff" class="removeOnSave"><ul><li style="color: #c00">There appears to have been a problem fetching the style sheet; status=0</li></ul></div><div id="references" class="appendix section"><!--OddPage--><h2><span class="secno">C. </span>References</h2><div id="normative-references" class="section"><h3><span class="secno">C.1 </span>Normative references</h3><p>No normative references.</p></div><div id="informative-references" class="section"><h3><span class="secno">C.2 </span>Informative references</h3><dl class="bibliography"><dt id="bib-CONTACTS-API">[CONTACTS-API]</dt><dd>R. Tibbett. <a href="http://dev.w3.org/2009/dap/contacts/Overview.html"><cite>Contacts API</cite></a>. 3rd August 2010. W3C Latest Editor's Draft. (Work in progress.) URL: <a href="http://dev.w3.org/2009/dap/contacts/Overview.html">http://dev.w3.org/2009/dap/contacts/Overview.html</a>
+</dd><dt id="bib-DAP-PRIVACY-REQS">[DAP-PRIVACY-REQS]</dt><dd>L. Arribas, P. Byers, M. Hanclik, F Hirsch, D. Rogers. <a href="http://dev.w3.org/2009/dap/privacy-reqs/"><cite>Device API Privacy Requirements</cite></a> 17 June 2010. (Work in progress.) URL: <a href="http://dev.w3.org/2009/dap/privacy-reqs/">http://dev.w3.org/2009/dap/privacy-reqs/</a>
+</dd><dt id="bib-GEOLOCATION-API">[GEOLOCATION-API]</dt><dd>Andrei Popescu. <a href="http://www.w3.org/TR/2008/WD-geolocation-API-20081222"><cite>Geolocation API Specification.</cite></a> 22 December 2008. W3C Working Draft. (Work in progress.) URL: <a href="http://www.w3.org/TR/2008/WD-geolocation-API-20081222">http://www.w3.org/TR/2008/WD-geolocation-API-20081222</a>
+</dd><dt id="bib-SYSINFOAPI">[SYSINFOAPI]</dt><dd>Dzung Tran, Max Froumentin, eds. <a href="http://www.w3.org/TR/2010/WD-system-info-api-20100202/"><cite>The System Information API</cite>, 2 February 2010, W3C Working Draft. (Work in Progess.) URL: </a><a href="http://www.w3.org/TR/2010/WD-system-info-api-20100202/">http://www.w3.org/TR/2010/WD-system-info-api-20100202/</a>
+</dd><dt id="bib-WIDGETS">[WIDGETS]</dt><dd>Marcos Caceres. <a href="http://www.w3.org/TR/2009/CR-widgets-20091201/"><cite>Widget Packaging and Configuration.</cite></a> 01 December 2009. W3C Candidate Recommendation. (Work in progress.) URL: <a href="http://www.w3.org/TR/2009/CR-widgets-20091201/">http://www.w3.org/TR/2009/CR-widgets-20091201/</a>
+</dd></dl></div></div></body></html>
\ No newline at end of file
Index: WD-src.html
===================================================================
RCS file: /sources/public/2009/dap/policy-reqs/WD-src.html,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -r1.3 -r1.4
--- WD-src.html 1 Sep 2010 19:52:35 -0000 1.3
+++ WD-src.html 13 Jan 2011 17:30:00 -0000 1.4
@@ -2,27 +2,53 @@
<html>
<head>
<title>Device API Access Control Use Cases and Requirements</title>
- <meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
+ <meta http-equiv='Content-Type' content='text/html;charset=utf-8' />
+<style type="text/css">
+.story {
+ margin: 1em 0em 0em;
+ padding: 1em;
+ border: 2px solid #cfd9f6;
+ background: #e2f0ff;
+}
+
+.story::before {
+ content: "Story";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #cfd9f6;
+ background: #fff;
+ padding: 3px 1em;
+}
+</style>
<script src='http://dev.w3.org/2009/dap/ReSpec.js/js/respec.js' class='remove'></script>
<!-- <script src='../ReSpec.js/js/respec.js' class='remove'></script> -->
<script class='remove'>
var respecConfig = {
specStatus: "WD-NOTE",
shortName: "dap-policy-reqs",
- publishDate: "2010-09-07",
- previousPublishDate: "2010-06-29",
- previousMaturity: "NOTE",
+ editors: [
+ { name: "Laura Arribas",
+ company: "Vodafone",
+ companyURL: "http://vodafone.com/" },
+ { name: "Frederick Hirsch",
+ company: "Nokia",
+ companyURL: "http://www.nokia.com/" },
+ {name: "Dominique Hazaël-Massieux", company: "W3C"}
+ ],
+ // 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>
+ <script src='../common/config.js' class='remove'></script>
</head>
<body>
<section id='abstract'>
- This document describes Device API Access Control Use Cases and
- corresponding Requirements.
+ With the emergence of numerous new APIs in Web browsers and runtime engines, the need to control which Web sites and applications can make use of these APIs increases. This document describes use cases and requirements for controlling access to these APIs.
</section> <!-- abstract -->
<section id='sotd'>
@@ -34,122 +60,86 @@
<section id='introduction' class='informative'>
<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>The management of security policies and revocation mechanisms are
- out of scope.</p>
- <p>The approach taken in this document is to simplify the possible
- interactions by considering three related use cases:</p>
+ Various groups have been defining APIs designed to enable
+ Web sites and applications access to device resources, including geolocation [[GEOLOCATION-API]], personal information such as calendar and contacts [[CONTACTS-API]],
+ system information [[SYSINFOAPI]] such as network information, etc. Much of this information is sensitive and can be misused.</p>
+
+ <p>This document outlines "user story" use cases
+ for security and access
+ control for device APIs and derives requirements from these
+ cases. Although security and access control is related to
+ privacy, this document does not discuss privacy specifically as
+ there is another document specific to privacy [[DAP-PRIVACY-REQS]].
+ </p>
+
+ <section id="defs">
+ <h2>Definition</h2>
+ <p>A <dfn>non-safe API</dfn> is an API that shares sensitive
+ user information or makes a commitment for the user to a
+ third-party (e.g. paying a fee).</p>
+ </section>
+ </section> <!-- introduction -->
+ <section id="interactions" class="informative">
+ <h2>Access Control Interactions</h2>
+ <p>Three main types of interactions have been identified for
+ controlling access to non-safe APIS:</p>
<ul>
- <li>web browser web pages and untrusted widgets</li>
- <li>trusted widgets and applications</li>
- <li>delegated authority</li>
+ <li>based on granular user consent, for every first call of a sensitive API,</li>
+ <li>based on user consent for a set of APIs at once, packaged into a single interaction (e.g. at “installation” time),</li>
+ <li>or delegated by the user to a third party that sets new default interactions for APIs based on the requesting script.</li>
</ul>
- <p>They are related because requirements for the web may
- also apply to trusted widgets, and those various requirements may
- also apply to delegated authority, likewise trusted widget/application
- requirements may apply to delegated authority case. Each level may
- add additional
- requirements. For example, the requirement for minimal user-dialogs
- may apply to all, while requirements on interoperable policy
- languages may only apply to the delegated authority case.
- </p>
- </section> <!-- introduction -->
- <section id='web-case' class='informative'>
- <h3>Web Browser and Untrusted Widgets</h3>
- <section id='web-case-overview' class='informative'>
- <h4>Use Case Overview</h4>
- <p>The web browser Device API use case is the one
- where a web page invokes the Device API as part of the page
- code, such as Javascript.</p>
- <p>This case cannot assume a policy framework that is accepted and
- managed for all parts of the web.</p>
- <p>As a result any device API available to such web pages must
- observe these two requirements:</p>
- <ol>
- <li>If no user-interaction is involved, use of the API must be
- safe.</li>
- <li>If not safe, then user consent is required for each use of the
- API. This consent should appear as a part of the task specific
- workflow, thus not necessarily appear as a permission dialog.</li>
- </ol>
- <p>
- A user may wish to 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. To be consistent with the
- delegated authority case a similar mechanism for remembering
- state might be appropriate.
- </p>
+ <p>These interactions can be relevant both for a Web site accessed through a browser, or an installable Web application (e.g. a widget [[WIDGETS]]) accessed through a dedicated runtime engine.</p>
+
+ <section id='userconsent'>
+ <h3>Granular User Consent</h3>
+ <section id='userconsent-story-1'>
+ <h4>User Story: Unknown restaurant Web site</h4>
+ <div class="story">
+ <p>Alice uses her browser to get more information on a restaurant her friends have told her about. The Web site of the restaurant offers to give her indications on how to come from where she stands to their location, as well as to send automatically a SMS to reserve a table for lunch.</p>
+ <p>Alice follows a link to the direction page, and her browser
+ asks her unintrusively to confirm she wants to share her current
+ location with the map service provider embedded in the Web
+ restaurant site. After considering issues related to sharing this
+ information, she decides to share her current location. Upon consenting to sharing her location through the browser, she gets detailed directions to the restaurant.</p>
+ <p>Her browser then displays a non-modal prompt asking if she wants to send an SMS to make a reservation at the restaurant. She is not interested and simply ignores the prompt.</p>
+ </div>
+ <h4>Analysis</h4>
+
+ <p>Access to non-safe APIs from web pages or applications with
+ which the user has no pre-established relationship must only be
+ granted after explicit user consent, and that consent needs to be
+ granted for each non-safe API separately. Note that it isn't
+ obvious whether this consent is truly informed, or that the user
+ understands all the issues involved. This is discussed further
+ elsewhere [[DAP-PRIVACY-REQS]].</p>
+
+ <p>The user may need to gather more information before making a decision on granting access to a given API: e.g. reading the site privacy policy or getting more information on what the collected data will be used for. To make it possible for the user to make an informed decision, the user consent interactions need to be non-blocking.</p>
+
+ </section>
+ <section id="userconsent-story-2">
+ <h4>User Story: Widget of unknown source using the camera</h4>
+ <div class="story">
+ <p>Bob receives from Alice a mobile widget that she says is used to create a crowd-sourced view of their city. While Bob trusts Alice, he is not sure how trustable that particular widget is.</p>
+ <p>He runs it in his widget runtime engine in untrusted mode; the widget is only able to take pictures when Bob explicitly press the shutter button of the phone; the geolocation of the pictures is only sent along with the pictures when Bob agrees to it.</p>
+ </div>
+ <h4>Analysis</h4>
+
<p>
- An un-trusted widget (i.e. unsigned widget or widget signed by an
+ An un-trusted widget (e.g.. unsigned widget or widget signed by an
unknown or untrusted authority) should be treated in the
- same manner as a web browser, since the risks
+ same manner as an unknown web site, since the risks
are the same.</p>
- <p>
- In summary:</p>
- <ul>
- <li>the user of a device is the sole authority that decides
- access rights of applications;</li>
- <li>
- there is no external policy authority and hence no
- explicit policy</li>
- <li>APIs must be designed to require appropriate user
- interaction or
- be safe by default</li>
- <li>There is an open question as to how users may set and remember
- preferences and if such settings should be interoperable across
- browsers and stored locally or remotely.</li>
- </ul>
- </section>
- <section id='web-case-rqmts' class='informative'>
- <h4>Requirements</h4>
- <p>
- <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>
- <p>
- Prompts should be eliminated whenever possible. Many prompts
- do not provide
- any meaningful security because:</p>
+
+
+ <p>To make it easier for the user to understand what he is
+ granting access to, the access control interactions need to be as
+ integrated as possible as a part of the task specific workflow,
+ thus not necessarily appearing as a permission dialog. Relying on
+ the user pressing the shutter button to take a picture is more
+ effective than asking him if he agrees with sharing a picture.</p>
+
+ <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
@@ -159,374 +149,245 @@
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>
- </section>
- <section id="web-issues" class='informative'>
- <h3>Issues</h3>
- <ul>
- <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>
- Different permission granularities have
- advantages for different use
- cases so the requirement might be to support different
- granularities for different cases.
- </p></li>
- </ul>
+ </p>
+
+</section>
+ <section id='userconsent-rqmts'>
+ <h4>Requirements</h4>
+ <ul>
+ <li>Non-safe APIs MUST NOT require the usage of blocking user consent interactions (e.g. modal dialogs) while the application is running (although modal dialogs may be required for security prompts provided during application
+ installation or invocation).</li>
+ <li>As a result, non-safe APIs MUST use asynchronous calls for operations that require user consent.</li>
+ <li>Non-safe APIs SHOULD permit to get user consent in interactions that are well-integrated in the workflow of the underlying operation.</li>
+ <li>In an untrusted context, user consent for a given non-safe
+ API SHOULD NOT imply consent for another non-safe API.</li>
+ <li>when a non-safe API expose multiple non-safe operations, the API MUST describe the granularity of user consent if that granularity is not part of the user workflow; the parameters to which this granularity can be applied include:<ul>
+ <li>separate consent for each operation, or grouped for the whole API,</li>
+ <li>persistent for each call in a given session,</li>
+ <li>persistent for each call over a period of time spanning
+ multiple sessions.</li>
+ </ul>
+ </li>
+ </ul>
</section>
+ </section> <!-- userconsent -->
+ <section id='grouped-permissions'>
+ <h3>Grouped permissions</h3>
+ <section id='grouped-permissions-story1'>
+ <h4>User Story: Web application for email</h4>
+ <div class="story">
+ <p>Alice uses a Web application as her email client, and considers it trustable.</p>
+ <p>Her service provider offers to use a set of advanced features that requires access to off-line storage, addressbook integration, access to a dedicated storage space on her device, and interactions through the microphone.</p>
+ <p>Rather than being prompted every so often to grant permission to use these features, Alice is offered to approve all these accesses in a batch, as part of an installation procedure that identifies these extra-permissions.</p>
+ <p>Alice follows that procedure and is no longer prompted for these permissions for this application; she still gets prompted when her email client asks for her geolocation since that permission was not part of the batch approval.</p>
+ </div>
+
+ <h4>Analysis</h4>
+
+ <p>Once a user has established a certain level of trust with a service provider, she is more likely to want to approve permissions as a batch rather than having to respond to prompt every so often that might slow down her work, or might make her miss an additional feature of the application.</p>
+
+ <p>Similarly, the user can be offered to validate a set of permissions in a batch when installing a widget, where the permissions can be identified through the <code>feature</code> element [[WIDGETS]].</p>
+
+ <p>To that end, the various permissions that are bound to APIs need to identified.</p>
+
+ <p>To establish trust, a few basic parameters may be used, among which:</p>
+ <ul>
+ <li><dfn>identity</dfn> — ensuring that the privileges are granted to the application from the trusted provider itself, to avoid phishing attacks;</li>
+ <li><dfn>reputation</dfn> — if others have reviewed positively an application, the user is more likely to trust it; reputation is itself linked to identity, either as a way to identify the source of the recommandation (e.g. approval from a network operator), or as a way to identify the aggregator of recommendations;</li>
+ <li><dfn>context</dfn> — a user is more likely to trust an application that requests permissions that make sense to her use of the said application.</li>
+ </ul>
- </section> <!-- web -->
- <section id='trusted-widget-case' class='informative'>
- <h3>Trusted Widget or Application</h3>
- <section id='widget-case-overview' class='informative'>
- <h4>Use Case Overview</h4>
- <p>The trusted Widget or application Device API use case is
- where a trusted widget or application is
- delivered to a device.
- In this case the entire widget or application
- can be trusted as an desktop application would be, so if installed
- should have a set of privileges associated with a trusted
- software.
- Thus it should be able to use all safe APIs that
- could be used in the web case, but may also be able to use
- additional
- APIs that are not safe, such as APIs that do not require
- specific user
- consent in each case. However this list must be carefully
- controlled.
- </p>
<p>
- Trust may be established in different ways, the most common being
+ Identity and reputation may be established in different ways; one of the most common being
through a validated signature on the widget or application package,
with a corresponding verification of the trust chain to a trusted root.
- Alternative means of determining trust are also possible, such as
- using a reputation or other mechanism.
- </p>
- <p>
- Once trust is established, a trusted widget or application
- might have explicit policy associated with it. In this case it
- can be treated the same as in the delegated authority case
- below, or it may not have explicit policy, but additional
- API functionality may in general be allowed due to the
- trust. In this case user acceptance of the entire widget or
- application ,
- similar to personal computer application install, may be appropriate.
</p>
+
+
</section>
- <section id='widget-case-rqmts' class='informative'>
+ <section id='grouped-permissions-rqmts'>
<h4>Requirements</h4>
- <ul>
- <li><p>Trust be established to a satisfactory level. In the
- case of using
- signature in conjunction with PKI mechanisms, the
- signature MUST be
- verified and the certificate chain MUST be validated to
- a known trust
- root.</p></li>
- <li><p>Other mechanisms than signatures may be used if they
- offer robust enough trust verification.</p></li>
- </ul>
+ <ul>
+ <li>Non-safe APIs SHOULD define an identifier for the various permissions they require.</li>
+ <li>The security framework SHOULD refer to these API permissions identifiers to allow grouping them in a single user consent operation.</li>
+ <li>when identity is checked through the use of signature in
+ conjunction with PKI mechanisms, the security framework MUST
+ require the verification of the signature, and MUST require
+ validation of the certificate chain to a known trust
+ root. Certificate revocation SHOULD be considered.</li>
+
+ </ul>
</section>
- </section> <!-- trusted widget -->
- <section id='delegated-authority-case' class='informative'>
+ </section>
+ <section id='delegated-authority-case'>
<h3>Delegated Authority</h3>
- <section id='delegated-authority-case-overview' class='informative'>
- <h4>Use Case Overview</h4>
- <p>The Delegated Authority Device API use case includes the use of
+ <p>Delegated authority use case refers to the use of
explicit and interoperable policy definitions to control the use of
- an extensive set of APIs, save and unsafe. Such rules may be used
- in the case of a trusted widget or the web case with clients that
- support it. It may be deployed by an Enterprise or a Mobile
- Operator, to give two examples.
- </p>
- <p>This can be viewed as delegation of authority for access control
- policy to an
- external service provider.
- This external service provider provides advice on the
+ an extensive set of APIs, safe and unsafe. Such rules may be used
+ in the context of a trusted widget or of well-identified web site, with clients that support it.</p>
+ <section id='delegated-authority-story1'>
+ <h4>User Story: Enterprise-level ban on geolocation</h4>
+ <div class="story">
+ <p>Bob manages the fleet of phones and laptops for ACMEcash, a cash transportation company: all the drivers have been equipped with a phone and a laptop they can use to interact with their intranet.</p>
+ <p>To keep the whereabouts of their employees as hidden as possible for security reasons, Bob wants to restrict all the devices distributed to employees so that they cannot use the geolocation API, except when connecting to the company intranet.</p>
+ <p>Bob creates a policy matching these rules, and deploys it to the phones and laptops.</p>
+ <p>When ACMEcash gets renamed ACMEbucks, Bob updates this policy to reflect the new domain name of the intranet.</p>
+
+ </div>
+ <h4>Analysis</h4>
+ <p>In many professional contexts, allowing access to private or sensors data available through connected devices creates an unacceptable risk.</p>
+ <p>In these contexts, being able to enforce and update a policy that determines who can make use of these data across devices and platforms can be a decisive aspect of the adoption of a given technology.</p>
+ <p>To that end, it should be possible to describe
+ platform-independent and declarative policies that determine which
+ APIs can be used from what Web site or application.</p>
+ <section id='delgated-authority-story1-rqmts'>
+ <h4>Requirements</h4>
+ <ul>
+ <li>The access control policy language MUST be device-independent.</li>
+ <li>The access control policy language MUST be declarative.</li>
+ </ul>
+ </section>
+ </section>
+ <section id='delegated-authority-story2'>
+ <h4>User Story: Third-party protection against malware</h4>
+ <div class="story">
+ <p>Alice keeps a lot of her private and sensitive data on her phone. Having heard that her friend Charlie has had troubles with a phishing attempt recently, she would like to use a service to increase her safety.</p>
+ <p>She subscribes to a service operated by ACMEsafe: they define and maintain a set of rules that block access to certain APIs from unknown sites, facilitate access to sites that she has identified as trustable and that can be reliably identified.</p>
+ <p>Both Alice’s browser and widget runtime engine follow the rules expressed in the policy defined by ACMEsafe; these rules are updated on a regular basis on the device, after having verified their proper origin by checking their digital signature.</p>
+ </div>
+ <h4>Analysis</h4>
+ <p>The same way anti-virus and malware tools allow users to reduce their risk of being exposed to troubles on their computers, some users may want to choose to delegate authority for access control policy to an external service provider.</p>
+ <p>This external service provider determines the
trustworthiness of
- specific applications, and determines an access control
+ specific applications, and specifies 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. The policy defined by the external
+ that advice: blanket rejection for known malware sites, user consent requested for others, and transparent approval for sites that the user has configured as trusted.</p>
+ <p>The policy defined by the external
authority may be updated
regularly in
response to new information on known threats.
</p>
+
+ <p>This policy needs to be integrity-protected during various points in its life-cycle.</p>
+ <section id='delgated-authority-story2-rqmts'>
+ <h4>Requirements</h4>
+ <ul>
+ <li>Integrity protection and source authentication of the access
+ control policy MUST be
+ supported, not only in transit but also storage.</li>
+ </ul>
+ </section>
+
+ </section>
+ <section id="delegated-authority-story2a">
+ <h4>User Story: Transfering remembered choices to another device</h4>
+ <div class="story">
+ <p>Dave has been using advanced features on the Web from his
+ phone for quite some time, and has thus accepted and rejected
+ permissions from a large number of Web sites on his
+ device.</p>
+ <p>But Dave is now looking to the brand new phone released by
+ ACMEdev, and would like to migrate his settings to that new phone,
+ which also uses a different browser.</p>
+ <p>Dave’s operator offers him to transfer seamlessly these
+ settings from one phone to other, and informs him that they can
+ also be used on his other connected devices.</p>
+ </div>
+
+ <h4>Analysis</h4>
<p>
- This use-case mirrors current practice with products such as
- virus scanners or
- other malware detectors.
+Remembering earlier decisions and
+maintaining these choices when changing devices either across vendors or
+device versions has value to the user. This may also be the case when
+wishing to have the same choices on multple devices. It should be
+possible to transfer or share a
+representation of user choices across devices at any time.
</p>
- <p>
- In summary:</p>
- <ul>
- <li>the user of a device delegates authority to an external policy
- provider;</li>
- <li>
- an initial security policy configuration may be
- provided by the external
+ <section id='delgated-authority-story3-rqmts'>
+ <h4>Requirements</h4>
+ <ul>
+ <li>Access control policy MUST be able to record user decisions
+ regarding policy configuration at an appropriate level of
+ granularity.</li>
+ <li>Access control policy MUST be portable across devices and
+ not bound to specific devices.</li>
+ </ul>
+ </section>
+
+ </section>
+ <section id='delegated-authority-story3'>
+ <h4>User Story: Operator-enforced usage limitations</h4>
+ <div class="story">
+ <p>Dave has found a nice-looking widget for managing SMS and MMS messages, but is not sure if it is safe to install it.</p>
+ <p>He contacts his operator ACMEcom; they indicate that on their devices, only widgets that have been verified by them will be able to send SMS.</p>
+ <p>Dave checks the widget, sees that the only special permission it requires is access to messaging features, and feels confident that he can now install it.</p>
+ </div>
+ <h4>Analysis</h4>
+ <p>An initial access control configuration may be
+ provided by an external
authority, together with any other associated device
configuration (such as
- root certificates). The configured policy may
+ 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 user may or may not be able to modify this policy;</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>
- <li>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;
- </li>
- <li>The external policy authority may configure the
- policy as part of the
- commissioning of the device (e.g. a network operator's
- configuration applied by
- the manufacturer prior to sale, or an enterprise
- configuring device policy
- using a secured device management interface).
- </li>
- </ul>
+ decisions to the user.</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
+ distributed or verified by the policy
authority (e.g. to control its exposure to the financial
risk of abuse of device
APIs).
</p>
- </section>
- <section id='delegated-authority-case-rqmts' class='informative'>
+ <section id='delegated-authority-case-rqmts'>
<h4>Requirements</h4>
<ul>
- <li><p>Policy SHOULD be defined in a portable device-independent
- manner.</p>
- <p>
- The reason for this requirement is that a single policy
- authority may need 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.
- </p>
- </li>
- <li>It SHOULD be possible to update portions of policy
- independently.
- <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>
- </li>
- <li>Security Framework MUST be separable from policy
- rules.</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>
- <li>It MUST be possible to provide integrity protection and
- source authentication for policy.
- <p>It should be possible for policy to be integrity protected during
- various points in its life-cycle.</p>
- </li>
- <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>
- <li>The security framework MUST support sufficient granularity
- for sensible access control decisions. (features )
- </li>
+ <li>It SHOULD be possible to update portions of policy independently.</li>
+ <li>Access control policies MAY be associated with
+ different authorities, including the user.</li>
</ul>
- <p>
- Note that separation of the security framework from policy
- statements
- can be achieved using declarative
- policy statements.
- </p>
- </section>
- <section id='delegated-authority-case-examples' class='informative'>
- <h3>Policy Examples</h3>
- <p>
- This section provides specific examples of statements or
- rules that may be
- expressed in a policy.
- </p>
- <p>Example web site policy cases:</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>
- <p>Example widget policy cases:</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>
- </section>
- </section> <!-- delgated authority -->
-
- <section id="threats" class='informative'>
+ <p class="note">The management of security policies and revocation mechanisms are out of scope of the Device APIs and Policy Working Group charter.</p>
+ </section>
+ </section>
+ </section>
+ </section>
+ <section id="threats" class='appendix'>
<h3>Security and Privacy Threats</h3>
<p>
- This section outlines some threats related to
- the Device 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?
+ applications based on browser technology. Experience with
+ security attacks suggests that the increase of scope and
+ power of the Device APIs raises the potential for attacks of
+ increasing significance. This section outlines some known threats.
</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
+ Up until now no major malware incident
+ has affected the mobile industry, but risks increase as
+ adoption and convergence increases. There have been attempts: the
+ MMS-spreading Commwarrior virus 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
+ avoiding mobile security issues to date has been the fact that
+ mobile platforms have been too fragmented and complex
+ to provide an attractive target. 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.
+ widgets and web applications as device APIs are opened up
+ and the size of the mobile market increases.
</p>
<section id="premium-rate-abuse">
- <h2>Abuse Case AC1: Premium Rate Abuse</h2>
+ <h2>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
@@ -535,13 +396,13 @@
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
+ ‘dialers’ 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>
+ <h3>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
@@ -563,9 +424,13 @@
the knowledge that their personal data will not leak in
any way.
</p>
+<p>
+Another example is turning on the camera or audio remotely to obtain
+audio, video or photo information without permission.
+</p>
</section> <!-- privacy-breach -->
<section id="integrity-breach">
- <h3>Abuse Case AC3: Integrity Breach</h3>
+ <h3>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
@@ -587,7 +452,7 @@
</p>
</section> <!-- integrity-breach -->
<section id="phishing">
- <h3>Abuse Case AC4: Phishing</h3>
+ <h3>Phishing</h3>
<p>
Widgets contain web content making it is easy to duplicate
and masquerade as something legitimate… perhaps a bank?
Received on Thursday, 13 January 2011 17:30:05 UTC