[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Comment on issue 8? "choice element" or "Policy w no Rules"
See comments below. > -----Original Message----- > From: email@example.com [mailto:firstname.lastname@example.org] On > Behalf Of email@example.com > Sent: Friday, 24 February, 2012 07:48 > To: firstname.lastname@example.org > Cc: email@example.com > Subject: RE: [xacml] Comment on issue 8? "choice element" or "Policy w > no Rules" > > Erik, > > > From: firstname.lastname@example.org [mailto:email@example.com] On > Behalf Of Erik Rissanen > Sent: Friday, February 24, 2012 10:12 AM > To: firstname.lastname@example.org > Subject: Re: [xacml] Comment on issue 8? "choice element" or "Policy w > no Rules" > > > The current table looks like this: > > > > Target Rule values Policy Value > > “Match” Don’t care Specified by the rule-combining algorithm > > “No-match” Don’t care “NotApplicable” > > “Indeterminate” See Table 7 See Table 7 > > > > The change was introduced in wd 20 in order to make sure the new > combining algorithms were always > > invoked. It would be confusing if a policy with permit-unless-deny > could return not-applicable since > > this algorithm was specifically introduced to guarantee that N/A or > Indeterminate are never returned. > > Granted, but it's more confusing to me that a Policy without any Rules > has any impact on the decision at all. [pht] I agree it is initially confusing, but once you understand that the combining algorithm controls the final result, regardless of the syntactic content (or even, in some cases, the evaluated results of the content), it is the most consistent way to specify the behavior. > > BTW, section 3.3, Policy Language Model, states that a Policy should > have 1..* Rules. Oddly, this section states that a PolicySet should > have 0..* Policies. [pht] This should be corrected if it differs from the schema. > > > Thanks, > Ray