[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Proposal on item 7 ConditionReference
Why only within a single policy? Is not our type and data structure shared between policies? PIP may, and should not be aware of multiple policies as far as I understand. Why could not attribute type declarations and expressions be shared? Is there any fundamental objection to that, besides the fact that we do not have a place to share it - a context schema and document - for now? Daniel -----Original Message----- From: Polar Humenn [mailto:polar@syr.edu] Sent: Tuesday, December 09, 2003 7:03 AM To: Michiharu Kudoh Cc: XACML TC Subject: Re: [xacml] Proposal on item 7 ConditionReference I think, any one who has implemented a referenced value for boolean expressions can easily use the same reference machinery to handle arbitary values. The fact that you want references to "Apply" constructs seys that kind of functionality would be needed. As far as I'm concerned, having a declarative values and references to them fit within the formal type system of XACML, and it fits within the declarative reduction semantics, and yields referencial transparency. All the good traits of a formally declarative language. In other words, I'm for a variable/general value defintion and its references across rule expressions within a single Policy, and only within a single policy. Cheers, -Polar On Tue, 9 Dec 2003, Michiharu Kudoh wrote: > I think both ApplyDef and VariableDef can define any valid expressions. So > there is no difference. Only difference is that ApplyDef always needs a > function name (actually a function ref) while VariableDef does not. So > VariableDef can directly define variable corresponding to > *AttributeDesignator, AttributeSelector, and AttributeValue, but ApplyDef > cannot. > > Apart from generality, when AttributeSelector or AttributeValue has complex > value, it might be useful to define it once by VariableDef and refer it > from inside the policy. On the contrary, it might be the case that XACML > does not provide such finer-grained ref function but just provide a way to > reuse only Boolean expression for simplicity (my revised proposal that use > only ConditionRef), e.g. complex value of AttributeValue can be specified > in a part of Boolean expression. What is your thought? > > Michiharu > > > > Polar Humenn > <polar@syr.edu> To: Michiharu Kudoh/Japan/IBM@IBMJP > cc: XACML TC <xacml@lists.oasis-open.org> > 2003/12/09 02:07 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_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_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_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_workgro up.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]