[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: summary of "Obligations rear their ugly head"
If you're like me, you've been swamped for the last week, and haven't had the time to carefully follow the thread between Polar and Bill on Obligations [1], which is too bad, since it's raised some excellent points. Sooo, as a public service, I've decided to summerize what I think the key points are, and extract what I think the lessons are. Hope this is helpful...Bill and Polar, please correct me :) The key point of this discussion centers around what Obligations really mean, and what a PEP is supposed to do with them, especially in error cases. For that matter, it's somewhat unclear exactly what all the error cases are. A second point is what the relationship really is between a PEP and a PDP, and based on that what a PEP should be free to do with decisions. At the start of the discussion, Polar raised a good question (and I'm paraphrasing here): what does "provided that" mean in the context of enforcing obligations at the PEP? In other words, if the spec says that the PEP should follow the Permit/Deny decision provided that it obeys the Obligations, what does that mean? We don't really want to push any authorization decisions out the PEP, but that's what this sounds like. Bill suggested that the PEP must be capable of understanding and supporting the Obligations it is given. This doesn't mean that the PEP must be able to take the obligated action right then (for example, it might delay sending email if the server is unavailable, or it might wait 30 days before expiring some 30-day-valid access token). The PEP simply must be able to undertand the obligations and know how to act on them eventually. [Personally, I think this is the right way to think about it] What this means is that if the PEP gets a Permit with obligations, and if it understands the obligations, then it should Permit. If it doesn't understand the obligations, then this is an error. The natural question, therefore, is how is this different than Deny, and for that matter how do you handle Deny when the PEP doesn't understand an obligation? In general, I think we all agree that these are error cases (ie, Indeterminate), and that the PEP should act accordingly: ping another PDP, look up the Obligation in some service, give up with an error, or whatever other app-specific behavior it knows. [the meta-comment here is that Obligations are optional, and so you don't have to use them, but that still doesn't help define what a PEP does when it encounters an Obligation it can't understand...thus, the comments about error handling] Related to this, Polar raised another good issue (again, I'm paraphrasing): what is the relationship between the PEP and PDP, and should the PEP always obey the PDP? Bill asserted that there is some relationship between the two, and it would be invalid for a PEP to flat-out ignore a decision, an obligation, etc. However, it's perfectly within a PEP's rights to balance a PDP's decision against other factors, like the decisions from other PDPs. I think there was agreement on this point. One specific editorial comment that Polar suggested (and I agree with) is that in the example showing Obligations, the text that reads "allow...provided that an email is sent to the patient" should be changed to "allow...with an Obligation to send email to the patient." Whew. There were, obiously, other details in the discussion, but I think that captures the high-order bits. Please someone chime in if I've missed an important point (it's getting a little late <g>). seth [1] No, this isn't about Obligations in Rules or about determinism. I'll respond to those issues in separate emails.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]