[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 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. seth
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]