[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml-comment] Attribute designators
Our vote is for Simon 1, as it is simpler and we
have already implemented this solution. I don't think the schema is broken
so it shouldn't be changed. Polar introduces a number of
changes.
This needs to be kept simple.
In the majority of cases you are only going to
require ORs and ANDs. The structure
<Target>
<Subject> <-- 'or' between <Subject> elements <SubjectMatch/> <-- 'and' between subject matches (always) <SubjectMatch/> </Subject> <Subject> <-- 'or' between <Subject> elements </Subject> </Target> is a much clearer syntax.
I have yet to see a use for the
example (Select sa.attrA such that sa.attrB="valB" &
sa.attrC="valC"). It only seems to be of benefit when you want to select
an attribute from an anonymous Subject block. Can this not be achieved by
naming the Subject blocks and asking for that particular attribute. e.g.
<SubjectAttributeDesignator AttributeId="AttrC"
Category="MainSubject">. There is a lot less coupling and this seems
far more intuitive for both the policy writer and for the building of the
Request context.
The support for (Select sa.attrA such that
sa.attrB="valB" & sa.attrC="valC") still looks contrived and appears to have
been thrown together at the last minute. This I suspect is why there is
the continual need to clarify the syntax. Unless desperately needed
it would seem best to drop this support in version 1 to give more time to
get the syntax correct.
The main issue we have with Polar is that we are
forced to implement this syntax to do a simple AND. With Simon 1 we
can implement this in a later version of our software. To us this is a
very important distinction as we need to have a deliverable product in
September.
John. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC