xacml — archive

[System]

Hi > In the proposal that I posted last Friday, I tried to make a couple of other > distinctions: a rule does not have an applicability or target element, > whereas a policy does; and a rule has an explicit grant/deny indicator, > whereas a policy does not. sounds ok > But in yesterday's call, Simon said that in his mind a rule does have an > applicability element (a R-A-S triple, which may be a simplified version of > the predicates contained in the rule). i think the problem is that the *semantics* of the applicability element has never been clear. > mentioned above, Pierangela questioned whether there is any need for a > policy to have a combination of rules (i.e., either it is just a combination > of predicates, or it is implicitly understood that they are combined in an > OR). My problem is that I can understand what a boolean combination of policy can be. [Note: Probably mainly for AND and OR; NOT could have use as a way to specify negation in case explicit denies are not supported (but then the fact that a rule expresses a negation would not be attached to the rule, so explicit deny would be better rather than or).] However: - what it means to have a combination or *rules* is not clear to me. Rules should express permissions/denials, if i understand it well they are a more expressive and fancy form of current authorizations. - we have policies and can have combination of policies. Why would we need combinations again within a policy? Btw, in my understanding boolean combination of policies was intended to be combination of POLICY OUTCOMES, not of rules. > Finally, Simon suggested that the smallest individual unit specified > by XACML should be a policy. no, if i recall correctly Simon said the smallest ``exportable unit'' which would mean the smallest unit which you can refer to in a boolean expression. This sounds good to me. > So now I really don't understand the difference between "policy" and "rule". > How are they different? Do we need to distinguish between them? Do we need > separate syntax for them? Why not forget about rules altogether and say > that, for XACML, a logical combination of predicates, with a (possibly > simplified) applicability or target element, and with an explicit grant/deny > indicator, *is* a policy. No mention of rules whatsoever (except possibly > in the "Related Terms" section that follows the glossary). Personally i think it would be cleaner to have rules. I had always assumed a policy is a set of rules, combination operates on policy. This seems cleaner to me and just as expressive as the case where policies are boolean expressions (whose semantics instead is not completely clear to me). > Note 1) I think we still need to retain the concept of a higher-level > policy (e.g., a base policy) that specifies a logical combination of > sub-policy results. The sub-policies may be included or referenced. that is not in contrast, and seems to be in the direction, with the proposal of having policies as a set of rules and boolean expression on policies. > Note 2) I think it would be useful to include the concept of a > meta-policy that specifies a logical combination of predicates about > policy (e.g., grant/deny, or issuer, or issue date, or whatever). I > don't know how else to be able to say general things like "policies > from this authority always override policies from that authority", > or "denies always override grants", or "policies issued in the past > month always override older policies". meta-policies could be fine. it is not clear to me at what level they operate. if you support grant and deny a meta-policy could be associated with a policy, regulating how the policy should evaluate the rule in it to produce an outcome decision (which could be evaluated in a boolean expression of policy). A metapolicy could also be associated with policies which are boolean expression of policies, i guess. The metapolicy example in the mystery model proposal was confusing to me as it was referring to precedence between grants and deny and one wonders whether this could subverrt possible precedence criteria that were intended *within* a specific policy. -p