- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Tue, 17 Aug 2010 19:19:26 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/docs
In directory hutz:/tmp/cvs-serv7252
Modified Files:
policy-requirements-proposal.html
Log Message:
Clarify that untrusted widgets (either unsigned or with untrusted
signature) are treated same as un-managed browser case. Move policy
examples from widget section to delegated authority section. Added
text for trusted widget that it may be treated as delegated authority
type, or may require installation (user approval). All based on Claes review.
Index: policy-requirements-proposal.html
===================================================================
RCS file: /sources/public/2009/dap/docs/policy-requirements-proposal.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- policy-requirements-proposal.html 17 Aug 2010 18:53:14 -0000 1.2
+++ policy-requirements-proposal.html 17 Aug 2010 19:19:24 -0000 1.3
@@ -65,7 +65,7 @@
</section> <!-- introduction -->
<section id='web-case'>
- <h3>Un-managed Web Browser</h3>
+ <h3>Un-managed Web Browser and Untrusted Widgets</h3>
<section id='web-case-overview'>
<h4>Use Case Overview</h4>
<p>The un-managed web browser Device API use case is the one
@@ -109,7 +109,11 @@
delegated authority case a similar mechanism for remembering
state might be appropriate.
</p>
-
+ <p>
+ An un-trusted widget (i.e. unsigned widget or widget signed by an
+ unknown or untrusted authority) should be treated in the
+ same manner as an un-managed web browser, since the risks
+ are the same.</p>
<p>
In summary:
<ul>
@@ -233,7 +237,10 @@
<section id='widget-case-overview'>
<h4>Use Case Overview</h4>
<p>The trusted Widget Device API use case is where a signed
- widget is delivered to a device. In this case the entire widget
+ widget that has been signed by a party the device trusts is
+ delivered to a device (this implies signature verification and
+ trust chain
+ validation). In this case the entire widget
can be trusted as an application would be, so if installed
should have a set of privileges associated with a trusted
software.</p>
@@ -245,43 +252,19 @@
consent in each case. However this list must be carefully
controlled.
</p>
- </section>
- <section id='widget-case-rqmts'>
- <h4>Requirements</h4>
<p>
+ A trusted widget might have explicit policy in which case it
+ can be treated the same as in the delegated authority case
+ below, or it may not have explicit policy, but additional
+ API functionality may in general be allowed due to the
+ trust. In this case user acceptance of the entire widget,
+ similar to application install, may be appropriate.
</p>
</section>
- <section id='widget-policy-examples'>
- <h3>Policy Examples</h3>
+ <section id='widget-case-rqmts'>
+ <h4>Requirements</h4>
<p>
- These use cases are specific examples of statements or
- rules that may be
- expressed in a policy.
</p>
- <p>Example web site use cases, to give examples of the types of
- policy that might be expressed:</p>
- <ul>
- <li>
- A reliably identified website can access geolocation
- coordinates if the
- user confirms it’s OK.
- </li><li>
- Any website in a subdomain
- of <code>mynetwork.example.com</code> can read phone
- status
- properties.
- </li><li>
- Reliably identified websites can send and receive SMS
- except to premium
- rate numbers.
- </li><li>
- <code>evil.example.com</code> cannot access any device APIs.
- </li><li>
- The <code>weather.example.com</code> <var>foo</var> widget
- can access geolocation coordinates but
- only if it’s embedded on the <var>foo</var> home page.
- </li>
- </ul>
</section>
</section> <!-- trusted widget -->
<section id='delegated-authority-case'>
@@ -445,15 +428,38 @@
can be achieved using declarative
policy statements.
</p>
-
</section>
<section id='delegated-authority-case-examples'>
- <h3>Policy Examples</h3>
- <p>
- These use cases are specific examples of statements or
- rules that may be
- expressed in a policy.
- </p>
+ <h3>Policy Examples</h3>
+ <p>
+ This section provides specific examples of statements or
+ rules that may be
+ expressed in a policy.
+ </p>
+ <p>Example web site policy cases:</p>
+ <ul>
+ <li>
+ A reliably identified website can access geolocation
+ coordinates if the
+ user confirms it’s OK.
+ </li><li>
+ Any website in a subdomain
+ of <code>mynetwork.example.com</code> can read phone
+ status
+ properties.
+ </li><li>
+ Reliably identified websites can send and receive SMS
+ except to premium
+ rate numbers.
+ </li><li>
+ <code>evil.example.com</code> cannot access any device APIs.
+ </li><li>
+ The <code>weather.example.com</code> <var>foo</var> widget
+ can access geolocation coordinates but
+ only if it’s embedded on the <var>foo</var> home page.
+ </li>
+ </ul>
+ <p>Example widget policy cases:</p>
<ul>
<li>
A widget whose signature chains to operator root can
Received on Tuesday, 17 August 2010 19:19:27 UTC