RE: [Policy] ACTION-152: Merging NOKIA's input into the policy framework doc

Hi All:

In general I support Laura's proposal, though I think a number of details are going to have to be worked out. It makes a lot of sense from the point of view of policy management to make the simplifying assumption that trust and access policies are orthogonal and can be specified and managed separately. But it is certainly the case that trust and access policies do tend to get intertwined in practice:

-- An access policy is written in relation to some set of trust domains. If a trust policy is going to be useful, then the domains it specifies must match the domains in the access policy.  This is not so much of an issue if access policies are typically written for some well-known set of domains ("untrusted", "trusted third party", "manufacturer", etc.), but when access policies are written in terms of arbitrary trust domains, then the trust policies need to be closely matched to them. 

-- As Paddy noticed, the Nokia submission doesn't say anyting about trust domain ambiguity. There is nothing in the model that prevents trust policies from assigning more than one domain to a given application. Nokia's own implementation discourages trust policies that are ambiguous, but for a standard specification we will need to extend the specified algorithms to include multiple trust domains and combining rules.

The Nokia proposal makes the distinction between trust and access policies explicit, and I would argue that this is gives maximum flexibility to policy specification, but we will still have to work through the cases where they interact.

I also want to note that the Nokia submission separates the trust manager from the access manager for purposes of the specification but is not intended to say anything about implementation. In the security model there are two separate computations, for trust domain and for access, so the abstract specification provides two boxes to put these in. In practice these are likely to share implementation.

Steve


-----Original Message-----
From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of ext Arribas, Laura, VF-Group
Sent: Wednesday, May 05, 2010 5:47 AM
To: public-device-apis@w3.org
Cc: Hirsch Frederick (Nokia-CIC/Boston)
Subject: [Policy] ACTION-152: Merging NOKIA's input into the policy framework doc


Hi All,

I'd like to introduce a proposal to merge NOKIA's submission into Policy Framework doc. Below I try to point out how would this changes impact the current document. It would be good to discuss it in today's call and see what editorial changes are required and if these changes are going to bring major improvements to the security framework.

Major changes we need to agree upon:
-- Need to define two types of policies: trust policies and access policies..
-- First, a trust domain needs to be assigned to the web content (see attached pic - "Trust domain request.png"). This request comes from the access requester ("content engine" in the NOKIA doc), ie, the browser or widget engine.
-- To determine the trust domain subject attributes may be used.
-- The PDP (Policy Decision Point) assigns the trust domain based on the trust policy. In NOKIA's input there is a separate Trust Manager that takes care of trust policies and assigning a trust domain to the web content. In this proposal there is no separate Trust Manager. The PDP manages both trust and access policies.
-- The PEP (Policy Enforcement Point) assigns the trust domain to the web content and sends it back to the access requester. (In NOKIA's input document when access to an API is requested the "content engine"
(browser) sends the Trust Domain together with the requested API
operation.)
-- The trust domain is managed by the access requester (browser). For every access request the assigned trust domain is sent together with the request.. (see attached pic - "Access request.png")
-- For installed content such as widgets, the trust domain request may also be carried out by the installer, which stores the trust domain in the application registry where it can be retrieved by the widget engine.
-- To determine if the access is allowed or denied resource and environment attributes may be used.
-- The PDP assigns the access based on the access policy.

Where do these changes impact the document?
-- Currently the whole document refers to Security Policies --> We would need to differentiate between Trust and Access Policies.
-- Layer model (section 2.2): currently two layers - JS API Access Control Layer and Device Capability Access Control Layer. We would need to add a third layer - Trust Domain Access Control Layer.
-- Main changes to the Logical Model (Section 2.3). This section would need to be changed altogether. Include two dataflows for trust domain and access requests. The elements of both dataflows are very similar.
-- Section 2.4 defined access control policy structure. Another section would need to be defined for trust domain policy structure. Subject attributes make no sense in access control policies; these need to be included in the trust domain policies.
-- In the current document policies and policy sets can be nested. This concept may not make so much sense in this proposal.
-- Current section 2.5 Rule Processing works only for access policies. A new section on rule processing would need to be defined for trust domain policies.
-- Section 3.7 (Subject Match): the whole concept of subject match as it is now only makes sense in the case of trust policies.
-- Section 3.19 (Effect): the effects define in the current document only apply to access policies. For trust policies the effect would be a string with the name of the assigned trust domain.
-- Section 3.20 (Query): this section needs to be modified. We need to differentiate trust domain and access queries.

My concerns:
-- The definition of two types of policies involves major changes into the current security model and a whole new model needs to be defined for Trust policies. With the current security model, it is already possible to write a policy following a trust model approach.

Other comments we need to agree upon:
-- Replace DAP security framework term.
-- Divide the document into two: one covering the logical model (up to Section 3 in the current document) and another one for the actual definition of the security model (from section 3). I believe this was already agreed during last week's call.


Thanks,
Laura


Laura Arribas

Security Technologies Researcher
Vodafone Group R&D
 
Tel: +44 (0) 7775411861
Fax: +44 (0) 1635231776
E-mail: laura.arribas@vodafone.com


Vodafone Group Services Limited
Registered Office: Vodafone House, The Connection, Newbury, Berkshire
RG14 2FN
Registered in England No 3802001.

Received on Tuesday, 11 May 2010 18:59:31 UTC