[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Proposal on item 7 ConditionReference
>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.. 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. 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. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]