- From: Laura Arribas via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 06 Jan 2010 11:32:22 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/policy-reqs
In directory hutz:/tmp/cvs-serv32286
Modified Files:
Overview.html
Log Message:
ACTION 63 - Review Policy Requirements doc
Document updated with agreed changes.
Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/policy-reqs/Overview.html,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -r1.3 -r1.4
--- Overview.html 10 Nov 2009 17:02:29 -0000 1.3
+++ Overview.html 6 Jan 2010 11:32:20 -0000 1.4
@@ -67,6 +67,17 @@
uses to access
them.
</dd>
+ <dd>
+ Although there will be simple Device APIs that provide access only to
+ a single Device Capability, it must be expected that there are also
+ more complex APIs that expose multiple Device Capabilities; examples
+ might include a camera API that provides the ability to geotag a photo
+ with the current location, or a messaging API that provides the
+ ability to access documents stored locally and attach them to outgoing
+ messages. Therefore, enabling or disabling access to a specific Device
+ Capability will not directly correspond to enabling or disabling
+ access to a single Device API interface.
+ </dd>
<dt>Feature</dt>
<dd>A Feature is a set of Device APIs that provides access
to specified Device Capabilities. A Feature is identified
@@ -102,6 +113,11 @@
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 evil.example.org.
+ </li><li>
+ An unsigned widget cannot launch another application without user
+ consent.
</li>
</ul>
</p>
@@ -174,9 +190,6 @@
</p>
<ul>
<li>Access control policy MUST be stated in declarative manner.</li>
- <li>The DAP security framework MUST allow a flexible choice of
- policy decisions for feature
- access to device capabilities.</li>
<li>It MUST be possible to declare policy in XML
language</li>
<li>The DAP policy language MUST define an XML syntax for
@@ -241,7 +254,7 @@
undermines the effectiveness of a user-driven access control system.
</p><p>
The semantics of some APIs are defined such that user
- interaction is essential to use of the API. An example is
+ interaction is essential to make 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
@@ -354,18 +367,7 @@
<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,
- independent of API
- </li>
- <li>The security framework MUST support access control
- 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>
</ul>
</section>
<section class='informative'>
@@ -388,9 +390,6 @@
application's private file, and a Bluetooth port needs to be distinguishable
from a USB serial port.
</p>
- <p>Using IRIs to identify capabilities and features allows the
- definition to be decentralized, allowing extensibility.
- </p>
</p>
</section>
<section class='informative'>
@@ -409,10 +408,20 @@
granularity of Features
and Device Capabilities.
</li>
+ <li>The security framework MUST support access control
+ decisions based on device capabilities, independent of API.
+ </li>
+ <li>The security framework MUST support access control
+ decisions based on features (one or more capabilities
+ bound to a device API).
+ </li>
+ <li>The security framework MUST support sufficient granularity
+ for sensible access control decisions.
+ </li>
</ul>
<p class='issue'>
- Is access control at the feature level required or is access control
- at the device capability level adequate?
+ ( see <a href="http://www.w3.org/2009/dap/track/issues/21">ISSUE-21 - OPEN</a> ) Is access control at the feature level required or is access control
+ at the device capability level adequate?
</p>
</section>
<section class='informative'>
Received on Wednesday, 6 January 2010 11:32:24 UTC