- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 10 Mar 2010 16:23:10 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/policy-reqs
In directory hutz:/tmp/cvs-serv8977
Modified Files:
Overview.html
Log Message:
add access control definition, change designators for privacy aspects, completing ACTION-102, ACTION-103
Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/policy-reqs/Overview.html,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -d -r1.17 -r1.18
--- Overview.html 10 Mar 2010 10:53:33 -0000 1.17
+++ Overview.html 10 Mar 2010 16:23:08 -0000 1.18
@@ -41,22 +41,44 @@
<h2>Definitions</h2>
<p>The following definitions are used in this document.</p>
<dl>
+ <dt>Access Control</dt>
+ <dd><p>It is referred to the management of controlling access to
+ device API and
+ its underlying resources i.e. whether to allow or disallow
+ the
+Access Control is a function of two methods that may or may not be
+mutually exclusive:</p>
+<ol>
+<li><p>Access Control by declaration - refers to a method wherein the
+author of the application seeks access to specific device APIs i.e. by
+declaring the application author's intent. Example, by declaring the
+Feature to which the application intents to access and the domain or
+network resources that may need to access that particular Feature during
+the lifecycle of the application.</p></li>
+<li>Runtime Policy Enforcement - refers to method wherein a
+security policy is applied at the runtime based on underlying
+implementation of the Device API, which maybe based on several factors
+e.g. the context in which the device API is accessed, terms of
+deployment, etc.</li>
+</ol>
+ </dd>
<dt>Application</dt>
- <dd>Code that may make use of DAP Device APIs. Application
+ <dd><p>Code that may make use of DAP Device APIs. Application
code can be widgets or web
- applications running in a browser, for example. </dd>
+ applications running in a browser, for example.</p></dd>
<dt>Device API</dt>
- <dd>A Device API is a collection of Javascript interfaces
+ <dd><p>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.
+ Capabilities.</p>
</dd>
<dt>Device Capability</dt>
- <dd>A Device Capability is a device resource or device functionality, which may
+ <dd><p>A Device Capability is a device resource or device
+ functionality, which may
require access
- control.</dd>
+ control.</p></dd>
<dd> Examples of device capabilities are the ability to
read a local
file, or to discover nearby Bluetooth devices, or to send an
@@ -67,7 +89,7 @@
uses to access
them.
</dd>
- <dd>
+ <dd><p>
Although there are simple Device APIs that provide access only to
a single Device Capability, there are also
more complex APIs that expose multiple Device Capabilities; examples
@@ -76,18 +98,18 @@
ability to access documents stored locally and attach them to outgoing
messages. Therefore, enabling or disabling access to a specific Device
Capability may not directly correspond to enabling or disabling
- access to a single Device API interface.
+ access to a single Device API interface.</p>
</dd>
<dt>Feature</dt>
- <dd>A Feature is a set of Device APIs that provides access
+ <dd><p>A Feature is a set of Device APIs that provides access
to specified Device Capabilities. A Feature is the unit of expression of dependencies by Web
- Applications.</dd>
+ Applications.</p></dd>
<dt>Implicit Consent</dt>
- <dd>A user action that is semantically meaningful in the
+ <dd><p>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>
+ taking a photograph.</p></dd>
</dl>
</section>
@@ -556,37 +578,37 @@
<p>There are four potential types of privacy requirements for device
APIs:</p>
<ul>
-<li><p>T1: Requirements for functionality provided strictly by user
+<li><p><code>UA-Functionality</code>: Requirements for functionality provided strictly by user
agents (without relation to any policy information provided by an
application or a user)</p></li>
-<li><p>T2: Requirements for policies to be provided by applications</
+<li><p><code>App-Policy</code>: Requirements for policies to be provided by applications</
p></li>
-<li><p>T3: Requirements for policies to be provided by users</p></li>
-<li><p>T4: Requirements for what applications can do with the data
+<li><p><code>User-Policy</code>: Requirements for policies to be provided by users</p></li>
+<li><p><code>Data-Use</code>: Requirements for what applications can do with the data
they receive</p></li>
</ul>
-<p>An example of T1 would be akin to the Geolocation requirement that
+<p>An example of <code>UA-Functionality</code> would be akin to the Geolocation requirement that
user agents must obtain express user permission before sending
-location. An example of T2 would be a requirement that applications
+location. An example of <code>App-Policy</code> would be a requirement that applications
provide information about the purpose, secondary uses, retention time,
or other policies about the data they are requesting to the UA so that
-they may be accessible to users. An example of T3 would be a
+they may be accessible to users. An example of <code>User-Policy</code> would be a
requirement that UAs provide a way for users to send information about
their policy preferences -- "don't disclose my data to anyone" or
-"make my data public" for example -- to applications. An example of T4
+"make my data public" for example -- to applications. An example of <code>Data-Use</code>
would be akin to the Geolocation requirement that applications must
only use the location information for the task for which it was
provided to them.</p>
<p class="issue">Will the document support all four types of
requirements, and if not, which subset will it support? If the
-document supports requirements of types T2 or T3, will it provide
+document supports requirements of types <code>App-Policy</code> or <code>User-Policy</code>, will it provide
hooks to allow the exchange of policies to be automated? How each
aspect of privacy gets addressed (or not) will depend on which kinds
of requirements are included. The Geolocation WG ultimately decided to
-support only requirements of types T1, T2, and T4, without automated
-support for T2 (i.e., there are normative requirements for what
+support only requirements of types <code>UA-Functionality</code>, <code>App-Policy</code>, and <code>Data-Use</code>, without automated
+support for <code>App-Policy</code> (i.e., there are normative requirements for what
applications are supposed to disclose to users on their own sites, but
as [[PRIVACY-ISSUES-GEO]] points out, most sites implementing the API
are not complying).</p>
@@ -603,12 +625,12 @@
<section>
<h4>Notice</h4>
-<p>T1: Whether the UA needs to notify users before their data is sent
+<p><code>UA-Functionality</code>: Whether the UA needs to notify users before their data is sent
to a application; how that notification happens; what that notice
should contain; whether the UA needs to notify users as their data is
sent to applications</p>
-<p>T2: Whether applications need to provide notice of the fact that
+<p><code>App-Policy</code>: Whether applications need to provide notice of the fact that
they are collecting user data and the primary purpose for which it is
being collected; how that notification happens; what that notice
should contain</p>
@@ -627,7 +649,7 @@
<section>
<h4>Consent</h4>
-<p>T1: Whether the UA needs to obtain consent of users to send their
+<p><code>UA-Functionality</code>: Whether the UA needs to obtain consent of users to send their
data to applications; how robust that consent needs to be (i.e.,
"express," "affirmative," "implied," "implicit," or something else);
how that consent is obtained; whether that consent should be
@@ -645,9 +667,9 @@
design APIs so that Web developers can request as little information
as they need to accomplish their goals.</p>
-<p>T1: Whether the UA needs to allow users to change or limit the
+<p><code>UA-Functionality</code>: Whether the UA needs to allow users to change or limit the
amount, granularity and/or frequency of data sent to applications.
-Examples of potential requirements of type T1 include:</p>
+Examples of potential requirements of type <code>UA-Functionality</code> include:</p>
<ul>
<li><p>APIs SHOULD make it easy to request as little information as
@@ -672,20 +694,20 @@
allowed.</p></li>
</ul>
-<p>T2: Whether applications can specify their desired amount,
+<p><code>App-Policy</code>: Whether applications can specify their desired amount,
granularity or frequency</p>
-<p>T3: Whether users can specify their desired amount, granularity or
+<p><code>User-Policy</code>: Whether users can specify their desired amount, granularity or
frequency to applications</p>
-<p>T4: Whether applications must request the minimal data necessary
+<p><code>Data-Use</code>: Whether applications must request the minimal data necessary
for their purposes</p>
</section>
<section>
<h4>Control</h4>
-<p>T1: Whether the UA needs to provide a mechanism for consent to be
+<p><code>UA-Functionality</code>: Whether the UA needs to provide a mechanism for consent to be
revoked; what revoking consent means; what the default settings are
for whether and to whom user data is sent; what the default settings
are for granularity and frequency; whether the UA needs to provide a
@@ -696,7 +718,7 @@
<section>
<h4>Access</h4>
-<p>T1: Whether the UA needs to allow users to view the applications
+<p><code>UA-Functionality</code>: Whether the UA needs to allow users to view the applications
with whom they've shared data and at what granularity and frequency;
whether the UA needs to allow users to view the history of the user's
data sharing with each application; whether the UA needs to allow
@@ -706,13 +728,13 @@
<section>
<h4>Retention</h4>
-<p>T2: Whether applications can specify how long they would like to
+<p><code>App-Policy</code>: Whether applications can specify how long they would like to
retain user data</p>
-<p>T3: Whether users can specify how long they would like applications
+<p><code>User-Policy</code>: Whether users can specify how long they would like applications
to retain their data</p>
-<p>T4: Whether applications must dispose of collected data after
+<p><code>Data-Use</code>: Whether applications must dispose of collected data after
fulfilling the purpose for which it was collected; whether
applications are bound by some default retention period</p>
</section>
@@ -720,13 +742,13 @@
<section>
<h4>Identifiability</h4>
-<p>T2: Whether applications can specify that they would like to link
+<p><code>App-Policy</code>: Whether applications can specify that they would like to link
the requested data to the user's identity or identifier</p>
-<p>T3: Whether users can specify their preference about having
+<p><code>User-Policy</code>: Whether users can specify their preference about having
requested data linked to their identities or identifiers</p>
-<p>T4: Whether applications must use data in the least identifiable
+<p><code>Data-Use</code>: Whether applications must use data in the least identifiable
format as possible; whether requesters must de-identify data as soon
as it is no longer needed in identifiable form</p>
</section>
@@ -734,13 +756,13 @@
<section>
<h4>Secondary Use</h4>
-<p> T2: Whether applications can specify secondary purposes for which
+<p> <code>App-Policy</code>: Whether applications can specify secondary purposes for which
they would like to use the data (other than the primary purpose)</p>
-<p> T3: Whether users can specify their preferences about having their
+<p> <code>User-Policy</code>: Whether users can specify their preferences about having their
data used for secondary purposes</p>
-<p> T4: Whether applications can use data for secondary purposes</p>
+<p> <code>Data-Use</code>: Whether applications can use data for secondary purposes</p>
</section>
<section>
@@ -750,15 +772,15 @@
requester is in a position to store and redistribute these data, with
or without the user consent.</p>
-<p> T2: Whether applications can specify that they would like to
+<p> <code>App-Policy</code>: Whether applications can specify that they would like to
disclose user data, to whom, at what granularity, and at what
identifiability</p>
-<p> T3: Whether users can specify their preferences about having their
+<p> <code>User-Policy</code>: Whether users can specify their preferences about having their
data disclosed, to whom, at what granularity, and at what
identifiability</p>
-<p> T4: Whether applications can disclose data to third parties, to
+<p> <code>Data-Use</code>: Whether applications can disclose data to third parties, to
whom, at what granularity, and at what identifiability</p>
</section>
Received on Wednesday, 10 March 2010 16:23:12 UTC