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] | [Elist Home]


Subject: Re: [xacml] CR 144: function "present" needs to be fixed.



Okay, I'm in trouble on this "*-is-present" stuff.

In looking in the schema, I found out that I probably messed up the
subject-attribut-*-present functions by not having an argument that
states the value of the subject-category attribute.

I also have a problem with the subject-attribute-*-present-where
functions.
I specify that they will take <SubjectMatch> elements as arguments in the
<Apply>. However, that does NOT fit the evaluation strategy very well, as
these elements return booleans, and to be consistent with the generic
function application evaluation model, they should be evaluated
independantly as arguments. Basically, they are evaluated without concern
of being limited to the same subject. We somehow have to bring the
evaluation of the equivalent of subject match into the function.

So, unfortunately, because of multiple subjects, this approach complicates
matters to no end for the function predicates that need to figure this
out, as for subject-attribute-is-present-where I would have to specify
something silly like:

For each subject match we would add to the
subject-attribute-is-present-where function, sets of four arguments, each
of which the first is the MatchId, the second is the attribute name, the
third is the data type, and the fourth is the matching value. (Yuch!)

My conclusion: Since attributes are retrieved by different schema
elements, it seems most logical to make their "is-present" counterparts
schema elements as well, using much of the same machinery already in
place. It would be easy to add these as element of the
AttributeDeignator/Selector/Type complex types we ALREADY have defined:

So, I think a better approach would be to add the following elementsto the
schema with the semantics I proposed in the previous iterations.

These elements woud be element instances of the <AttributeDesignatorType>:

ActionAttributeIsPresent      ActionAttributeMustBePresent
ResourceAttributeIsPresent    ResourceAttributeMustBePresent
EnvironmentAttributeIsPresent EnvironmentAttributeMustBePresent

These elements would be element instances of the
<SubjectAttributeDesignatorType>:

SubjectAttributeIsPresent     SubjectAttributeMustBePresent

These elements would be element instances of the
<SubjectAttributeDesignatorWhereType>:

These elements can be element instances of the <AttributeSelectorType>:

AttributeIsPresent            AttributeMustBePresent

I can modify the document with Word97 and give these sections to the list
if one would like?

-Polar



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


Powered by eList eXpress LLC