[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Proposal on item 7 ConditionReference
On Tue, 9 Dec 2003, Michiharu Kudoh wrote: > > > > > 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? Yes. It would be any valid expression. -Polar > > 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]