[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Backgrounds of properties for new combining algorithm
I agree that the property associated with each element does not solve all the problems in the case of a custom algorithm as you pointed out. But it is also true that it really solves some cases without breaking the semantics described in the spec. Since XACML provides a powerful framework (e.g. combining algorithm), it helps vendors to implement their access control engine who are not satisfied with the standardized algorithms. They may not be able to join the TC to standardize their proprietary semantics. The advantage of this approach is that if they implement the custom algorithm, then they can reuse other wonderful language features of the current XACML spec. I also understand someone who is satisfied with (or weary of) the current specification does not want new functions. But it is not true for people who needs additional function to support their requirements in terms of the application in their mind (or real use case). So what is the decision criteria to incorporate new function in the current spec? We cannot add any new functions unless it solves all the problems? I don't think so. Most of the new work items for 1.1 is not new one but carried over to 1.1 from 0.0x era since we did not have enough time when we discussed for the standardization of 1.0. It's the same with Simon's proposal on hierarchical support. Some people have been requiring such function more than 1 year, not 1-2 week thought, and they also understand the philosophy of the XACML model. I think it is worth considering to incorporate in 1.1 spec even if it does not solve any problems what you have in your mind. Of course final decision needs vote. :-) However, what I think improtant is that such new functions should not heavily affect the current available implementations. So, what I would suggest is that, if such new function is not critical one, it should be optional as much as possible. Michiharu Kudo Seth Proctor <Seth.Proctor@Sun To: Michiharu Kudoh/Japan/IBM@IBMJP .COM> cc: XACML TC <xacml@lists.oasis-open.org> Subject: Re: [xacml] Backgrounds of properties for new combining algorithm 2003/04/25 00:31 > 1) Placeholder for some information used in another access control > policylanguage It sounds to me like you're talking about two different cases here: using XACML as an intermediary language and strictly translating from some other language to XACML. I think you're stressing the latter, but both of these issues apply. In the case of using XACML as an intermediary language (ie, a general bridge between two proprietary languages) I think that it may well be useful to have an area where you can include raw information that can't easily be expressed in XACML. Of course, this data must never be used by XACML, so the where and how of this data being included isn't as important. In the case of translating from one language to XACML (which is what you're talking about), you want to include properties because you may need to use custom combining algorithms and they in turn may need special data. Unfortunately, adding properties doesn't really solve the problem here, since what you're really talking about is a policy language that can't be cleanly mapped onto the semantics of XACML. In that case, adding properties for combining algorithms to use won't solve your problem, it might just help things out a little. For the same reason that you need to support new combining algorithms, you might also need to express conditions differently, or redefine rules, or add properties to references. If there is a sematic mis-match, just adding properties for combining algorithms won't solve the problem. Note that since you're talking about custom combining algorithms, there are already ways to add inputs if you need them (like getting attributes out of the request or setting up some algorithm-specific mechanism similar to attribute and policy retrieval). Not that I'm advocated this approach, I'm just saying that it can be done and it's not more vague than what's already in the specification. It doesn't seem to me, however, that adding propoerties will solve your problem. > 2) Placeholder for storing implementation specific information This one scares and confuses me, because now you're not just talking about inputs for combining algorithms, but all parts of a policy. You're also talking about doing out-of-order execution on a Condition, which won't always help if required attributes aren't present. In general, it's going to be hard to come up with the right order to do function evaluations (some attributes might be cached, others might suddenly become unavailable, etc.). I agree with you that this use case isn't as compelling. seth
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]