OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only

Re: [xacml] Proposal on item 7 ConditionReference

  • 1.  Re: [xacml] Proposal on item 7 ConditionReference

    Posted 12-08-2003 17:03
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    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]