DLP & NAC Profilwe WD 7 updates and open issues

[Hal Lockhart <hal.lockhart@oracle.com>]

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?

Hal