W3C home > Mailing lists > Public > public-dap-commits@w3.org > January 2010

2009/dap/policy-reqs Overview.html,1.3,1.4

From: Laura Arribas via cvs-syncmail <cvsmail@w3.org>
Date: Wed, 06 Jan 2010 11:32:22 +0000
To: public-dap-commits@w3.org
Message-Id: <E1NSU7i-0008QX-OP@lionel-hutz.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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 6 January 2010 11:32:24 GMT