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






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_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

> .
>
>
>
>

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]