OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [xacml] New core and multiple resource profile

>> 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.
> 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  

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  

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 :)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]