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] Proposed XACML 1.1 Solution for Item F1:Properties for newcombining algorithms

OK, I understood. So there is no difference of views regarding the
extensibility of the algorithm.

In your prior message, you wrote that
>Since new,
>algorithm-specific code has to be added to implement a new
>combining algorithm, why not add new code at the same time to
>parse policies that contain a custom extension to define some
>sort of CombiningAlgorithmParameters element?

What do you mean by "policies that contain a custom extension to define
some sort of CombiningAlgorithmParameters element?" At what portion is this
element created? Does the policy mean XACML policy?

Michiharu Kudo

                      Seth Proctor                                                                                                                  
                      <Seth.Proctor@Sun        To:       Michiharu Kudoh/Japan/IBM@IBMJP                                                            
                      .COM>                    cc:       Anne.Anderson@Sun.COM, XACML TC <xacml@lists.oasis-open.org>                               
                                               Subject:  Re: [xacml] Proposed XACML 1.1 Solution for Item F1:Properties for      new combining      
                      2003/06/21 03:07          algorithms                                                                                          

On Thu, 2003-06-19 at 06:43, Michiharu Kudoh wrote:
> I think that the difference of views seems to be related to how new
> combining algorithms should be defined. My view is anybody should be able
> to define new algorithms (if they need). Your view seems to be opposite,
> that is nobody can define new algorithm unless it passes the TC approval
> process or people can define algorithms as far as they need no additional
> property information. However, vendors who needs to define new algorithms
> anyhow must plugs-in their specific algorithms to the existing policy
> engine. It is the "custom PDP". I think one of the advantage of the
> XACML policy model is to allow each vendor to add plug-in(s) for new
> combining algorithm to the existing engine if they think necessary.

Not at all. I am all for extension mechanisms, and indeed the open sourced
implementation that I work on supports adding new combining algorithms. It
designed this way from the start, and it makes it easy to write custom algs
and add them into the system for any policy to use. I don't consider this
represent a "custom PDP" but a PDP that is supporting custom functionality.

When there is an algorithm that will be generally useful, however, I think
worth trying to standardize it, since that promotes interoperability. In
case of the existing permit and deny overrides algs, while the spec doesn't
specify an order of evaluation, I suspect that most implementations will
go in order since there's no other compelling order for evaluation. This is
certainly what my code does. Many people I've talked with have expressed a
desire to have that order guarenteed, since it lets them write policies in
particular way and know that evaluation will always proceed in that same
ordering. So, we've proposed ordered algs, since this was an original goal
when this topic was first being discussed, since there is noted demand, and
since it doesn't require much effort to add to the spec or to support.


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