[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.