- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 25 Aug 2010 13:54:49 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/policy-reqs
In directory hutz:/tmp/cvs-serv15284
Modified Files:
Overview.html
Log Message:
update to allow both trusted widgets and applications, enable trust by
other means than signatures, move issues for features/capabilities to
features document
Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/policy-reqs/Overview.html,v
retrieving revision 1.42
retrieving revision 1.43
diff -u -d -r1.42 -r1.43
--- Overview.html 18 Aug 2010 14:42:03 -0000 1.42
+++ Overview.html 25 Aug 2010 13:54:47 -0000 1.43
@@ -49,12 +49,12 @@
interactions by considering three related use cases:</p>
<ul>
<li>web browser web pages</li>
- <li>trusted widgets</li>
+ <li>trusted widgets and applications</li>
<li>delegated authority</li>
</ul>
<p>They are related because requirements for the web may
also apply to trusted widgets, and those various requirements may
- also apply to delegated authority, likewise trusted widget
+ also apply to delegated authority, likewise trusted widget/application
requirements may apply to delegated authority case. Each level may
add additional
requirements. For example, the requirement for minimal user-dialogs
@@ -229,18 +229,17 @@
</section> <!-- web -->
<section id='trusted-widget-case'>
- <h3>Trusted Widget</h3>
+ <h3>Trusted Widget or Application</h3>
<section id='widget-case-overview'>
<h4>Use Case Overview</h4>
- <p>The trusted Widget Device API use case is where a signed
- 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
+ <p>The trusted Widget or application Device API use case is
+ where a trusted widget or application is
+ delivered to a device.
+ In this case the entire widget or application
+ can be trusted as an desktop application would be, so if installed
should have a set of privileges associated with a trusted
- software.</p>
- <p>Thus a trusted widget should be able to use all safe APIs that
+ software.
+ Thus it should be able to use all safe APIs that
could be used in the web case, but may also be able to use
additional
APIs that are not safe, such as APIs that do not require
@@ -249,18 +248,36 @@
controlled.
</p>
<p>
- A trusted widget might have explicit policy in which case it
+ Trust may be established in different ways, the most common being
+ through a validated signature on the widget or application package,
+ with a corresponding verification of the trust chain to a trusted root.
+ Alternative means of determining trust are also possible, such as
+ using a reputation or other mechanism.
+ </p>
+ <p>
+ Once trust is established, a trusted widget or application
+ might have explicit policy associated with it. In this 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.
+ trust. In this case user acceptance of the entire widget or
+ application ,
+ similar to personal computer application install, may be appropriate.
</p>
</section>
<section id='widget-case-rqmts'>
<h4>Requirements</h4>
- <p>
- </p>
+ <ul>
+ <li><p>Trust be established to a satisfactory level. In the
+ case of using
+ signature in conjunction with PKI mechanisms, the
+ signature MUST be
+ verified and the certificate chain MUST be validated to
+ a known trust
+ root.</p></li>
+ <li><p>Other mechanisms than signatures may be used if they
+ offer robust enough trust verification.</p></li>
+ </ul>
</section>
</section> <!-- trusted widget -->
<section id='delegated-authority-case'>
@@ -478,29 +495,6 @@
</li>
</ul>
</section>
- <section id="delegated-authority-issues">
- <h4>Issues</h4>
- <p class="issue">Whether requirements are needed specifying need
- to define
- capabilities in addition to
- features deferred since this is
- a higher level document at this time.
- </p>
- <p class="issue">Define features, capabilities as URIs, strings, both</p>
- <p class="issue">
- Features defined according to CRUD, one feature for Create,
- Read, Update, Delete?
- </p>
- <p class="issue">
- Feature parameters to avoid explosion of capabilities and
- features? e.g. file open with either read or write
- parameter.
- ( see
- <a href="http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/att-0120/minutes-2009-10-07.html#item03">discussions
- in minutes of October 7 call</a> )
- </p>
-
- </section> <!-- delegated authority issues -->
</section> <!-- delgated authority -->
<section id="threats">
Received on Wednesday, 25 August 2010 13:54:51 UTC