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

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 current
> 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 was
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 to
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 it's
worth trying to standardize it, since that promotes interoperability. In the
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 simply
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 a
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]