Do you also lock the attributes used in Obligations? Does XACML allow to
return those? Does XACML allow to distinguish the use of attributes (r
for decision-making, w for Obligation enforcement). If either of the
answers is "no", we've got a problem.
Alex
David Chadwick wrote:
> Hi Alex
>
> we can link the lock with the unlock by the PIP recording the
> transaction ID in the request context as an environmental attribute
> (and the PDP ignores it), but the obligation uses it to know which
> lock to release. Even if it is a per PDP lock there might still be
> other PDPs locking other parts of the coordination database at the
> same time, so the transaction ID is still needed to be passed.
>
> regards
>
> David
>
>
> Oleksandr Otenko wrote:
>> I think the issue is more complex than that, as you need to lock the
>> attributes used in Obligations, too, and there should be a mechanism
>> to link the lock with unlock, if the implementer were to go that way.
>> I think the support for transactional model for decision-making
>> should be evaluated, if it wasn't already.
>>
>> The effect of per-policy vs per-PDP call locking depends more on the
>> number of concurrent requests than the size of the policy. But I
>> guess this is more of an implementation issue.
>>
>>
>> Alex
>>
>> David Chadwick wrote:
>>> Hi Alex
>>>
>>> yes you are correct. XACML already has elements for returning the
>>> attributes that are needed, in response to a decision request.
>>> Alternatively, we implemented a method GetAttributes that can be
>>> called on the PDP by the PEP at anytime (but usually at start up) to
>>> get the full set of environment attributes in the policy. This is ok
>>> for small policies but not for large ones where a per user request
>>> return is needed. So there is a trade off here, which someone would
>>> need to experimentally measure, to see at what policy size the per
>>> call becomes more efficient that the per PDP return of attributes.
>>>
>>> regards
>>>
>>> David
>>>
>>> Oleksandr Otenko wrote:
>>>> Thanks, Rich. I wasn't implying the PDP needs to understand
>>>> transactions, but someone has to, and that is more likely to be the
>>>> entity enforcing the obligations. On the other hand, it is not the
>>>> obligation enforcer that obtains the values of the attributes used
>>>> for access control decisions. It is probably the PIP that has to
>>>> lock the attributes, but it is the Obligation Enforcer that has to
>>>> unlock them.
>>>>
>>>> Transaction coordination is an important task that requires close
>>>> interaction with and between the P*P entities. For example,
>>>> currently there is no way of knowing which attributes to lock, for
>>>> what purpose (r/w), and for how long. Trivial solutions cause
>>>> problems. The best solution would be to refine the policy set based
>>>> on the request, to feed back what attributes need locking for
>>>> update before a decision is made, and what attributes might need
>>>> locking for reading until the obligations are enforced (which also
>>>> need locking prior to decision-making). The careful definition of
>>>> "before, with, after" temporal constraints could address the "how
>>>> long" part.
>>>>
>>>>
>>>> Alex
>>>>
>>>>
>>>> Rich.Levinson wrote:
>>>>> Hi Oleksandr,
>>>>>
>>>>> I am working under the assumption that the PDP does not maintain
>>>>> its own database of attributes, so therefore, I am assuming that
>>>>> the account balance Attribute you are referring to is maintained
>>>>> by some system or combination of systems external to the PDP, and
>>>>> that if the PDP has to obtain a value for this attribute that it
>>>>> has a way thru the logical ContextHandler to obtain it.
>>>>>
>>>>> I am also assuming that when the PDP obtains an Attribute thru one
>>>>> of its access channels (i.e. either in the initial request, or
>>>>> somehow thru ContextHandler reaching out and obtaining thru some
>>>>> proprietary mechanism (i.e. some mechanism not defined or even
>>>>> identified in the XACML spec)), that it can safely assume that the
>>>>> value of that Attribute has been delivered in a reliable manner
>>>>> (integrity for certain, and presumably confidentiality) from a
>>>>> trusted source (provider of that particular kind of Attribute).
>>>>>
>>>>> Given those assumptions, the PDP can process the Attribute without
>>>>> needing to do any "second-guessing" as to whether the Attribute
>>>>> should be used or not. It is what it is, and will be used as
>>>>> delivered and Policy logic should determine whether the Attribute
>>>>> meets whatever conditions are required of it for any possible
>>>>> value that is delivered for it. i.e. either the Attribute is
>>>>> within the ranges allowed for it or not. If outside the ranges,
>>>>> then appropriate exception handling should exist in the Policies
>>>>> to determine what to do based on that.
>>>>>
>>>>> Now, from what I gather from your use case description, the PDP is
>>>>> expected to return this Attribute in an AttributeAssignment
>>>>> element of an Obligation, possibly under some conditions it will
>>>>> return it and others not depending on Policy evaluation, but at
>>>>> least in some cases it can be returned.
>>>>>
>>>>> Trying to read a little more into the use case, I am assuming that
>>>>> this account balance can possibly be changed by the user if they
>>>>> are granted access, and that one wants to ensure that there are no
>>>>> timing windows thru which inconsistent results can get into the data.
>>>>>
>>>>> In general, to achieve this objective, one would need to "lock"
>>>>> the attribute for the duration of the transaction. In a
>>>>> distributed data base there are many strategies to provide this
>>>>> capability, however, I do not think that the PDP is an active
>>>>> player in the transaction, i.e. I would think the transaction
>>>>> "coordination" is being done by some entity external to the PDP.
>>>>>
>>>>> In this case, my sense is that for the PDP to safely read this
>>>>> Attribute, it is the responsibility of the transaction coordinator
>>>>> to first initiate the transaction and lock any Attributes needed
>>>>> for consistency of the transaction, and that the authorization
>>>>> would take place within the bounds of the transaction. For
>>>>> example, if the PEP happened to be the transaction coordinator, I
>>>>> would expect the PEP would do some kind of "BeginTransaction",
>>>>> then issue the authorization call to determine if user is
>>>>> authorized based on the state of the data within the transaction,
>>>>> and, if so, then allow the user to complete the transaction and
>>>>> end it.
>>>>>
>>>>> In such a scenario, the PDP could obtain the Attribute and return
>>>>> it in an Obligation to the PEP and if that happens within the
>>>>> bounds of the transaction there should be no problem.
>>>>>
>>>>> Where I do see a problem is if it is assumed that by getting the
>>>>> Attribute, that the PDP is effectively taking on some role as
>>>>> transaction coordinator and taking some responsibility for the
>>>>> validity of the data. I think this would be outside the scope of
>>>>> intended functionality for a PDP.
>>>>>
>>>>> In this context, as described above, I don't see any reason that
>>>>> the PDP would need to be involved with the "before, after, or
>>>>> with" aspects of the handling of the Attribute.
>>>>>
>>>>> If I missed something about the use case that would change that,
>>>>> please let me know, I am only working with the information as I
>>>>> read it from your email.
>>>>>
>>>>> Thanks,
>>>>> Rich
>>>>>
>>>>>
>>>>> Oleksandr Otenko wrote:
>>>>>> Hi Rich,
>>>>>>
>>>>>>
>>>>>> Say the decision is based on a value of an Attribute (account
>>>>>> balance for a cloud computing user). A distributed system needs
>>>>>> to maintain the value, and update it coherently across multiple
>>>>>> nodes. Is this Attribute Assignment part of an Obligations spec
>>>>>> or is it considered business process logic? If it is going to be
>>>>>> part of the Obligations spec, the "after, with, before" are going
>>>>>> to be, and the synchronization mechanism needs defining. But as
>>>>>> you said, this is probably for later in this case.
>>>>>>
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>> Rich.Levinson wrote:
>>>>>>> Hello Erik and Oleksandr,
>>>>>>>
>>>>>>> I would like to throw 2 cents in here, as well. As Erik states,
>>>>>>> we have not been actively reviewing this spec since it is not
>>>>>>> planned as part of the core release of 3.0. The issue caught my
>>>>>>> attention, because I hadn't realized this stateful type of info
>>>>>>> had been added to Obligations WD3:
>>>>>>> http://www.oasis-open.org/committees/download.php/27230/xacml-3.0-obligation-v1-wd-03.zip
>>>>>>>
>>>>>>> which, it might be useful to note, was actually released on
>>>>>>> 20-Feb-08, as opposed to the date in the spec which was not
>>>>>>> updated and is the same as WD2, which is 28-Dec-07.
>>>>>>>
>>>>>>> In any event, I had done some thinking about Obligations earlier
>>>>>>> wrt to XACML 2.0 and my sense was that it would make sense to
>>>>>>> think of 2 classes of Obligations:
>>>>>>>
>>>>>>> 1. pre-Condition Obligations, which need to be in effect before
>>>>>>> access is granted, for example, the subject guarantees not to
>>>>>>> disclose the data being requested to 3rd parties.
>>>>>>> 2. post-Condition Obligations, which generally will take effect
>>>>>>> after access is granted, for example, the subject
>>>>>>> guarantees to
>>>>>>> delete the data after 30 days, although, this may also be
>>>>>>> viewed
>>>>>>> as a pre-Condition Obligation; possibly a better example
>>>>>>> would
>>>>>>> be that the PEP will send an email to the party about whom
>>>>>>> the
>>>>>>> data being returned is about.
>>>>>>>
>>>>>>> Using 2.0, the way I would probably go about implementing case
>>>>>>> 1, the pre-condition, would be to issue a Deny with an
>>>>>>> accompanying Obligation which the PEP could inform the user that
>>>>>>> in order to access the data, that the user would have to agree
>>>>>>> to some conditions, which the PEP could obtain, and then the PEP
>>>>>>> would re-submit the request with an additional Attribute
>>>>>>> indicating that this Obligation had been met before the request
>>>>>>> was being made.
>>>>>>>
>>>>>>> With this approach, I see little need to introduce the potential
>>>>>>> complexity that the WD3 proposal includes with the "before,
>>>>>>> after, with, any" constructs, which as the previous emails
>>>>>>> indicate are not particularly clearly definable without probably
>>>>>>> the necessity of introducing some kind of workflow at the PEP
>>>>>>> which will guarantee ordering of tasks or require some kind of
>>>>>>> 2-phase commit to ensure that Obligations and access decisions
>>>>>>> are not in violation of some yet to be defined rules for some
>>>>>>> yet to be defined use cases.
>>>>>>>
>>>>>>> If there are such use cases, I think it would be advisable to
>>>>>>> introduce them as a basis for requiring these capabilities,
>>>>>>> before we consume a number of cycles analyzing the technology.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Rich
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Oleksandr Otenko wrote:
>>>>>>>> Thanks for your response.
>>>>>>>>
>>>>>>>> I notice there are obligations such as Attribute Assignment. I
>>>>>>>> regard it is possible to use the values of the attributes
>>>>>>>> during concurrent decision processes, therefore it is important
>>>>>>>> to understand the concurrency model.
>>>>>>>>
>>>>>>>> BTW, as far as I am aware, the ATMs first withdraw the money,
>>>>>>>> then dispense, and only if the dispense phase fails, they
>>>>>>>> execute a recovery or rollback step. There is no guarantee when
>>>>>>>> the rollback step completes, and in some implementations you
>>>>>>>> can see the account debited for significant periods of time.
>>>>>>>> Account update will be a common case of obligation, and often
>>>>>>>> it will be important to lock some amount even upon failure than
>>>>>>>> overspend.
>>>>>>>>
>>>>>>>>
>>>>>>>> Alex
>>>>>>>>
>>>>>>>> Erik Rissanen wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Thanks for the very thorough analysis.
>>>>>>>>>
>>>>>>>>> You can find the draft under "work in progress" on the XACML
>>>>>>>>> TC web page. It's called "obligation families".
>>>>>>>>>
>>>>>>>>> The draft is very early work, carelessly written by me :-),
>>>>>>>>> and certainly not in any way ready for implementation. Just so
>>>>>>>>> everybody knows... :-)
>>>>>>>>>
>>>>>>>>> I have not read your analysis very carefully yet, but I get
>>>>>>>>> the feeling that there has been a misunderstanding. The words
>>>>>>>>> "after", "before" and "with" are confusing. The draft does not
>>>>>>>>> attempt to define a temporal/causal order of enforcement.
>>>>>>>>> There was no intention to provide any guarantees with respect
>>>>>>>>> to side effects of enforcement.
>>>>>>>>>
>>>>>>>>> I used those names because I couldn't think of anything better
>>>>>>>>> and because after and before are simple ways to implement the
>>>>>>>>> guarantees which I was describing.
>>>>>>>>>
>>>>>>>>> What really was intended was to provide a mechanism which
>>>>>>>>> allows policy writers to have guarantees about the atomicity
>>>>>>>>> of the dual enforcement of the obligation and the access
>>>>>>>>> enforcement. To say things like "access must not be granted if
>>>>>>>>> obligations cannot be enforced", or "an obligation must not be
>>>>>>>>> enforced unless access enforcement is guaranteed to succeed",
>>>>>>>>> etc.
>>>>>>>>>
>>>>>>>>> BTW, you are right, a simple method by which to implement the
>>>>>>>>> "After" guarantee is simply to never run the obligation. That
>>>>>>>>> is the intended meaning. It is intended for those cases where
>>>>>>>>> it is important that the obligation is _never_ enforced unless
>>>>>>>>> the access was successfully enforced. For instance, consider a
>>>>>>>>> case where a granted access means a billing event. If you are
>>>>>>>>> concerned about your customer relations you want to make sure
>>>>>>>>> that you never bill for an access which was not successful.
>>>>>>>>>
>>>>>>>>> You should also note that in many cases some of these
>>>>>>>>> guarantees cannot be provided. If the guarantee cannot be
>>>>>>>>> provided the PEP should report failure. It might also be
>>>>>>>>> possible to detect this already at the time of policy
>>>>>>>>> deployment and the PDP could return an error saying that the
>>>>>>>>> policy contains requirements which cannot be enforced.
>>>>>>>>>
>>>>>>>>> In any case, I am not pursuing this right now because I am
>>>>>>>>> focusing on getting the XACML 3.0 core done. I will look into
>>>>>>>>> this in detail once the core XACML stuff is done, and we
>>>>>>>>> revisit this work.
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Erik
>>>>>>>>> Oleksandr Otenko wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> We were discussing XACML draft with David with regards to the
>>>>>>>>>> Obligations definitions. Can you help me understand the
>>>>>>>>>> reasoning behind them? I cannot find the draft myself, but I
>>>>>>>>>> have issues with what David quoted; I trust it is a complete
>>>>>>>>>> copy:
>>>>>>>>>>
>>>>>>>>>>> *Obligation before access*
>>>>>>>>>>> This mode guarantees that if the access control decision is
>>>>>>>>>>> successfully enforced, then the obligation is also
>>>>>>>>>>> successfully enforced. (This mode does NOT guarantee that
>>>>>>>>>>> access decision is successfully enforced even if the
>>>>>>>>>>> obligation is enforced.)
>>>>>>>>>>>
>>>>>>>>>>> *Obligation after access*
>>>>>>>>>>> This mode guarantees that if the obligation is successfully
>>>>>>>>>>> enforced, then the access control decision is also
>>>>>>>>>>> successfully enforced. (This mode does NOT guarantee that
>>>>>>>>>>> the obligation is successfully enforced even if the access
>>>>>>>>>>> decision is enforced.)
>>>>>>>>>>>
>>>>>>>>>>> *Obligation with access*
>>>>>>>>>>> This mode guarantees that the obligation is successfully
>>>>>>>>>>> enforced if and only if the access control decision is
>>>>>>>>>>> successfully enforced.
>>>>>>>>>>> *Any timing*
>>>>>>>>>>> In this mode the PEP makes a best effort attempt to enforce
>>>>>>>>>>> both the obligation and the access decision and no guarantee
>>>>>>>>>>> is made about success.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I have no problem with the definitions as they are, but want
>>>>>>>>>> to clarify
>>>>>>>>>> it means that:
>>>>>>>>>>
>>>>>>>>>> * *With* is the same as *After* in this interpretation
>>>>>>>>>> * *Any timing* can be the same as *After*
>>>>>>>>>> * *After* is not obligatory for enforcement
>>>>>>>>>> * (Thus only *Before* is a true obligation)
>>>>>>>>>>
>>>>>>>>>> This becomes evident if you consider a concurrency model with
>>>>>>>>>> *happens-before* predicate (e.g. as used in Java memory
>>>>>>>>>> model, 3-rd
>>>>>>>>>> edition). Please, follow me on this:
>>>>>>>>>>
>>>>>>>>>> Since *After* starts after the access decision is enforced,
>>>>>>>>>> there is no
>>>>>>>>>> guarantee when the effects of the obligation are observed.
>>>>>>>>>> This is fine
>>>>>>>>>> with me, as this is the definition of the "best effort", and
>>>>>>>>>> there is
>>>>>>>>>> the place for that in the security policies. However, the
>>>>>>>>>> cheapest way
>>>>>>>>>> to implement "best effort" is to /never/ execute such
>>>>>>>>>> obligation. This
>>>>>>>>>> is made clear in the statement about *After*, but: a) this is
>>>>>>>>>> just like
>>>>>>>>>> *Any timing*, so the latter can be deprecated; b) marking
>>>>>>>>>> obligation
>>>>>>>>>> *After* makes it not obligatory for enforcement (kind of, it
>>>>>>>>>> becomes a
>>>>>>>>>> non-Obligation).
>>>>>>>>>>
>>>>>>>>>> The definition of *With* in the form quoted also lacks the
>>>>>>>>>> definition of
>>>>>>>>>> the timing the effects of *With* are observed. All that it
>>>>>>>>>> states, is
>>>>>>>>>> that it can be observed after a successful access control
>>>>>>>>>> decision
>>>>>>>>>> enforcement: it doesn't state /how soon/. This allows for an
>>>>>>>>>> implementation that performs the "best effort" enforcement.
>>>>>>>>>> This also is
>>>>>>>>>> fine with me, but then *With* becomes the same as *After*.
>>>>>>>>>>
>>>>>>>>>> Please, correct me, but it seems the definition of the
>>>>>>>>>> obligations in
>>>>>>>>>> the current form can be rewritten using the *happens-before*
>>>>>>>>>> predicate
>>>>>>>>>> as follows:
>>>>>>>>>>
>>>>>>>>>> * The last step of *Before* Obligation *happens-before*
>>>>>>>>>> the first
>>>>>>>>>> step of access control decision enforcement process
>>>>>>>>>> * The last step of the access control decision enforcement
>>>>>>>>>> process
>>>>>>>>>> *happens-before* the /first/ step of *After* Obligation
>>>>>>>>>> * The last step of the access control decision enforcement
>>>>>>>>>> process
>>>>>>>>>> *happens-before* the /last/ step of *With* Obligation
>>>>>>>>>> * *Any timing* has no *happens-before* relationship with
>>>>>>>>>> access
>>>>>>>>>> control decision enforcement process (unsynchronized;
>>>>>>>>>> hmmmm, maybe
>>>>>>>>>> there is some value in having it, after all)
>>>>>>>>>>
>>>>>>>>>> You can see why I think *With* is the same as *After*:
>>>>>>>>>> *After*'s /last/
>>>>>>>>>> step is executed in the same way as *With*'s, and since there
>>>>>>>>>> is no
>>>>>>>>>> requirement about the timing of the /first/ step of *With*,
>>>>>>>>>> the least
>>>>>>>>>> effort implementation is to implement it as *After*.
>>>>>>>>>>
>>>>>>>>>> I propose to modify the definition of *With* using the
>>>>>>>>>> *happens-before*
>>>>>>>>>> predicate, which allows to express the timing of the
>>>>>>>>>> enforcement more
>>>>>>>>>> precisely, and makes the purpose of the obligations more clear:
>>>>>>>>>>
>>>>>>>>>> * The last step of *Before* Obligation *happens-before*
>>>>>>>>>> the first
>>>>>>>>>> step of access control decision enforcement process
>>>>>>>>>> o This makes sure the effects of the Obligation can be
>>>>>>>>>> observed /during the access control decision
>>>>>>>>>> enforcement
>>>>>>>>>> process/
>>>>>>>>>> o *Caveat*: the effects of the Obligation may not be
>>>>>>>>>> observed,
>>>>>>>>>> if there was an intervening Obligation enforced
>>>>>>>>>> concurrently
>>>>>>>>>> * The last step of the access control decision enforcement
>>>>>>>>>> process
>>>>>>>>>> *happens-before* the first step of *After* Obligation
>>>>>>>>>> o This makes sure the effects of the access control
>>>>>>>>>> decision
>>>>>>>>>> enforcement process can be observed /during the
>>>>>>>>>> Obligation
>>>>>>>>>> enforcement/
>>>>>>>>>> o *Caveat*: the effects of the decision enforcement
>>>>>>>>>> may not be
>>>>>>>>>> observed, if there was an intervening decision
>>>>>>>>>> enforced
>>>>>>>>>> concurrently
>>>>>>>>>> * The last step of *With* Obligation *happens-before* the
>>>>>>>>>> last step
>>>>>>>>>> of the access control decision enforcement process
>>>>>>>>>> o There is no guarantee that either of the processes
>>>>>>>>>> will
>>>>>>>>>> observe the effects of the other
>>>>>>>>>> o This makes sure the effects of the Obligation can be
>>>>>>>>>> observed at the same time the effects of the
>>>>>>>>>> access control
>>>>>>>>>> decision enforcement are
>>>>>>>>>> o *Caveat*: the effects of the Obligation may not be
>>>>>>>>>> observed,
>>>>>>>>>> if there was an intervening Obligation enforced
>>>>>>>>>> concurrently
>>>>>>>>>> o *Caveat*: this does not explain what happens to the
>>>>>>>>>> Obligation, if the access control decision is /not
>>>>>>>>>> enforced/
>>>>>>>>>> (e.g. fails)
>>>>>>>>>>
>>>>>>>>>> If it is critical to observe all effects (reads: it is
>>>>>>>>>> critical to beat
>>>>>>>>>> all caveats), use the synchronization techniques between the
>>>>>>>>>> monitor,
>>>>>>>>>> the Obligation enforcer, and the decision enforcer.
>>>>>>>>>>
>>>>>>>>>> Notice that now *With* can be implemented as *Before*, but
>>>>>>>>>> that is good
>>>>>>>>>> as far as the word Obligation is concerned. There is a
>>>>>>>>>> significant
>>>>>>>>>> difference in the wording of the two, which allows the
>>>>>>>>>> implementers to
>>>>>>>>>> optimize *With* differently to *Before*.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *Discussion of With Obligation*
>>>>>>>>>>
>>>>>>>>>> Access control decision enforcement and Obligation
>>>>>>>>>> enforcement are
>>>>>>>>>> independent processes. This means that without explicit
>>>>>>>>>> synchronization
>>>>>>>>>> the effects of the processes can be observed in an arbitrary
>>>>>>>>>> order. The
>>>>>>>>>> existing wording of the draft allows for the effects of
>>>>>>>>>> *With* to not be
>>>>>>>>>> observed at all. My concern is that it will be implemented as
>>>>>>>>>> such, and
>>>>>>>>>> the only Obligation mandatory for enforcement is *Before*. The
>>>>>>>>>> modification I propose is necessary, because there is no way to
>>>>>>>>>> /guarantee/ when the process /ends/.
>>>>>>>>>>
>>>>>>>>>> The modified definitions are based on a concurrency model,
>>>>>>>>>> and they
>>>>>>>>>> clearly state the observed effects of each Obligation in a
>>>>>>>>>> concurrent world.
>>>>>>>>>>
>>>>>>>>>> In my opinion it is not possible to implement the "if and
>>>>>>>>>> only if" part
>>>>>>>>>> of the *With* Obligation without a concurrency issue. This is
>>>>>>>>>> because
>>>>>>>>>> either it is enforced *After* the access control decision
>>>>>>>>>> enforcement is
>>>>>>>>>> known to have succeeded (no point to have *With* as a
>>>>>>>>>> separate type), or
>>>>>>>>>> allow the Obligation's effects to be observed upon access
>>>>>>>>>> control
>>>>>>>>>> decision enforcement failure. My proposal is to allow the
>>>>>>>>>> latter, as in
>>>>>>>>>> that case it makes sense to have *With* as a separate type of
>>>>>>>>>> the
>>>>>>>>>> Obligation.
>>>>>>>>>>
>>>>>>>>>> It is possible to reduce the implementation options by
>>>>>>>>>> placing further
>>>>>>>>>> constraints, e.g.:
>>>>>>>>>>
>>>>>>>>>> * The first step of the access control decision enforcement
>>>>>>>>>> *happens-before* the first step of *With* Obligation
>>>>>>>>>> o This makes sure that the implementation is not the
>>>>>>>>>> same as
>>>>>>>>>> that of *Before*
>>>>>>>>>> o The only reason you may observe the effects of this
>>>>>>>>>> Obligation is that the decision enforcement was
>>>>>>>>>> /attempted/
>>>>>>>>>> * The effects of the *With* Obligation should not be
>>>>>>>>>> observed, if
>>>>>>>>>> the first step of the *With* Obligation *happens-before*
>>>>>>>>>> the
>>>>>>>>>> access control decision enforcement failure
>>>>>>>>>> o This is a lenient implementation of the "if and
>>>>>>>>>> only if"
>>>>>>>>>> requirement of the *With* Obligation
>>>>>>>>>> o There is a possibility that the effect of the *With*
>>>>>>>>>> Obligation is observed for indefinite time, at
>>>>>>>>>> least if its
>>>>>>>>>> last step /also/ *happened-before* the failure to
>>>>>>>>>> enforce
>>>>>>>>>> the access control decision
>>>>>>>>>> o There is a point for the implementors to spend the
>>>>>>>>>> effort
>>>>>>>>>> rolling the Obligation's effects back upon the
>>>>>>>>>> failure of
>>>>>>>>>> decision enforcement, to create a /fairer/ system of
>>>>>>>>>> obligations; but if that is critical, a new
>>>>>>>>>> constraint needs
>>>>>>>>>> to be introduced to clarify before when the last
>>>>>>>>>> step of the
>>>>>>>>>> rollback should happen
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Dr. Alex Otenko
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>
>>>>
>>>
>>
>
