OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml] Summary of issues: WI#10. Parameters for Combining Algorithms






Hi, Polar

I am ok with the combiner elements you suggested.
To make things clearer, I made two policy examples:

1) Combiner parameters for <Policy>

<Policy PolicyId="P1" algid="priority-rule-combo-algo">
   <CombinerParameters>
     <CombinerParameter ParameterName="creater">
       <AttributeValue DataType="string">Alice</AttributeValue>
     </CombinerParameter>
   </CombinerParameters>
   <RuleCombinerParameters RuleIdRef="R1">
     <CombinerParameter ParameterName="priority">
       <AttributeValue DataType="integer">1</AttributeValue>
     </CombinerParameter>
     <CombinerParameter ParameterName="preference">
       <AttributeValue DataType="integer">2</AttributeValue>
     </CombinerParameter>
   </CombinerParameters>
   <RuleCombinerParameters RuleIdRef="R2">
     <CombinerParameter ParameterName="priority">
       <AttributeValue DataType="integer">3</AttributeValue>
     </CombinerParameter>
   </CombinerParameters>
   <RuleCombinerParameters RuleIdRef="R2">
     <CombinerParameter ParameterName="preference">
       <AttributeValue DataType="integer">1</AttributeValue>
     </CombinerParameter>
   </CombinerParameters>
   <Rule RuleId="R1">
      ...
   </Rule>
   <Rule RuleId="R2">
      ...
   </Rule>
</Policy>

<CombinerParameters> indicates the parameter for the rule combining
algorithm.
The first <RuleCombinerParameters> indicates two parameters for Rule "R1".
The second <RuleCombinerParameters> indicates the priority parameter for
Rule "R2".
The third <RuleCombinerParameters> indicates the preference parameter for
Rule "R2".
Since the second and the third <RuleCombinerParameters> have the same
RuleIdRef,
their combiner parameters are concatenated in the order they appear.
I changed the attribute name from RuleId to RuleIdRef because it is a
reference to
rule id.

In this case, there is no need to add new element/attribute other than
*-Parameter(s).

2) Combiner parameters for <PolicySet>

<PolicySet PolicySetId="PS" algid="priority-policy-combo-algo">
   <CombinerParameters>
     <CombinerParameter ParameterName="creater">
       <AttributeValue DataType="string">Alice</AttributeValue>
     </CombinerParameter>
   </CombinerParameters>
   <PolicyCombinerParameters PolicyIdRef="P1">
     <CombinerParameter ParameterName="priority">
       <AttributeValue DataType="integer">1</AttributeValue>
     </CombinerParameter>
   </CombinerParameters>
   <PolicySetCombinerParameters PolicySetIdRef="PS1">
     <CombinerParameter ParameterName="priority">
       <AttributeValue DataType="integer">2</AttributeValue>
     </CombinerParameter>
   </CombinerParameters>
   <PolicyIdReference PolicyId="P1">urn:policy1
   </PolicyIdReference>
   <PolicySetIdReference PolicySetId="PS1">unn:policySet1
   </PolicySetIdReference>
</Policy>

<CombinerParameters> indicates the parameter for policy combining
algorithm.
<PolicyCombinerParameters> indicates the parameter for policyIdReference
"P1".
<PolicySetCombinerParameters> indicates the parameter for
policySetIdReference "PS1".
In this case, we need to add PolicyId and PolicySetId attributes to
<PolicyIdReference> and
<PolicySetIdReference>, respectively.

Best,
Michiharu



                                                                           
             Polar Humenn                                                  
             <polar@syr.edu>                                               
                                                                        To 
             2004/04/02 22:25          Michiharu Kudoh/Japan/IBM@IBMJP     
                                                                        cc 
                                       Anne Anderson                       
                                       <Anne.Anderson@Sun.COM>, Seth       
                                       Proctor <Seth.Proctor@Sun.COM>,     
                                       XACML TC                            
                                       <xacml@lists.oasis-open.org>        
                                                                   Subject 
                                       Re: [xacml] Summary of issues:      
                                       WI#10. Parameters for Combining     
                                       Algorithms                          
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





Michiharu,

After thinking about it more thoroughly, I'm getting more confortable with
*explicitly* associating CombinerParameters with rules/policies.

I had thought, that an implemenation would have to offer the combining
algorthim the entire rule/policy, instead of just its evaluated decision.
It turns out that that implemenation would have to offer the evaluated
decision with its specific Id.

However, that somewhat complicates matters as we would have to have four
kinds of CombinerParameters elements.

<CombinerParameters>
           For parameters associated with the combining algorithm itself.
<RuleCombinerParameters  RuleId="...">
           To associate with rules, only allowed inside a <Policy>.

<PolicyCombinerParameters PolicyId=".....">
<PolicySetCombinerParameters PolicySetId="...">

           To associate with Policy/Ref, and PolicySet/Ref, only allowe
           in <PolicySet>.


Then for each we would have to make the argument that their can be *only*
one per combining algorithm,rules,policy/ref,policyset/ref, respectively,
or that the combination of any two with the same id, is equivalent to a
single <CombiningParameters> element including the concatention of the
contents of all <CombiningParameters> elements with the same id,
preserving the orginial order.

This would involve changing the schema, however, the benefits are that the
a lot of the work can be taken care of by the
  1. Syntax Verification
      Knowing that the RuleCombinerParameters will only be referencing
      a rule within the same policy, and
  2. Type checking,
      that the referenced rule should/must exist within the policy.
      that the referenced policy/set/ref must exist within the policyset.


What say you all?

Cheers,
-Polar




On Fri, 2 Apr 2004, Michiharu Kudoh wrote:

> Polar
>
> Regarding the issue summarized by Anne, I would prefer c). I can
understand
> the Seth's opinion but am not clear on the reason you wrote.
>
> >Actually, having a CombiningParameters element reference a rule leads to
> >ordering inconsitencies and restrictions in the combining algorithms.
>
> What do you mean by ordering inconsistencies and restrictions in the
> combining algorithms?
> In my opinion, combiner parameter does not affect the already
standardized
> algorithms because they don't need those parameters. It only affects some
> custom algorithms that needs combiner parameters. Such custom algorithms
> must be aware how to assign a parameter to a rule/policy. I think that
the
> implicit sequence-based assignment scheme (you are proposing) has no
> difference from the explicit reference-based assignment scheme in terms
of
> implementation aspect.


>
> Or what you are concerned is the formal semantics of the combining
> algorithm?
>
> Best,
> Michiharu
>
>
>
>
>              Polar Humenn
>              <polar@syr.edu>
>
To
>              2004/04/02 07:39          Seth Proctor
<Seth.Proctor@Sun.COM>
>
cc
>                                        Anne Anderson
>                                        <Anne.Anderson@Sun.COM>, XACML TC
>                                        <xacml@lists.oasis-open.org>
>
Subject
>                                        Re: [xacml] Summary of issues:
>                                        WI#10. Parameters for Combining
>                                        Algorithms
>
>
>
>
>
>
>
>
>
>
> On Thu, 1 Apr 2004, Seth Proctor wrote:
>
> > On Thu, 2004-04-01 at 11:51, Anne Anderson wrote:
> > > This is my understanding of where we are on WI#10 (combining
> > > algorithm parameters).  Could people clarify if I have gotten any
> > > of this wrong or if I have left something out?
> >
> > Thanks for this summary! I have a couple comments/questions about this
> > proposal (not about the summary you've written)...
> >
> > >    APPROVED:
> > >    a) Schema will be as specified in
> > >       http://lists.oasis-open.org/archives/xacml/200403/msg00125.html
> > >       except that <AttributeValue> will be replaced with
> > >       <Expression> (per WI#7), which could be a <ConditionReference>.
> >
> > Do we really want expressions instead of simple values being passed as
> > parameters?
>
> Yes.
>
> > Do we have use cases where this extra complexity is needed?
>
> It's really no extra complexity.
>
> > I thought that one of the things we wanted to guarentee is that nothing
> > outside the policy can effect the parameters to an algorithm.
>
> Nothing will. The parameters are inside the policy, and effectively used
> within the policy's combining algorithm, just as the result of the rules
> are.
>
> > Using an expression defeats this (ie, if I use a designator, I'll never
> > know just by looking at the policy what parameters are being supplied).
> > Could someone provide a clear example that shows why we _need_
> > expressions instead of concrete values?
>
> Aside from you get it for free, so why not use it. You may want to
> reference a value you've defined else where.
>
> > >   b) <CombinerParameter> <AttributeValue>/<Expression> elements
> > >       will have a DataType so the PDP can completely evaluate the
> > >       value before passing it to the CombiningAlgorithm.
> > >    b) <CombinerParameters> are children of the <Policy>, not of
> > >       the <Rule>; i.e. they are specified outside the <Rule>
> > >       elements to which they apply.
> >
> > What about policy combining algorithms? Do we need the same kind of
> > CombinerParameters element in PolicySet to define parameters for
> > policies?
>
> Yes. Whether its a policy or rule combining it's basically the same
> mechanism (except policy combining algorthims have these pesky
obligations
> to deal with (more on that later).
>
> > >    ISSUE:
> > >
> > >    How are <CombinerParameters> elements and the
> > >    <CombinerParameter> elements within them associated with
> > >    particular <Rule> elements?  Options:
> > >
> > >    a) Left completely up to the CombiningAlgorithm.
> > >
> > >       Polar's preference.
> > >
> > >    b) Specified order: all <CombinerParameter> elements in the
> > >       1st <CombinerParameters> element are associated with the
> > >       1st <Rule>, the 2nd <CombinerParameters> are associated
> > >       with the 2nd <Rule>, etc.
> > >
> > >    c) Specified in <CombinerParameters> metadata.  E.g.
> > >       <CombinerParameters ParameterRef="Rule5">
> > >          <CombinerParameter ParameterName="p1".../>
> > >          <CombinerParameter ParameterName="p2".../>
> > >       </CombinerParameters>
> > >       <CombinerParameters ParameterRef="Rule2">
> > >          <CombinerParameter ParameterName="p1".../>
> > >          <CombinerParameter ParameterName="p2".../>
> > >       </CombinerParameters>
> >
> > For what it's worth, I think that item c is the best choice, for a few
> > reasons. For one, we want to be explicit with the parameters how
they're
> > used, so we can't just leave it up to the algorithm to pick an
ordering.
> > For another, specifying all in order in one place (the
> > CombinerParameters) and then hoping that the rules stay in the same
> > order is a recipe for disaster (since you might change the rule
ordering
> > and forget about the parameters)...trust me, this will lead to a lot of
> > problems :) Finally, this will require the same number of parameters as
> > rules, which is a problem if one of the rules doesn't need parameters.
> > All of these problems are solved by the simple mapping from
> > CombinerParameters to Rules via RuleId.
> >
> > In today's TC meeting, Polar raised the issue of having to know RuleIds
> > in the combining algorithm. I agree this is something important to
> > consider, and it shouldn't be a requirement, but this is an
> > implementation detail. At the end of the day, all I want is the result
> > of evaluating a rule being provided along with the parameters for that
> > result, and mapping using RuleId doesn't prevent this at all.
>
> Actually, having a CombiningParameters element reference a rule leads to
> ordering inconsitencies and restrictions in the combining algorithms.
>
> > Actually, technically speaking, I'd like the parameters before I do the
> > rule evaluation, since my alg may decide which Rule to evaluate based
on
> > parameters, but that is also an implementation detail :)
>
> So be it.
>
> Cheers,
> -Polar
>
>
> >
> > seth
> >
> >
> > 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]