RE: [xacml] Item 60 (Define standard "purpose" attributes)

["Daniel Engovatov" <dengovatov@bea.com>]

I do not argue that we should not try to define certain attributes
within the standard at all.   It just seems that we should do it in a
more coherent fashion, then one-by-one by exception.

One thing - if we want to make use of such attribute in recombination
algorithms, their "attachment" points should be defined in a more
generic way.

Another thing, that if we had a context definition schema and default
document, then specifying mandatory attributes and their scope would be
easier, then the current model of spreading them out over the standard.
I feel it is the same story as for current-time and id attributes. 

For example we may attach attributes to decision (sort of like we do
with status and obligations.

Daniel;


-----Original Message-----
From: Bill Parducci [mailto:bill.parducci@overxeer.com] 
Sent: Friday, February 13, 2004 1:33 PM
To: Daniel Engovatov
Cc: Tim Moses; XACML
Subject: Re: [xacml] Item 60 (Define standard "purpose" attributes)

Daniel Engovatov wrote:

> Just, if we start going that route, I have a boatload of very useful
> attributes to specify, such as "direction" (access on the way in or
out)
> and so on.

i'm with you on that one; i have been thinking about how best to tackle 
'direction' for quite some time now.

as to this:

 > Could you add to your proposal why this should be part of the
standard?
 > As far as I can see there are no issues with implementing this
behavior
 > using a custom recombination algorithm.

i would offer that if there is sufficient applicability in such
attributes we 
may be able to avoid 'custom recombination algorithms' by implementing
them into 
the spec. by definition, custom extensions create a non-transportable
policy set 
and i believe it is the general consensus of the group to limit the
instances 
where this may be necessary provided there is sufficient justification 
(interoperability being something of good thing :o)

of course, that begs the question of what constitutes sufficient
justification. 
based on tim's proposal i believe that he is making the case that
'purpose' is 
one such attribute. perhaps the most efficient way to deal with this is
to step 
back a little and take a look at a collection of attributes that are not

currently spelled out in the current draft and see if there is a general

approach that can be taken, if each attribute requires a specific
solution or if 
the whole 'boatload' should be handled implementationally (considering
also the 
general perceived value of each).

to that end, if you have additional attributes you would like considered
perhaps 
you could post them? since i suspect that 'purpose' will not be the last

attribute to merit such consideration i personally would be interested
in seeing 
if we cannot create a more general solution to (i have been looking for
a place 
to insert the <existential> tag into the schema: 'i have purpose,
therefore i 
exist' :o)

b