- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Tue, 17 Aug 2010 19:25:36 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/docs
In directory hutz:/tmp/cvs-serv8111
Modified Files:
policy-requirements-proposal.html
Log Message:
fix validation issues
Index: policy-requirements-proposal.html
===================================================================
RCS file: /sources/public/2009/dap/docs/policy-requirements-proposal.html,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -r1.3 -r1.4
--- policy-requirements-proposal.html 17 Aug 2010 19:19:24 -0000 1.3
+++ policy-requirements-proposal.html 17 Aug 2010 19:25:34 -0000 1.4
@@ -1,3 +1,4 @@
+<!DOCTYPE html>
<html>
<head>
<title>(Proposed Revision:) Device API Access Control Use Cases
@@ -46,13 +47,12 @@
<p>The management of security policies and revocation mechanisms are
out of scope.</p>
<p>The approach taken in this document is to simplify the possible
- interactions by considering three related use cases:
+ interactions by considering three related use cases:</p>
<ul>
<li>un-managed web</li>
<li>trusted widgets</li>
<li>delegated authority</li>
</ul>
- </p>
<p>They are related because requirements for the un-managed web may
also apply to trusted widgets, and those various requirements may
also apply to delegated authority, likewise trusted widget
@@ -74,7 +74,7 @@
<p>This case cannot assume a policy framework that is accepted and
managed for all parts of the web.</p>
<p>As a result any device API available to such web pages must
- observe these two requirements:
+ observe these two requirements:</p>
<ol>
<li>If no user-interaction is involved, use of the API must be
safe.</li>
@@ -82,7 +82,6 @@
API. This consent should appear as a part of the task specific
workflow, thus not necessarily appear as a permission dialog.</li>
</ol>
- </p>
<p>
A user may wish to establish a policy configuration (through
explicit
@@ -115,7 +114,7 @@
same manner as an un-managed web browser, since the risks
are the same.</p>
<p>
- In summary:
+ In summary:</p>
<ul>
<li>the user of a device is the sole authority that decides
access rights of applications;</li>
@@ -129,7 +128,6 @@
preferences and if such settings should be interoperable across
browsers and stored locally or remotely.</li>
</ul>
- </p>
</section>
<section id='web-case-rqmts'>
<h4>Requirements</h4>
@@ -162,7 +160,6 @@
just because that's what's needed for the application to
continue.</li>
</ul>
- </p>
<p>
If prompts are shown and dismissed as a matter of routine,
then the user is
@@ -299,7 +296,7 @@
other malware detectors.
</p>
<p>
- In summary:
+ In summary:</p>
<ul>
<li>the user of a device delegates authority to an external policy
provider;</li>
@@ -334,9 +331,7 @@
configuring device policy
using a secured device management interface).
</li>
-
</ul>
- </p>
<p>
In determining the policy, the policy authority has the
opportunity to define
@@ -352,7 +347,6 @@
</section>
<section id='delegated-authority-case-rqmts'>
<h4>Requirements</h4>
- <p>
<ul>
<li><p>Policy SHOULD be defined in a portable device-independent
manner.</p>
@@ -421,7 +415,6 @@
for sensible access control decisions. (features )
</li>
</ul>
- </p>
<p>
Note that separation of the security framework from policy
statements
Received on Tuesday, 17 August 2010 19:25:38 UTC