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: Re: [xacml] Obligations in Rules?


On Dec 11, 2008, at 8:02 AM, Erik Rissanen wrote:
>
> If we focus back on the original issues for the 3.0 core we are  
> working on:
>
> 1. Do we want to define a special mechanism for "Why" (and/or "What")?
> 2. If so, what is the concrete proposal for that?
> 3. Would it be mechanically different from obligations in any way?
> (And would it be a problem if it's identical. Well, I know you  
> position on this Bill.;-))

Before I can answer #2 or #3 the TC must decide upon your proposal to  
move Obligations to the Rule level :)

So, in the spirit of summarization I offer the following observations:

A. I believe that the justifications for the ObligationExpressions  
proposal were the Boeing Use Cases and anecdotal observations that  
others have run into similar issues.

B. These Use Cases were fairly specific: information as to WHY a  
decision was made are needed

C. It was noted that V2 Obligations can partially solve this problem

D. The use of Obligations for this were met with a luke warm reception  
(or is "kludge" tepid :D )

E. By making Obligations dynamic and adding them at the Rule level the  
problem can be more fully solved


IF my summary is correct on this then I propose that we not extend  
Obligations to the Rule level, make them dynamic and co-opt your  
ObligationExpressions proposal to introduce (Cause|Advice)Expressions.  
Under this scenario the machinery for this would be identical between  
Obligations and Causes from the Policy level up, but would differ in  
that only Causes would exist at the Rule level.

My fundamental reason for suggesting that we not extend Obligations  
down is that they are poorly understood due to a lack of tangible  
function. The original intent of handling asynchronous decision  
actions has waned and what remains is a place to "put stuff that we  
don't account for in the spec". I had hoped that a way to quantify  
(and combine! :) such things would be found--which is why I spent a  
number of weeks early in the V3 process thinking about how to approach  
this--but it proved to be too difficult given a number of factors (not  
the least of which are limitations in my skill set ;) Therefore I  
would prefer that we do not extend something that is fundamentally  
broken (yes, Polar, you did tell me so a few years ago :-p )

I am not excited about "duplicate" machinery, but if we have a chance  
to address a real world problem in a precise way I think we should  
explore it. If there is interest in this approach by others then I  
would be happy to cut and paste the schema bits up, but I think what I  
have outlined above is "concrete" enough for a general decision on  
whether it is a viable option to pursue further.

thanks

b


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