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

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

Laura

I think there is a natural division between (1) defining trust domain  
and policy processing and (2) XACML profiling.

Thus  Policy Framework can include trust domain and policy processing  
models, definition of resource, environment and security attributes,  
and discussion  of applicability and Web and REST cases as well as  
trust domain ambiguities (or how to include multiple trust domains).  
As Steve mentioned, it is probably useful to define some standard  
trust domains.

An XACML profile can reference specific XACML  specifications, define  
schema definitions, and detailed processing rules that are XACML  
specific.

An implementer thus can use the XACML profile to create unified trust/ 
policy processing or maybe choose to not use XACML etc. Some decisions  
here regarding conformance but I think the separation is useful.

I also would like to see how simple the model can be made -  might we  
be able to simplify flows and layering?

Thus, to be specific,  in the current framework draft, sections 2,  
3.1, 3.3, 3.4 and 3.5 could remain in framework; sections 3.2 3.6-3.20  
and 4  moved to XACML profile. Section 5 could go into a separate  
examples document. Out of scope can go into requirements,   Added to  
framework would be trust domain model contribution from Nokia.

Doing this separation would allow us to focus first on the model.

What do you think?

regards, Frederick

Frederick Hirsch
Nokia



On May 5, 2010, at 5:46 AM, ext Arribas, Laura, VF-Group wrote:

>
> 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.
>
> <Trust domain request.png><Access request.png>

Received on Wednesday, 12 May 2010 13:14:13 UTC