[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Backgrounds of properties for new combining algorithm
> 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]