MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [xacml] item 11 (xacml extension points) mods
Hi Polar,
I agree with you. In fact, what I meant by @must-understand was that pdp is
aware of combining algorithm.
So if @must-understand is an overload we do not need it.
Simon
----- Original Message -----
From: "Polar Humenn" <polar@syr.edu>
To: "Simon Godik" <simon.godik@overxeer.com>
Cc: "XACML" <xacml@lists.oasis-open.org>
Sent: Monday, February 02, 2004 7:26 AM
Subject: Re: [xacml] item 11 (xacml extension points) mods
>
> Simon, (again, please forward to list).
>
> I really object to a PDP having to know what subjective attributes such as
> "MustUnderstand" are.
>
> I thought that the <Parameters> elements are merely arguments to the
> encompassing combining algorithm.
>
> You can still associate parameters with each contained PolicySet, Policy,
> or Rule, but that is defined by the particular combining algorithm to
> which you are supplying the parameters.
>
> For example, if you have 3 rules and you want parameters supplying each
> rule's priority. You select the "priority-rule-combining-algorithm", and
> it specifies that each <Parameters> element contains one integer
> <Parameter> element with a value between 1 and 10. The combining algorithm
> associates each <Parameters><Parameter> one-for-one-in-order with the
> occurance of the rules, and evaluate accordingly.
>
> Alternatively, you may have "priority-rule-combo-alg2" that takes a single
> <Parameters> element that contains 3 integer <Parameter> elements each
> with a value of -100 to 100, of which each <Parameter> is associated with
> a the rule in sequence.
>
> This approach yields a lot of flexibility, and puts the task of
> "MustUnderstand" to the definition of the combining algorithm and not the
> PDP in general.
>
> Depending on the implmenentation, the combination algorithm may have to
> dynamically take care of cases that are mis-typed, or mis-matched.
> However, tt still does leave the possiblity that the PDP "compiler" may
> know of the combining algorithm and be able to type check its
> constinuent structure.
>
> Cheers,
> -Polar
>
>
> On Mon, 2 Feb 2004, Simon Godik wrote:
>
> > After focus call mods to the xacml extension points proposal. (Item 11).
> >
> > Proposal:
>
> > Allow element of type <xacml:ParametrsType> as an optional child of
> > <xacml:PolicySet> and <xacml:Policy> elements. <xacml:Parameters>
> > element contains a list of parameters specific to the combining
> > algorithm of <xacml:Parameters> element parent. If MustUnderstand
> > attribute of <xacml:Parameters> element is set to "true", PDP must be
> > able to process all enclosed <xacml:Parameter> elements. If
> > MustUnderstand is 'true', a list of parameters must include at least one
> > parameter. If MustUnderstand attribute is set to "false", PDP may ignore
> > a list of combiner-specific parameters.
>
> >
> > Parameter names and values are interpreted by the combining algorithm.
> >
> > Schema:
> > <xs:element name="Parameters" type="xacml:ParametersType"/>
> > <xs:complexType name="ParametersType">
> > <xs:sequence>
> > <xs:element ref="xacml:Parameter" minOccurs="0" maxOccurs="unbounded"/>
> > </xs:sequence>
> > <xs:attribute name="MustUnderstand" type="xs:boolean" use="required"/>
> > </xs:complexType>
> > <!-- -->
> > <xs:element name="Parameter" type="xacml:ParameterType"/>
> > <xs:complexType name="ParameterType">
> > <xs:sequence>
> > <xs:any namespace="##any" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
> > </xs:sequence>
> > <xs:attribute name="ParameterName" type="string" use="required"/>
> > </xs:complexType>
> >
> >
> > Simon
> >
> >
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]