[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: No Subject
1. Are custom data-types and functions allowed, or are you limited to the functions named in Table 1 and therefore to standard data-types? The spec is unclear on this issue. Supporting custom functions and data-types isn't hard from the XACML policy processing point of view, but it does make the combining and reduction steps significantly harder, since you need to have some way to express the Predicate Combinations from Table 1 for arbitrary new functions, and you need to also support all the min/max/etc functions being defined in this spec. Unless there is demonstrable need for custom functions, I would suggest specifying that only the given functions can be used. This could be revisited in the future as new use cases arise. 2. Are the Predicates always of the form: <Apply> <AD/AS> <AV> </Apply> or will other forms be supported? The spec suggests that the Value could be replaced with some expression (more on that later), but in order to support the Predicate Combinations you need something of the form above. I would suggest that this be explicitly defined somewhere so it's clear that other forms are not allowed (this may be done somewhere, but I couldn't find it). Those were the only issues that seemed undefined to me. These really need to get nailed down before implementations can hope to interoperate. Here are some other comments, in no particular order. a. The combining steps look very doable, though it may require some tricky code, especially if the answer to question 1 above is that arbitrary functions are allowed. b. Some of the complexity in supporting the combining steps comes from supporting many new functions. Specifically, the min, max, smallest gt, largest lt, intersection, and proper subset operations all represent new functions, and since they're all specified for each type, we're talking about 78 new functions (6 operations times 13 data-types) to support the standard types. In most cases these never need to be exposed as XACML functions (see next item), so it should be possible to write custom code to handle these in a tighter manner, but if arbitrary types are supported, these almost have be handled like regular XACML functions. c. The text right after Table 1 says that expressions may be used, but that this isn't recommended. Personally, unless there's a truly compelling reason to support sub-expressions (i.e., support forms other than those shown in question 2 above), I would avoid this. For one thing, it makes the combining step much harder. For another, it means that you can't [1] do the Predicate Reduction without the actual values you'll be using, since you won't have concrete values for x and y. Finally, it means that you need to be able to output resulting policies that name the functions from item b above, so each of these needs a name and a proper definition. I'm also not entirely sure how I do combining between two policies if one or both has arbitrarily deep expressions in them. If expressions in Predicates must be allowed by the spec, there needs to be more language explaining how to handle them and what the implications are of their use. Simply saying that you shouldn't use them is not enough. d. Compilation is possibly an app-specific operation, so I understand that it's been left unspecified. It's also, however, a complex step and I doubt that most people will understand how to use it correctly. I would want to see, therefore, some text that describes how this step is typically carried out and exactly what purpose it serves. If there is no such text then there's no reason I can see to include a section discussing it. There's not even an example of this step being used in the long example at the end of the spec. Finally, a couple small nits: line 341 should have <AttributeValue> and not <Attribute> as the thing that "x" represents in the text right after Table 1 the element being referenced should not be <AttributeValue> since AVs don't have anything except values. Perhaps this should read "in the case that another Apply rather than AttributeValue is used" or something to that effect. [1] I actually haven't convinced myself that this is true, but it looks like at the very least it will be a pain... ----------------------------------------------------------------- Tim Moses 613.270.3183
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]