MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Fw: [xacml] syntax for variables and variable references
Forwarded message from Polar.
----- Original Message -----
From: "Polar Humenn" <polar@syr.edu>
To: "Simon Godik" <simon.godik@overxeer.com>
Cc: "Tim Moses" <tim.moses@entrust.com>; <xacml@lists.oasis-open.org>
Sent: Monday, February 02, 2004 7:05 AM
Subject: Re: [xacml] syntax for variables and variable references
>
> Simon, (My mail is getting bounced by the list, so please forward.
> Thanks)
>
> I'm not sure about the variable in targets approach. Targets have simple
> matches to bring about indexing. Variables represent general expressions.
> Putting general expressions into Targets will force the targets to be
> evaluated like the condition, and hence there will be no difference.
>
> On the rackling around of the types. I don't mind getting rid of the
> Condition element.
>
> Simon, is there xomething in XML that prevents us from arranging the type
> structure in a more convential way that usually represents most languages
> have their abstract syntax?
>
> Something like:
>
> Expression ::= AttributeValue
> | AttributeDesignator
> | Function
> | Apply
> | VariableRef
>
> That would mean that we create a base complex type of <ExpressionType>
> which is simply extended by <AttributeValueType>,
> <AttributeDesignatorType>, <FunctionType>, <ApplyType>, <VariableRefType>.
> Then the <ApplyType> simply contains a sequence of elements of
> <ExpressionType>. And therefore a VariableDef just associates a VariableId
> with something of <ExpressionType>.
>
> A Condition is then merely just something of an ExpressionType (which has
> to type check to a singleton boolean value).
>
> Just wondering.
>
> Cheers,
> -Polar
>
> On Mon, 2 Feb 2004, Simon Godik wrote:
>
> > Hi Tim,
> >
> > Schemas are mods of v2-1 schema from the proposal
> > http://lists.oasis-open.org/archives/xacml/200401/msg00035.html by
> > Michiharu (work iterm 7)
> >
> > Syntax for variables and variable references.
> >
> > Current variable syntax definition needs adjustment to account for the
> > <condition> element.
> >
> > I think we should allow variables in target matches as well.
> > (not yet included).
> > Two possible alternatives for variable syntax.
> >
> > Alt a: <-- my preference
> > ------
> > Drop <condition> element and replace it with the <apply> element.
> > This makes it easy to create variable def and ref. Note that <condition>
> > and <apply> are of the same type, so change is 'harmless'.
> >
> > The advantage of this approach is simplicity. There is one element for
> > variable definition and one element for variable reference.
> >
> > ex 1a: rule with top-level <apply>:
> > <rule>
> > <target>...</target>
> > <apply funcid="string-equal">...</apply>
> > </rule>
> >
> > ex 2a: variable def is used in top-level apply:
> > <var-def varid="cond1">
> > <apply funcid="string-equal">...</apply>
> > </var-def>
> >
> > <rule>
> > <target>...</target>
> > <var-ref varid="cond1"/>
> > </rule>
> >
> > For the rule to be valid, <var-ref> must resolve into <apply> element.
> > (which it does). Note that the same variable definition can be reused in
> > top level <apply> and enclosed <apply> elements.
> >
> > Alt b:
> > -------
> > Keep <condition> element. In addition to existing <variable-def> and
> > <variable-ref> elements create <cond-var-def> and <cond-var-ref>
elements.
> > Then <cond-var-ref> is allowed as an alternative to <condition> in a
rule.
> >
> > In addition to having more syntactic elements, disadvantage of this
approach
> > is that <cond-var-def> can not be reused for <variable-def>.
> >
> > ex 1b: The same as 2a but variable is defined for condition:
> >
> > <cond-def varid="cond1">
> > <cond funcid="string-equal">...</cond>
> > </var-def>
> >
> > <rule>
> > <target>...</target>
> > <cond-ref varid="cond1"/>
> > </rule>
> >
> > Syntactic detail.
> > -----------------
> > Variable is defined with the <VariableDef> element. Type of the variable
> > defined by <VariableDef> is determined by the type of enclosed
expression.
> > Name of the variable defined by <VariableDef> is the value of VariableId
> > attribute of type xs:string.
> >
> > (By derivation from the apply-core-type) Variable definition can be
applied to
> > any combination of <apply>, <function>, <attr-value>, <subj-attr-desig>,
> > <res-attr-desig>, <act-attr-desig>, <env-attr-desig>, <attr-sel>,
> > and <var-ref> elements.
> >
> > <xs:element name="VariableDef" type="xacml:VariableDefType"/>
> > <xs:complexType name="VariableDefType">
> > <xs:complexContent>
> > <xs:extension base="xacml:ApplyCoreType">
> > <xs:attribute name="VariableId" type="xs:string" use="required"/>
> > </xs:extension>
> > </xs:complexContent>
> > </xs:complexType>
> >
> > VariableId - required. This is variable name.
> >
> > Variable is dereferenced with the <VariableRef> element. Variable name
> > is defined by the value of VariableId attribute of type xs:string.
> >
> > <xs:element name="VariableRef" type="xacml:VariableRefType"/>
> > <xs:complexType name="VariableRefType">
> > <xs:attribute name="VariableId" type="xs:string"/>
> > </xs:complexType>
> >
> > VariableId - required. This is variable name. Must resolve to named
variable
> > definition.
> >
> > Alternative (a):
> > ------------------------
> > Rule schema:
> > <xs:complexType name="RuleType">
> > <xs:sequence>
> > <xs:element ref="xacml:Description" minOccurs="0"/>
> > <xs:element ref="xacml:Target" minOccurs="0"/>
> > <xs:choice>
> > <xs:element ref="xacml:Apply"/> <-- change: <cond> replaced with <apply>
> > <xs:element ref="xacml:VariableRef"/> <-- new: variable ref
> > </xs:choice>
> > </xs:sequence>
> > <xs:attribute name="RuleId" type="xs:anyURI" use="required"/>
> > <xs:attribute name="Effect" type="xacml:EffectType" use="required"/>
> > </xs:complexType>
> >
> > For the rule to be valid, <VariableRef> must resolve into <apply>
element.
> >
> > Sequence of <VariableDef> elements is included as a child of <Policy>
> > element following <PolicyDefaults> element.
> >
> > Alternative (b).
> > ------------------------------
> > Rule schema:
> > <xs:complexType name="RuleType">
> > <xs:sequence>
> > <xs:element ref="xacml:Description" minOccurs="0"/>
> > <xs:element ref="xacml:Target" minOccurs="0"/>
> > <xs:choice>
> > <xs:element ref="xacml:Condition"/>
> > <xs:element ref="xacml:CondVarRef"/> <-- new: condition var reference
> > </xs:choice>
> > </xs:sequence>
> > <xs:attribute name="RuleId" type="xs:anyURI" use="required"/>
> > <xs:attribute name="Effect" type="xacml:EffectType" use="required"/>
> > </xs:complexType>
> >
> > <CondVarDef> defines condition variable. Condition variable can be used
> > only for conditions.
> >
> > <xs:element name="CondVarDef" type="xacml:CondVarDefType"/>
> > <xs:complexType name="CondVarDefType">
> > <xs:sequence>
> > <xs:element ref="xacml:Condition"/>
> > </xs:sequence>
> > <xs:attribute name="VariableId" type="xs:string" use="required"/>
> > </xs:complexType>
> >
> > VariableId is a name of condition variable.
> >
> > Condition variable reference is of <VariableRefType>:
> > <xs:element name="CondVarRef" type="xacml:VariableRefType"/>
> >
> > Condition variable reference must resolve to named condition variable.
> >
> > Sequence of choices between <VariableDef> and <CondVarDef> elements is
> > included as a child of <Policy> element following <PolicyDefaults>
element.
> >
> > Simon
> >
> >
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]