[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. 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>> >>>> >>> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]