[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Proposal on item 7 ConditionReference
Polar OK. Now I understand that you just wanted to introduce more general value reference mechanism than ApplyIdRef. The difference between ApplyIdRef and VariableRef would be that *AttributeDesignator, AttributeSelector, and AttributeValue can be handled in the case of VariableRef, right? Or do I miss something? Michiharu Polar Humenn <polar@syr.edu> To: Michiharu Kudoh/Japan/IBM@IBMJP cc: XACML TC <xacml@lists.oasis-open.org> 2003/12/05 00:12 Subject: Re: [xacml] Proposal on item 7 ConditionReference On Thu, 4 Dec 2003, Michiharu Kudoh wrote: > Hi, Polar > > Thank you for your comments. I see what you mean and it might also be a > good way to reuse values according to your idea. Actually, I did not intend > that level (value-level or LET level) of flexibility. I was only concerned > with the Condition level reusability. More accurately, policy author can > define any condition (that returns T/F) and refers it from inside the > condition or apply element. It greatly reduces the duplication and also > keep the spec simpler. LET like construct might be useful in more > complicated expression cases but that is beyond my use cases... > > So now I agree that you have problems with "ApplyIdRef" in the sense that > it can return arbitrary data type (I missed it). So my opinion is: I definately don't have "problems" with it. I like the idea, and I see no problem with just making it like a LET construct for general values, whether they are used for conditions or in other expressions. I think pretty much if we do condition references correctly we get the other for basically free. -Polar > - limit to Condition level reference (or Boolean return type) > - delete schema modifications with regard to ApplyIdRef > - replace ApplyIdRefeference element with ConditionIdReference element > defined in ApplyType in my previous proposal > Does it make sense? > > Cheers, > -Michiharu > > > > > Polar Humenn > <polar@syr.edu> To: Michiharu Kudoh/Japan/IBM@IBMJP > cc: XACML TC <xacml@lists.oasis-open.org> > 2003/12/04 10:02 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_workgroup.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 > . > > > > > 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 . > 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]