[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Proposal on item 7 ConditionReference
On Wed, 3 Dec 2003, Daniel Engovatov wrote: > >I think I know where you are going with this, but I don't think the LET > >statement will do that for you. What we want is to simply reference > values > >amongst different rules. > > Within single policy, or across all policies? Probably I missed > something.. With in a single policy. I think we predicated the apporach based on that. > I am not suggesting that the proposed idea would not work - just the > longer I look at our architecture, the more I feel that more cross > policy information needs to be provided. Let expressions being one of > them, instead of condition references. I understand. -Polar > > Daniel; > > > For example a place to define five-minutes-from-now attribute of > > datetime type defined as (add-time current-time 5 minutes) and so on. > > > > > > Daniel; > > > > -----Original Message----- > > From: Polar Humenn [mailto:polar@syr.edu] > > Sent: Wednesday, December 03, 2003 5:02 PM > > To: Michiharu Kudoh > > Cc: XACML TC > > Subject: Re: [xacml] Proposal on item 7 ConditionReference > > > > > > Michiharu-san, > > > > Thanks for your proposal on condition reference. However, it looks > like > > you've added something else, called your "ApplyIdRef", which performs > > the > > same function except for arbitrary typed values, where as the > condition > > references logical values. > > > > I think these two things can really be consolidated. > > > > What we are really doing is specifying value that can be referenced in > > other expressions, so safe on space, and also perhaps, to save > > evaluation > > time, if that value is to be used more than once within the same > policy. > > > > This approach is just like giving a variable a value in any other > > programming language. As Gerald Brose said to me in Milan, "What they > > want > > is a 'let' statement", to which I concurred. > > > > So, now if we are going to go that way, lets do it in general. > > > > I would suggest using the words > > > > <VariableDef VarId="x"> > > .... -- This doesn't have to be ApplyType, but just a > > value. > > </VariableDef> > > > > <VariableRef VarId="x> > > > > The type of a VariableDef will be deduced by the value or expression > it > > contains, and the type of the corresponding VariableRef will coincide. > > > > A condition is merely a value of type xs:boolean, and a condition > > reference, just to be consistent with the syntax we have, will > reference > > a > > variable. > > > > <ConditionRef VarId="y"> > > > > And the restriction is that the variable defined for "y" must be > > xs:boolean. > > > > How does that approach sound? > > > > Cheers, > > -Polar > > > > > > On Thu, 20 Nov 2003, Michiharu Kudoh wrote: > > > > > > > > > > > > > > > > > >7. ConditionReference > > > > > > > > General proposal now accepted. Waiting for the specific > > > > line-by-line specification changes. > > > > > > The following is a proposal on Item 7: ConditionReference > > > > > > Regarding the motivating examples, please refer to the original > draft > > > proposal: > > > http://lists.oasis-open.org/archives/xacml/200304/msg00039.html > > > > > > 1. Overview > > > > > > This proposal extends XACML 1.1 to support more succinct condition > > > specification. The extension allows policy writers to define a set > of > > > condition expressions at a place and refer to it from inside the > > policy. > > > This condition reference does not extend beyond the policy boundary > to > > meet > > > the agreement that the minimum administration unit is a policy. The > > > extension consists of two parts: condition-level reference and > > apply-level > > > reference. > > > > > > Condition-level reference allows a Rule to contain a > > ConditionIdReference > > > element as an alternative to a Condition element. The > > ConditionReference > > > would identify a ConditionDef element specified below Policy > element. > > This > > > allows a single Condition to be re-used in Rules under different > > Targets. A > > > ConditionId attribute is added to the ConditionDef element to > support > > this. > > > > > > To support finer-grained condition reference, apply-level reference > > allows > > > a condition or apply to contain a ApplyIdReference element as an > > > alternative to an Apply element. The ApplyReference would identify a > > > ApplyDef element specified below Policy element. This allows a > single > > Apply > > > to be re-used in Conditions or Apply in Rules under different > > Conditions > > > and Targets. An ApplyId attribute is added to the ApplyDef element > to > > > support this. > > > > > > 2. Sample policy specifications > > > > > > <Policy> > > > <ConditionDef ConditionId="CheckAgeBetween20-60" > > > FunctionId="...function:and"> > > > <Apply FunctionId="...integer-greater-than-or-equal"> > > > ... age is equal or greater than 20 ... > > > <Apply FunctionId="...integer-less-than-or-equal"> > > > ... age is equal or less than 60 ... > > > </Condition> > > > <Rule Effect = "Permit"> > > > <Target>... target 1 > > > > <ConditionIdReference>CheckAgeBetween20-60</ConditionIdReference> > > > </Rule> > > > <Rule Effect = "Permit"> > > > <Target> ... target 2 > > > > <ConditionIdReference>CheckAgeBetween20-60</ConditionIdReference> > > > </Rule> > > > </Policy> > > > > > > > > > 3. Specification modifications > > > (based on the XACML 1.1 pdf doc as of Aug 7, 2003) > > > > > > + Line 2083, Section 5.20, insert > > > <xs:element ref="xacml:ConditionDef" minOccurs="0"/> > > > <xs:element ref="xacml:ApplyDef" minOccurs="0"/> > > > > > > + Line 2105, Section 5.20, insert > > > <ConditionDef> [Optional] > > > Defines a set of condition expressions referred from the rules in > the > > > enclosing policy. > > > > > > <ApplyDef> [Optional] > > > Defines a set of apply expressions referred from the rules in the > > enclosing > > > policy. > > > > > > + Line 2135, new Section 5.22 and 5.23, insert > > > 5.22. Element <ConditionDef> > > > The <ConditionDef> element SHALL specify a set of condition > > expressions > > > referred from the rules in the enclosing policy. > > > > > > <xs:element name="ConditionDef" type="xacml:ConditionDefType"/> > > > <xs:complexType name="xacml:ConditionDefType"> > > > <xs:complexContent> > > > <xs:extension base="xacml:ApplyType"> > > > <xs:attribute name="ConditionId" type="xs:anyURI" > use="required" > > /> > > > </xs:extension> > > > </xs:complexContent> > > > </xs:complexType> > > > > > > 5.23. Element <ApplyDef> > > > The <ApplyDef> element SHALL specify a set of apply expressions > > referred > > > from the rules in the enclosing policy. > > > > > > <xs:element name="ApplyDef" type="xacml:ApplyDefType"/> > > > <xs:complexType name="xacml:ApplyDefType"> > > > <xs:complexContent> > > > <xs:extension base="xacml:ApplyType"> > > > <xs:attribute name="ApplyId" type="xs:anyURI" use="required" > /> > > > </xs:extension> > > > </xs:complexContent> > > > </xs:complexType> > > > > > > + Line 2143, old Section 5.22, insert > > > <xs:element ref="xacml:ConditionIdReference" minOccurs="0"/> > > > > > > + Line 2165, Section 5.22, insert > > > <ConditionIdReference> [Optional] > > > The <xacml:ConditionIdReference> element SHALL be used to reference > a > > > <ConditionDef> element by id. If <ConditionIdReference> is a URL, > then > > it > > > MAY be resolvable to the <Condition>. The mechanism for resolving a > > > condition reference to the corresponding condition is outside the > > scope of > > > this specification. > > > <xs:element name="ConditionIdReference" type="xs:anyURI"/> > > > Element <ConditionIdReference> is of xs:anyURI simple type. > > > > > > + Line 2182, Section 5.25, modify the line > > > call. The <Apply> element can be applied to any combination of > > <Apply>, > > > <ApplyIdReference>, > > > > > > + Line 2190, Section 5.25, insert > > > <xs:element ref="xacml:ApplyIdReference"/> > > > > > > + Line 2208, Section 5.25, insert > > > <ApplyIdReference> [Optional] > > > A function call reference. > > > > > > > > > 4. Schema modifications > > > The following lists schema fragments affected by this proposal. > > > > > > <xs:complexType name="PolicyType"> > > > <xs:sequence> > > > <xs:element ref="xacml:Description" minOccurs="0"/> > > > <xs:element ref="xacml:PolicyDefaults" minOccurs="0"/> > > > <xs:element ref="xacml:ConditionDef" minOccurs="0"/> > > > <xs:element ref="xacml:ApplyDef" minOccurs="0"/> > > > <xs:element ref="xacml:Target"/> > > > <xs:element ref="xacml:Rule" minOccurs="0" > > > maxOccurs="unbounded"/> > > > <xs:element ref="xacml:Obligations" minOccurs="0"/> > > > </xs:sequence> > > > <xs:attribute name="PolicyId" type="xs:anyURI" > use="required"/> > > > <xs:attribute name="RuleCombiningAlgId" type="xs:anyURI" > > > use="required"/> > > > </xs:complexType> > > > > > > <xs:element name="ConditionDef" type="xacml:ConditionDefType"/> > > > <xs:complexType name="xacml:ConditionDefType"> > > > <xs:complexContent> > > > <xs:extension base="xacml:ApplyType"> > > > <xs:attribute name="ConditionId" type="xs:anyURI" > use="required" > > /> > > > </xs:extension> > > > </xs:complexContent> > > > </xs:complexType> > > > > > > <xs:element name="ApplyDef" type="xacml:ApplyDefType"/> > > > <xs:complexType name="xacml:ApplyDefType"> > > > <xs:complexContent> > > > <xs:extension base="xacml:ApplyType"> > > > <xs:attribute name="ApplyId" type="xs:anyURI" use="required" > /> > > > </xs:extension> > > > </xs:complexContent> > > > </xs:complexType> > > > > > > <xs:complexType name="RuleType"> > > > <xs:sequence> > > > <xs:element ref="xacml:Description" minOccurs="0"/> > > > <xs:element ref="xacml:Target" minOccurs="0"/> > > > <xs:element ref="xacml:Condition" minOccurs="0"/> > > > <xs:element ref="xacml:ConditionIdReference" > > minOccurs="0"/> > > > </xs:sequence> > > > <xs:attribute name="RuleId" type="xs:anyURI" use="required"/> > > > <xs:attribute name="Effect" type="xacml:EffectType" > > use="required"/> > > > </xs:complexType> > > > > > > <xs:complexType name="ApplyType"> > > > <xs:choice minOccurs="0" maxOccurs="unbounded"> > > > <xs:element ref="xacml:Apply"/> > > > <xs:element ref="xacml:ApplyIdReference"/> > > > <xs:element ref="xacml:Function"/> > > > <xs:element ref="xacml:AttributeValue"/> > > > <xs:element ref="xacml:SubjectAttributeDesignator"/> > > > <xs:element ref="xacml:ResourceAttributeDesignator"/> > > > <xs:element ref="xacml:ActionAttributeDesignator"/> > > > <xs:element ref="xacml:EnvironmentAttributeDesignator"/> > > > <xs:element ref="xacml:AttributeSelector"/> > > > </xs:choice> > > > <xs:attribute name="FunctionId" type="xs:anyURI" > > use="required"/> > > > <!-- Legal types for the first and subsequent operands are > > defined in > > > the accompanying table --> > > > </xs:complexType> > > > > > > Best, > > > Michiharu > > > > > > > > > To unsubscribe from this mailing list (and be removed from the > roster > > of the OASIS TC), go to > > > http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgro > > up.php. > > > > > > > To unsubscribe from this mailing list (and be removed from the roster > of > > the OASIS TC), go to > > > http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgro > > up.php. > > > > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]