I don't think separation into S, A, R and E is useful conceptually. That
is implementation specifics.
There will be cases when Obligations change attributes not used in
evaluation. So you will need a list of these separately.
Alex
David Chadwick wrote:
> Alex
>
> first of all there can be multiple specialised PIPs, to pick up
> subject, action, resource and environment attributes, and additional
> PIPs to pick up obligation related data. Only the latter will need to
> lock the attributes. So when XACML returns the complete set of
> attributes that are needed we can rule out the S, A, R and E ones
> immediately as they wont need locking by their PIPs. They will be read
> only. Only the coordination ones will need reading and locking by the
> specialist obligation PIP. So I dont think we have a problem if the
> PDP returns which attributes are needed for evaluating each request
> context
>
> regards
>
> David
>
>
> Oleksandr Otenko wrote:
>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
