OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xacml] DLP & NAC Profilwe WD 7 updates and open issues

1.  We're still looking for a volunteer to populate the sample policies in 4.2.
2.  I think we want the attributes to be associated with the proper categories, such as recipient-subject, recipient-machine, and ip-address should be associated with recipient subject category.  We should fix this in the next WD, or pull -07 and re-submit it with the corrections.
3.  Agree that variation in algorithms would make better examples.
4.  I don't know that we would want to promote that as a best practice, unless it's called out specifically to force the behavior described.  The Indeterminate with Missing Attributes is definitely useful in many circumstances.

-----Original Message-----
From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Hal Lockhart
Sent: Thursday, June 26, 2014 11:42 AM
Subject: [xacml] DLP & NAC Profilwe WD 7 updates and open issues

I fixed the typo in the definition of ipAddress-pattern (line 193). I cleaned up a variety of issues with the example policies. I believe the policies are now correct, match their summaries and are consistent with the attribute definitions in the profile.

I note the following open issues:

1. Section 4.2 (NAC) has two sections for sample policies, but no policies.

2. Section 2.3 raises questions about how we model Subject Categories. XACML defines 5 Subject category types: access subject, recipient subject, intermediary subject, codebase and requesting machine. The implication of this is that each of these are potentially autonomous actors with their own set of all kinds of subject attributes. In the profile we have attributes requesting-machine, recipient-machine, ip address and codebase. They are all listed at subject attributes and in the examples they are of category access subject. Is this the way we want it to work or should they be associated with the other subject category types? 

It is clear that a person, a machine (smartphone) and a codebase can all have different ids and authentication methods, for example. Probably only a machine can have a ip address, so if we don't otherwise need to use requesting machine it seems ok to associate the ip address with the access subject. In the XACML scheme, source of the request can be decomposed into the three categories: access subject, requesting machine and codebase, but for recipient subject and intermediary subject person, code and machine are all lumped together.

3. The examples use the first applicable rule combining algorithm throughout. This works because every policy has only one rule. However if anyone modifies the policies either as an example or to use in their own PDP and introduces additional rules, the policies may not function as expected. Should we change the rule combining algorithm to something else, such as deny overrides?

4. All of the attribute designators in the examples set "must be present" to false. Since as far as I can see, all the attribute values are required to make a decision in each case, the effect of this will be to return Deny anytime the PEP omits an attribute value instead of returning Indeterminate with mussing attributes, allowing the PEP to retry. Is this what we should designate as best practice?


To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]