[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml-comment] XACML Obligations - a concurrency model
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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]