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