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