- From: Dominique Hazael-Massieux via cvs-syncmail <cvsmail@w3.org>
- Date: Thu, 09 Sep 2010 08:05:39 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/policy-reqs
In directory hutz:/tmp/cvs-serv11702
Modified Files:
Overview.html
Log Message:
finished rewrite
Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/policy-reqs/Overview.html,v
retrieving revision 1.46
retrieving revision 1.47
diff -u -d -r1.46 -r1.47
--- Overview.html 8 Sep 2010 16:07:37 -0000 1.46
+++ Overview.html 9 Sep 2010 08:05:37 -0000 1.47
@@ -206,11 +206,16 @@
</div>
<h4>Analysis</h4>
+ <p>In many professional contexts, allowing access to private or sensors data available through connected devices creates an unacceptable risk.</p>
+ <p>In these contexts, being able to enforce and update a policy that determines who can make use of these data across devices and platforms can be a decisive aspect of the adoption of a given technology.</p>
+ <p>To that end, it should be possible to describe platform-independent and declarative policies that determine what APIs can be used from what Web site or application.</p>
</section>
<section id='delegated-authority-story2'>
<h4>User Story: Third-party protection against malware</h4>
<div class="story">
-
+ <p>Alice keeps a lot of her private and sensitive data on her phone. Having heard that her friend Charlie has had troubles with a phishing attempt recently, she would like to use a service to increase her safety.</p>
+ <p>She subscribes to a service operated by ACMEsafe: they define and maintain a set of rules that block access to certain APIs from unknown sites, facilitate access to sites that she has identified as trustable and that can be reliably identified.</p>
+ <p>Both Alice’s browser and widget runtime engine follow the rules expressed in the policy defined by ACMEsafe; these rules are updated on a regular basis on the device, after having verified their proper origin by checking their digital signature.</p>
</div>
<h4>Analysis</h4>
<p>The same way anti-virus and malware tools allow users to reduce their risk of being exposed to troubles on their computers, some users may want to choose to delegate authority for access control policy to an external service provider.</p>
@@ -224,101 +229,53 @@
regularly in
response to new information on known threats.
</p>
+
+ <p>This policy needs to be integrity-protected during various points in its life-cycle.</p>
+
</section>
<section id="delegated-authority-story2a">
<h4>User Story: User-defined cross-devices policies</h4>
<div class="story">
- <p>@@@
- A user may wish to establish a policy configuration (through
- explicit
- configuration of
- preferences, and remembered decisions) and there is the option
- of reusing this
- configuration across multiple devices. A user with multiple
- devices may wish
- for their security preferences to be consistent (or to at
- least have the
- option of consistency) across those devices. Rather than have
- to manually
- configure the preferences on each device, it should be
- possible for there to
- be a seamless security experience across devices, e.g. by
- switching SIM card
- between devices and as a result automatically applying a
- policy resident on
- the SIM card or synchronizing with a network-based policy
- management system. A
- specific case is the case where a user wishes to transfer a
- configuration from
- an old device to a new device. To be consistent with the
- delegated authority case a similar mechanism for remembering
- state might be appropriate.
- </p>
+ <p>Dave has been using advanced features on the Web from his phone for quite some time, and has thus accepted and rejected permissions from a large number of Web sites on his device.</p>
+ <p>But Dave is now looking to the brand new phone released by ACMEdev, and would like to migrate his settings to that new phone, which also uses a different browser.</p>
+ <p>Dave’s operator offers him to transfer seamlessly these settings from one phone to other, and informs him that they can also be used on his other connected devices.</p>
+ </div>
- <p>@@@
- If user decisions
+ <h4>Analysis</h4>
+ <p>If user decisions
are themselves expressible in the policy language, then they can be
- "remembered" by
- adding a policy-set and/or rule to the policy. Similarly, user
+ preserved by encoding them in a local policy. Similarly, user
configuration settings should be possible in the policy
language. This means that the policy document is not just a
way of creating
an initial policy configuration, but can be the sole and complete
representation of the access control configuration at any time.
- </p></div>
+ </p>
</section>
<section id='delegated-authority-story3'>
<h4>User Story: Operator-enforced usage limitations</h4>
<div class="story">
- <p>@@@ reserve SMS sending to widgets verified by the operator?</p>
-
+ <p>Dave has found a nice-looking widget for managing SMS and MMS messages, but is not sure if it is safe to install it.</p>
+ <p>He contacts his operator ACMEcom; they indicate that on their devices, only widgets that have been verified by them will be able to send SMS.</p>
+ <p>Dave checks the widget, sees that the only special permission it requires is access to messaging features, and feels confident that he can now install it.</p>
</div>
-
- <p>@@@
- In summary:</p>
- <ul>
- <li>the user of a device delegates authority to an external policy
- provider;</li>
- <li>
- an initial security policy configuration may be
- provided by the external
+ <h4>Analysis</h4>
+ <p>An initial security policy configuration may be
+ provided by an external
authority, together with any other associated device
configuration (such as
root certificates). The configured policy may
determine access control policy
without reference to the user, or may refer certain
- decisions to the user;
- </li>
- <li>The user may or may not be able to modify this policy;</li>
- <li>
- the policy may be updated periodically under the
- authority of the policy
- authority. Policy maintenance may also occur as the
- cumulative effect of
- certain user decisions being remembered.
- </li>
- <li>The configured policy, at any given time, may be stored
- locally on the device
- or may be stored remotely and be accessible via a network
- service, or both;
- </li>
- <li>The external policy authority may configure the
- policy as part of the
- commissioning of the device (e.g. a network operator's
- configuration applied by
- the manufacturer prior to sale, or an enterprise
- configuring device policy
- using a secured device management interface).
- </li>
- </ul>
+ decisions to the user.</p>
<p>
In determining the policy, the policy authority has the
opportunity to define
a policy that supports a specific objective - such as to
limit access to APIs
to only those web applications that are themselves
- distributed by the policy
+ distributed or vefiried by the policy
authority (e.g. to control its exposure to the financial
risk of abuse of device
APIs).
@@ -330,85 +287,23 @@
<h4>Requirements</h4>
<p class="note">The management of security policies and revocation mechanisms are out of scope of the Device APIs and Policy Working Group charter.</p>
<ul>
- <li><p>Policy SHOULD be defined in a portable device-independent
- manner.</p>
- <p>
- The reason for this requirement is that a single policy
- authority may need to define and configure a
- security policy for multiple dissimilar devices. A
- typical network operator's
- portfolio many include tens or even hundreds of
- models, each based on
- different platforms, and different UAs. A commonly
- supported interoperable
- format for configuration of a policy dramatically
- impacts the practicality of
- achieving the desired configuration across all devices.
- </p>
- </li>
- <li>The security policy framework SHOULD make it possible to record
+ <li>The security framework MUST express policies in a device-independent manner.</li>
+ <li>The security framework MUST express access control policies in a declarative manner; this declarative language SHOULD be in an XML syntax.</li>
+ <li>The security framework SHOULD make it possible to record
security configuration choices and interactive policy
decisions using the policy markup language format.</li>
- <li>It SHOULD be possible to update portions of policy
- independently.
- <p>
- Configuration of some parts of access control policy may
- be part of the
- overall configuration required to enable a particular
- application
- or service.
- This, along with many other configuration parameters,
- may be remotely
- configurable via device management. The configuration
- required to enable a
- service may be provided by the service provider as a
- policy fragment, to be
- added to the overall policy by the policy authority. An
- interoperable
- representation of such policy fragments would enable this to be
- done without
- authoring the configuration updates separately for each
- target device,
- platform, or UA.
- </p>
- </li>
- <li>Security Framework MUST be separable from policy
- rules.</li>
- <li>Access control policy MUST be stated in declarative
- manner.</li>
- <li>The DAP policy language MUST define an XML syntax for
- that language.</li>
- <li>It MUST be possible to provide integrity protection and
- source authentication for policy.
- <p>It should be possible for policy to be integrity protected during
- various points in its life-cycle.</p>
- </li>
- <li>The DAP security framework MUST NOT preclude different
- authorities defining the security policy.
- </li>
- <li>The Security Framework MUST allow multiple instantiations of a web
- runtime with independent security decisions</li>
- <li>The Security Framework MUST be application language
- independent</li>
- <li>The Security Framework MUST be Javascript capable and
- define a Javascript binding</li>
- <li>It MUST be possible to have separate policy decision and
- enforcement points</li>
- <li>The DAP security model SHOULD be compatible with the
+ <li>The security framework SHOULD make it possible to update portions of policy independently.</li>
+ <li>The security framework MUST provide integrity protection and source authentication for policy.</li>
+ <li>The security framework MUST NOT preclude different authorities defining the security policy.</li>
+ <li>The Security Framework MUST be Javascript capable and define a Javascript binding</li>
+ <li>The security framework MUST be compatible with the
same origin policy.</li>
<li>The security framework MUST support sufficient granularity
- for sensible access control decisions. (features )</li>
+ for sensible access control decisions.</li>
<li>The security framework SHOULD allow users to have control
over general configuration of security
decisions</li>
</ul>
- <p>
- Note that separation of the security framework from policy
- statements
- can be achieved using declarative
- policy statements.
- </p>
-
</section>
</section>
</section>
Received on Thursday, 9 September 2010 08:05:44 UTC