All,
I think this is a good use case which we should support.
After some off list clarifications from Bill, I would like to explain
how this fits in the current obligation families working draft. I think
the document could be improved with respect to this, and I will try to
do so for the next version.
The current draft defines "After", "Before" and "With" options for
obligations after the proposal from David Chadwick. What is currently a
bit unclear perhaps is that when I thought about David's proposal, I
made two distinct interpretations from the metadata "After", "Before"
and "With".
The first interpretation is what I would call the "Causality"
interpretation. According to this interpretation the metadata is
intended to guarantee that, for instance, if the obligation is "After",
then any side effects from the access enforcement will be visible to the
obligation enforcement.
The second interpretation is what I would call the "Atomicity"
interpretation. According to this the metadata is intended to guarantee
that, for instance, if the obligation is "After", then it is guaranteed
that if the obligation is successful, then the access has also been
successful.
I tried to think what David intended and I thought that he was mostly
interested in the atomicity guarantees, so that is what I wrote in the
draft.
What Bill is proposing is the causality interpretation.
I think we should support both. I haven't really thought through yet how
these two can interact and be perhaps combined. My gut feeling is that
the atomicity guarantees should be supersets of the causality
guarantees, that is, if you ask for the atomicity guarantee, you get the
causality as well.
Regards,
Erik
Bill Parducci wrote:
> I would like to propose that we introduce a "TTL" attribute to
> ObligationFamiles, specifically for those that are to occur after the
> decision has been rendered. The use for post decision Obligations
> would be along the lines of:
>
> make request (PEP)
> compute decision (PDP)
> generate response (PDP)
> execute decision (PEP)
> execute obligation; ERROR state if not complete by TTL (PEP)
>
> The thinking here is that if you specify that you wish something to
> happen after the decision is made/enforced then it seems logical that
> you would want it to be time bound. In other words, I am suggesting is
> that there are two reasons why an Obligation may not be met, one
> quantitative (Obligation simply failed), the other qualitative (the
> Obligation is taking longer to fulfill than is considered reasonable
> by the Policy writer).
>
> What is "reasonable"? I don't know, but my opinion is that it is
> defined by the Policy writer not the system administrator because the
> former has the context of what the Policy is supposed to achieve. I
> also suspect that the specification of the TTL value is best suited at
> the ObligationFamily level since it defines the expected behavior for
> that class of Obligation.
>
> How the ERROR behaves and how that information is dealt with is
> implementational.
>
> b
>
> On Feb 17, 2008, at 3:13 AM, erik@axiomatics.com wrote:
>
>> This is a major rewrite of the obligation families profile.
>>
>> Summary of changes:
>>
>> - Use