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: 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:


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]