- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 16 Jun 2010 19:10:40 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/policy-reqs
In directory hutz:/tmp/cvs-serv13162
Modified Files:
Overview.html
Log Message:
additional validation
Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/policy-reqs/Overview.html,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -d -r1.37 -r1.38
--- Overview.html 16 Jun 2010 18:47:10 -0000 1.37
+++ Overview.html 16 Jun 2010 19:10:38 -0000 1.38
@@ -18,8 +18,8 @@
</head>
<body>
<section id='abstract'>
-This document defines Device API Access Control Requirements
-and the corresponding use cases.
+ This document defines Device API Access Control Requirements
+ and the corresponding use cases.
</section> <!-- abstract -->
<section id='introduction'>
@@ -37,8 +37,8 @@
<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
+ <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
@@ -46,28 +46,29 @@
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.
+ 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.
-<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>
+ <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'>
@@ -122,10 +123,10 @@
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>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
@@ -159,8 +160,6 @@
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
@@ -172,34 +171,44 @@
</p>
<ul>
<li>
- the user of a device is the sole authority that decides access rights of
+ 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
+ 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
+ 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.
+ 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.
+ 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>
+ </section> <!-- PM1 -->
<section>
<h4>Use case PM2: user-delegated configuration</h4>
<p>
@@ -207,65 +216,89 @@
</p>
<ul>
<li>
- the user of a device delegates authority for access control policy to an
+ 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
+ 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
+ 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
+ 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.
+ 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
+ This use-case mirrors current practice with products such as
+ virus scanners or
other malware detectors.
</p>
- </section>
+ </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
+ 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>
+ </section> <!-- PI2 -->
<section>
<h4>Prompts</h4>
<p>
- Prompts should be eliminated whenever possible. Many prompts do not provide
- any meaningful security because:</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
+ <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
+ <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
+ 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>
@@ -297,16 +330,21 @@
</p>
<div class="issue">
<ul>
- <li> <p class='issue'>User authorization vs other policy authority</p>
+ <li> <p class='issue'>User authorization vs other
+ policy authority</p>
<p class='issue'>
- Support for trust models other than user security decisions needed?
+ 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>
+ <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
@@ -315,62 +353,84 @@
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
+ 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.
+ 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>
+ 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
+ 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
+ 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
+ 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.
+ 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>
+ </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
+ <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
+ <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>
@@ -387,15 +447,15 @@
</ul>
<p>
</p>
- </section>
- </section> <!-- user control rqmts -->
+ </section> <!-- portable -->
+ </section> <!-- user control rqmts -->
</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>
+ enterprise or network operator managed access control.</p>
+ <section>
<h4>Use case PM3: external policy authority</h4>
<p>
In this use case:
@@ -430,7 +490,7 @@
authority (eg to control its exposure to the financial risk of abuse of device
APIs).
</p>
-</section>
+</section> <!-- PM3 -->
<section>
<h4>Use case PI1: device-independent policy definition</h4>
<p>
@@ -442,7 +502,7 @@
achieving the desired configuration across all devices. This is relevant to
Policy Management use case PM3.
</p>
-</section>
+</section> <!-- PI1 -->
<section>
<h4>Use case PI3: policy provisioning as part of service deployment</h4>
<p>
@@ -456,7 +516,7 @@
authoring the configuration updates separately for each target device,
platform, or UA.
</p>
-</section>
+</section> <!-- PI3 -->
<section>
<h3>Policy interoperability</h3>
<p>
@@ -471,46 +531,121 @@
</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?
+ 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.
+ 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>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 kowledge that their personal data will not leak in any way.
+ <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>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>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> <!-- policy use cases -->
- <section>
+<section>
<h2>Capabilities</h2>
<p>
-Declarative policy is used for access control decisions for various
+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>
Received on Wednesday, 16 June 2010 19:10:42 UTC