OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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]