(bill)
>> In conjunction logically yes. In conjunction syntactically within a
>> Policy, Nno. The PDP must dictate order, not the Policy(Set) or it
>> will not work.
>
(hal)
> Can you elaborate? Why would it not work? (I can think of reasons, I
> just want to know yours.)
Sure... or at least I can try (my experience with working Obligations
is that the things get weird pretty quick :)
To begin with there would need to be an unambiguous precedence of
Obligations(Category|Families) for the PDP to be able to determine the
order of exclusivity as well as the scope of such exclusivity
deterministically.
For example assume you have Obligations pertaining to encryption. Ob1
says encrypt:3DES, Ob2 says encrypt:blowfish. Both know that
encryption must occur as well as that there should only be a single
encryption mechanism so they each declare themselves as Exclusive,
"Level 1" in priority. What's a PDP to do?
Knowing that 3DES and blowfish have any relationship requires some
sort of associative categorization/classification. Since I assume we
are stepping off into the realm of PDP awareness re: Obligations it
seems unrealistic that the Policy is the place for determining that
3DES takes precedence over blowfish and both of them fit into a
Category. It seems highly likely that diverse Policies may not know of
the existence (or name for that matter) of other, similar Obligation
mechanisms.
For this reason I think an Obligation need only declare its Name and
Category in the Policy and that the PDP maintains the order of
precedence, exclusivity, etc. above that. In the example above both
Obligations would declare themselves as Category "Encryption" and the
PDP would know that there are exclusion rules and the order of
precedence for this Category and return the appropriate Obligation to
the PEP.
Again, this obviously assumes that the PDP will act upon this
information. I guess that the case could be made that the PDP
continues to blindly collect all of the Obligations--along with the
newly added Exclusivity and Precedence information--and pass the whole
mess back to the PEP but I believe that is an unworkable solution, one
which begs the question of the need for adding this additional
information in the Policy in the first place since you would have a
Big White Box solution that extends out to the PEP (and you are just
as well off using "drinkMagicPotion6" for the Obligation ;)
BTW, the concept on a "knowledgeable PDP" is why I think that the PDP
meta data should include information pertaining to what the PDP is
aware of in terms of Obligations (or if it supports Obligations at
all). It seems like it would be a good thing to know if you were PEP
in a distributed environment :)
b
