summary of "Obligations rear their ugly head"

[seth proctor <Seth.Proctor@Sun.COM>]

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.