- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Tue, 10 Nov 2009 17:02:31 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/policy-reqs
In directory hutz:/tmp/cvs-serv9326
Modified Files:
Overview.html
Log Message:
additional edits to complete ACTION-49
Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/policy-reqs/Overview.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- Overview.html 8 Nov 2009 18:59:31 -0000 1.2
+++ Overview.html 10 Nov 2009 17:02:29 -0000 1.3
@@ -30,6 +30,11 @@
further work. It is based on input documents and list
discussion.
</p>
+ <p>
+ The security framework described in this document is intended
+ to be applicable both to widgets and web applications (web
+ site access to Device APIs).
+ </p>
</section>
<section class='informative'>
@@ -37,45 +42,90 @@
<p>The following definitions are used in this document.</p>
<dl>
<dt>Application</dt>
- <dd>Code that may make use of DAP APIs. This can be widgets, web
+ <dd>Code that may make use of DAP Device APIs. Application
+ code can be widgets or web
applications running in a browser, for example. </dd>
- <dt>API</dt>
- <dd>Collection of interfaces structured in terms of methods and
- properties used by applications to access device
- capabilities. Related interfaces may be grouped into
- modules. Interfaces may be defined using WebIDL. Note that
- interfaces, by themselves, are not necessarily associated
- with a specific
- device capability.
- </dd>
- <dt>Feature</dt>
- <dd>A Feature is a defined way
-of accessing certain specified define capabilities using an associated API.</dd>
- <dt>device capability</dt>
- <dd>device resource or functionality requiring access
+ <dt>Device API</dt>
+ <dd>A Device API is a collection of Javascript interfaces
+ structured in
+ terms of methods and properties. Device APIs are used by
+ applications to access Device
+ Capabilities.
+ </dd>
+ <dt>Device Capability</dt>
+ <dd>A Device Capability is a device resource or device functionality
+ requiring access
control.</dd>
- <dd> Examples of device capabilities are the ability to
+ <dd> Examples of device capabilities are the ability to
read a local
file, or to discover nearby Bluetooth devices, or to send an
SMS
- message. In principle, device capabilities can be defined
+ message. Device Capabilities may be defined
in a way that is
- independent of the specific APIs that an application uses to access
+ independent of the specific Device APIs that an application
+ uses to access
them.
</dd>
+ <dt>Feature</dt>
+ <dd>A Feature is a set of Device APIs that provides access
+ to specified Device Capabilities. A Feature is identified
+ uniquely by IRI, and is the unit of expression of dependencies by Web
+ Applications.</dd>
+ <dt>Implicit Consent</dt>
+ <dd>A user action that is semantically meaningful in the
+ application context but which also implies that the user
+ wishes the action to proceed. An example is pressing a camera
+ shutter to take a photograph, implying consent to the act of
+ taking a photograph.</dd>
</dl>
</section>
- <section>
- <h2>Out of Scope</h2>
+ <section class='informative'>
+ <h2>Use Cases</h2>
+ <p>Example Widget use cases, to give examples of the types of
+ policy that might be expressed:</p>
<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 weather.example.com can access
+ geolocation coordinates if the user says it’s OK.
+ </li><li>
+ The weather.example.com Widget can connect to
+ weather.example.com 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>
+ </ul>
+ </p>
+ <p>Example web site use cases, to give examples of the types of
+ policy that might be expressed:</p>
+ <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 mynetwork.example.com can read phone status
+ properties.
+ </li><li>
+ Reliably identified Websites can send and receive SMS except to premium
+ rate numbers.
+ </li><li>
+ evil.example.com cannot access any device APIs.
+ </li><li>
+ The weather.example.com foo widget can access geolocation coordinates but
+ only if it’s embedded on the foo home page.
+ </li>
+ </ul>
</p>
- <ul>
- <li>The management of security policies ... is out of scope
- (charter)</li>
- <li>Identity Revocation</li>
- </ul>
</section>
<section>
@@ -168,9 +218,12 @@
decisions</li>
<li>Users SHOULD have control over general configuration of security
decisions</li>
+ <li>The security policy framework SHOULD be able to record
+ security configuration choices and interactive policy
+ decisions using the policy markup language format.</li>
</ul>
</section>
- <section class='informative'>
+ <section>
<h3>Rationale</h3>
<p>
Prompts should be eliminated whenever possible. Many prompts do not provide
@@ -187,20 +240,31 @@
less inclined to take any security decision seriously, which further
undermines the effectiveness of a user-driven access control system.
</p><p>
- There will unavoidably be situations, however, where the
- user is required to
- make access control decisions when web applications wish to
- use sensitive
- APIs. The key issue remains, therefore, and DAP needs to
- ensure a framework
- is provided that allows it to happen, and maximizes its
- effectiveness,
- rather than seeking to eliminate it altogether.
+ The semantics of some APIs are defined such that user
+ interaction is essential to use of the API. An example is
+ a camera API that enables the user to take a photograph, but
+ is defined to require the user to press a shutter key to take
+ the photograph. Another example
+ is an API that produces a message template, but requires the
+ user to press "send" to actually send the message.
</p><p>
- Modal prompts (i.e. prompts that block all other user
+ Such user actions constitute implicit consent, since the user
+ has a choice to perform them and doing so implies consent to
+ use the associated Device Capabilities. Such implicit consent
+ eliminates the need for a security access dialog for that
+ action since it is implicit in the application semantics.
+ </p><p>
+ Device APIs may also be defined such that implicit consent is not
+ implied. Examples are a camera API that takes a photograph without
+ user involvement, or a messaging API that sends a message without the
+ user pressing "send". In these cases policy and/or
+ user dialogs may be required.
+ </p><p>
+ It is important to note that modal prompts (i.e. prompts
+ that block all other user
interaction until
- dismissed) seriously compromise user experience and are
- avoidable.
+ 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.
@@ -210,24 +274,17 @@
so that all
operations that could potentially trigger a prompt are
asynchronous.
- </p><p>
- The semantics of some APIs can be defined such that they
- require user interaction that is meaningful to the user, yet
- also imply consent to the action. Such implicit consent
- eliminates the need for a security access dialog entirely,
- incorporating it into the application semantics. An example is
- a camera API that enables the user to take a photograph, but
- requires them to press a shutter key to do so. Another example
- is an API that produces a message template, but requires the
- user to press "send" to actually send the message.
- </p><p>
- Given the wide range of possible valid means of eliciting
- user security
- decisions, DAP should be minimally prescriptive about the
- user experience,
- and should not assume that the same user experience is
- appropriate for every
- API.
+ </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 class='informative'>
@@ -281,33 +338,6 @@
effectively.
</p>
</li>
- <li>Application control vs user agent control
- <p class='issue'>
- Does application or user agent or both determine which prompts are
- presented to user?
- </p>
- <p>
- This issue is whether the application, or the user agent, or both, have a
- role in determining the extent to which prompts may appear, and at what
- time.
- </p><p>
- Usually an application itself knows whether or not the user has implicitly
- given permission for a particular operation. For example, after a user as
- explicitly clicked the "send email now" button, he should not be faced with
- a dialog saying "this application wishes to connect to the
- network ....".
- The user agent, by itself, cannot tell if the application has earned the
- right to perform an operation without further explicit user acknowledgment,
- so there is an argument for the application being able to influence whether
- or not the UA intervenes with a prompt. This, of course, requires greater
- trust in the application than would be necessary if the UA intervened
- unconditionally.
- </p><p>
- DAP should determine whether or not there is a role that the application
- itself can play in how and when security decisions are elicited explicitly
- from the user.
- </p>
- </li>
</ul>
</section> <!-- open issues -->
</section> <!-- user control -->
@@ -321,10 +351,8 @@
<li>Capabilities MUST be defined for all sensitive device resources
and functionality.
</li>
-
- <li>The security framework MUST support identifying device
- capabilities
- independently of API using IRIs.
+ <li>Capabilities MUST be identified by strings associated
+ with API definitions produced by the DAP WG.
</li>
<li>The security framework MUST support access control
decisions based on device capabilities,
@@ -334,6 +362,7 @@
decisions based on device features (one or more capabilities
bound to a device API).
</li>
+ <li>Features MUST be identified by IRI.</li>
<li>The security framework MUST support sufficient granularity
for sensible access control decisions.
</li>
@@ -368,17 +397,41 @@
<h3>Open Issues for Resolution</h3>
<p>
</p>
- <p class='issue'>
- Is access control at the feature level required or is access control
- at the device capability level adequate?
- </p>
- <p class='issue'>
- Define features by IRI and capabilities by string? e.g. BONDI identifies features by IRI, but defines a separate
- namespace, centrally managed, for device capabilities (e.g.
- device.io.file.read).
- </p>
</section>
</section>
+<section>
+ <h2>Access Control</h2>
+ <section>
+ <h3>Requirements</h3>
+ <p></p>
+ <ul>
+ <li>Access control decisions may be made at both the
+ granularity of Features
+ and Device Capabilities.
+ </li>
+ </ul>
+ <p class='issue'>
+ Is access control at the feature level required or is access control
+ at the device capability level adequate?
+ </p>
+ </section>
+ <section class='informative'>
+ <h3>Rationale</h3>
+ <p>
+ </p>
+ </section>
+</section>
+<section>
+ <h2>Out of Scope</h2>
+ <p>
+ </p>
+ <ul>
+ <li>The management of security policies ... is out of scope
+ (charter)</li>
+ <li>Identity Revocation</li>
+ </ul>
+</section>
+
<section class='appendix'>
<h2>Acknowledgements</h2>
<p>
Received on Tuesday, 10 November 2009 17:02:41 UTC