OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-users message

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


Subject: Re: [xacml-users] Chronicle Attribute



Hi David.

> Your suggestion is precisely what we do NOT want to do. The PEP  
> should not need to look inside the obligation attribute  
> assignements. The obligation ID should tell it which service to  
> call, and the Chronicle tells it when to call it.

I understand that you are trying to avoid this, but this is how  
Obligations are defined. They are obligations to the PEP, not to  
anything else. Of course, if the PEP wants to delegate responsibility  
to other entities that's perfectly valid, but from the XACML model  
point of view, this is the defined relationship.

My concern here is that everyone seems to want to do something  
different with Obligations, and sees their definition as subtly  
different. The more we define in the core standard, the less useful I  
fear Obligations will become. As it is, there is confusion about when  
and where to handle Obligations, and what it means to "discharge"  
them. If I have to include a "when" tag on Obligations that are  
handled directly by the PEP, what does this mean? For your specific  
application the meaning may seem clear, but for a lot of systems I've  
worked on, I can think of many ways to interpret the meaning.

Personally, I would far rather see Obligations remain opaque in the  
core, and have a group start work on a best practices styled  
document; something that captures the way people use Obligations, and  
defines some standard structures and identifiers to build around. I  
believe this would be of great general utility.

One reason for such a document is that it would give us a place to  
collect all of these features requests. There are many things people  
would like added to this feature, but it's hard to say how we're  
deciding what actually goes into the core. For instance, everyone  
(no, I'm not exaggerating) who first looks at Obligations thinks that  
you can include an AttributeDesignator which is evaluated at the PDP  
before Obligation are returned to the PEP. This comes from an example  
in the XACML specification that implies this behavior, even though  
this isn't part of the specification. Arguably, this feature would be  
very useful, and is in high demand. We could add it by including a  
tag on AttributeAssignment (e.g.) that says "evaluate this at the PDP  
and include the result as an attribute of type foo." Should we add  
this overhead to the PDP? I don't know.

All this said, there is clear interest from others on the TC in  
having some "when" facility, so I suspect that something will be  
added in 3.0. :)


seth


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