OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-comment message

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

Subject: Re: [xacml-comment] XACML Obligations - a concurrency model

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.


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

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