2009/dap/policy-reqs Overview.html,1.50,1.51

Update of /sources/public/2009/dap/policy-reqs
In directory hutz:/tmp/cvs-serv27366

Modified Files:
	Overview.html 
Log Message:
adding a few informative references


Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/policy-reqs/Overview.html,v
retrieving revision 1.50
retrieving revision 1.51
diff -u -d -r1.50 -r1.51
--- Overview.html	10 Sep 2010 12:58:16 -0000	1.50
+++ Overview.html	10 Sep 2010 13:05:41 -0000	1.51
@@ -61,8 +61,8 @@
       <h2>Introduction</h2>
       <p>
         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.</p>
+        Web sites and applications access to device resources, including geolocation [[GEOLOCATION-API]], personal information such as calendar and contacts [[CONTACTS-API]],
+        system information [[SYSINFOAPI]] such as network information, etc. Much of this information is sensitive and can be misused.</p>
       <p>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>This document explores use cases for such a framework through user stories, and derives requirements both for APIs and the framework based on these use cases.</p>
@@ -81,6 +81,8 @@
         <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>These interactions can be relevant both for a Web site accessed through a browser, or an installable Web application (e.g. a widget [[WIDGETS]]) accessed through a dedicated runtime engine.</p>
+
     <section id='userconsent'>
       <h3>Granular User Consent</h3>
       <section id='userconsent-story-1'>
@@ -165,6 +167,8 @@
 
 	<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>Similarly, the user can be offered to validate a set of permissions in a batch when installing a widget, where the permissions can be identified through the <code>feature</code> element [[WIDGETS]].</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>

Received on Friday, 10 September 2010 13:05:48 UTC