[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Proposal on item 7 ConditionReference
OK. Could you briefly summarize pros and cons of both ways, please?
Just for people who wants to understand the difference between two
approaches.
I will post the two proposals (only boolean val ref or any val ref) with
the
comparison you will make. Actually I can live with both.
Michiharu
Polar Humenn
<polar@syr.edu> To: Michiharu Kudoh/Japan/IBM@IBMJP
cc: XACML TC <xacml@lists.oasis-open.org>
2003/12/10 00:02 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_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
> .
>
>
>
>
> 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]