- From: Dominique Hazael-Massieux via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 08 Sep 2010 16:07:39 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/policy-reqs
In directory hutz:/tmp/cvs-serv28116
Modified Files:
Overview.html
Log Message:
vastly rewritten (but not fully done yet)
now organized around user stories, and in terms of granular user consent/grouped permissions/delegated authority/
Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/policy-reqs/Overview.html,v
retrieving revision 1.45
retrieving revision 1.46
diff -u -d -r1.45 -r1.46
--- Overview.html 1 Sep 2010 17:02:33 -0000 1.45
+++ Overview.html 8 Sep 2010 16:07:37 -0000 1.46
@@ -3,12 +3,40 @@
<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">
+.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: "ED",
shortName: "dap-policy-reqs",
+ 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/",
@@ -16,12 +44,11 @@
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 what Web sites and applications can make use of these APIs increases. This document describes use cases and requirements for controling access to these APIs.
</section> <!-- abstract -->
<section id='sotd'>
@@ -33,54 +60,175 @@
<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.
+ Various groups have been defining APIs designed to enable
+ Web sites and applications access to device resources, including geolocation, personal information such as calendar and contacts,
+ system information such as network information, etc. Much of this information is sensitive and can be misused. As part of its charter, the Device API and Policy Working Group is developing a set of technologies to control access to
+ this information, including through the use of a policy framework.
</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>
+ <section id="defs">
+ <h2>Definitions</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 haven been identified for this access control:</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>
+ <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. She glances at the privacy policy and decides she can safely share her current location. She consents to sharing her location through the browser, and 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.</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 (e.g.. unsigned widget or widget signed by an
+ unknown or untrusted authority) should be treated in the
+ same manner as an unknown web site, since the risks
+ are the same.</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
+ 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>
+
+</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 enduce 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>separate for each call or valid for a longer time,</li>
+ <li>persistent across users visits or not.</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>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>identity — ensuring that the privileges are granted to the application from the trusted provider itself, to avoid phishing attacks;</li>
+ <li>reputation — 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>context — a user is more likely to trust an application that requests permissions that make sense to her use of the said application.</li>
+ </ul>
+
+ <p>
+ 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.
+ </p>
+
+
+ </section>
+ <section id='grouped-permissions-rqmts'>
+ <h4>Requirements</h4>
+ <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 signatuure, and MUST require validation of the certificate chain to a knonw trust root.</li>
+
+ </ul>
+ </section>
+ </section>
+ <section id='delegated-authority-case'>
+ <h3>Delegated Authority</h3>
+ <p>Delegated authority use case includes refers to the use of
+ explicit and interoperable policy definitions to control the use of
+ 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>
+ </section>
+ <section id='delegated-authority-story2'>
+ <h4>User Story: Third-party protection against malware</h4>
+ <div class="story">
+
+ </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 specifies an access control
+ policy that embodies
+ 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>
+ </section>
+ <section id="delegated-authority-story2a">
+ <h4>User Story: User-defined cross-devices policies</h4>
+ <div class="story">
+ <p>@@@
A user may wish to establish a policy configuration (through
explicit
configuration of
@@ -106,80 +254,8 @@
delegated authority case a similar mechanism for remembering
state might be appropriate.
</p>
- <p>
- An un-trusted widget (i.e. 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
- 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>
- <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>
+
+ <p>@@@
If user decisions
are themselves expressible in the policy language, then they can be
"remembered" by
@@ -189,128 +265,17 @@
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>
- </section>
+ </p></div>
- </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
- 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'>
- <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>
- </section>
- </section> <!-- trusted widget -->
- <section id='delegated-authority-case' class='informative'>
- <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
- 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
- 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. The policy defined by the external
- authority may be updated
- regularly in
- response to new information on known threats.
- </p>
- <p>
- This use-case mirrors current practice with products such as
- virus scanners or
- other malware detectors.
- </p>
- <p>
+ <section id='delegated-authority-story3'>
+ <h4>User Story: Operator-enforced usage limitations</h4>
+ <div class="story">
+ <p>@@@ reserve SMS sending to widgets verified by the operator?</p>
+
+ </div>
+
+ <p>@@@
In summary:</p>
<ul>
<li>the user of a device delegates authority to an external policy
@@ -360,8 +325,10 @@
</p>
</section>
- <section id='delegated-authority-case-rqmts' class='informative'>
+
+ <section id='delegated-authority-case-rqmts'>
<h4>Requirements</h4>
+ <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>
<ul>
<li><p>Policy SHOULD be defined in a portable device-independent
manner.</p>
@@ -379,6 +346,9 @@
achieving the desired configuration across all devices.
</p>
</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>
<li>It SHOULD be possible to update portions of policy
independently.
<p>
@@ -427,8 +397,10 @@
<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>
+ for sensible access control decisions. (features )</li>
+ <li>The security framework SHOULD allow users to have control
+ over general configuration of security
+ decisions</li>
</ul>
<p>
Note that separation of the security framework from policy
@@ -436,67 +408,11 @@
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'>
+ </section>
+</section>
+</section>
+ <section id="threats" class='appendix'>
<h3>Security and Privacy Threats</h3>
<p>
This section outlines some threats related to
Received on Wednesday, 8 September 2010 16:07:43 UTC