Re: [xacml] Modeling Delegation of Rights in a simplified XACML withHaskell

[bill parducci <bill.parducci@overxeer.com>]

Frank Siebenlist wrote:

> One could think of many custom combinators that customers could create 
> themselves, just like the current xacml would let you invent your own 
> combinator (theoretically), but I'm not sure if I want to be associated 
> with the definition of only the most simple combinators...and I sure 
> wouldn't like to prove any correctness for these custom contraptions ;-)

precisely. this is why i think that each issuing PDP be responsible for 
providing an unambiguous answer--via explicit listing, resolution query 
or some other mechanism--something that can't necessarily be sent with 
each policy instance (in the form of a 'delegation chain')

> One combinator that could solve some interesting use case is a threshold 
> one, where the combinator would only evaluate to permit if there are 
> n-of-m issuers that grant that permission according to their associated 
> policy statements.
> 
> A good example is the pilot scheduler case, where the pilot scheduler 
> should be able to have the rights to "make" pilots fly, but who 
> shouldn't have the rights to make him/herself fly.
> This pilot scheduler example could be implemented with the current 
> scheme if we would define so-called threshold-combinators, where 
> combined policies would only evaluate to permit if there are n-of-m 
> issuers that grant that permission. This would allow you to have a 
> separate issuer different from the pilot scheduler who would give policy 
> statements that would let all pilots fly always, and a combinator that 
> would only yield permit if both these issuers would have policy 
> statements that both would yield permit for a scheduled pilot.

hmmm... going to have to think on this one for a while, it is starting 
to sound a lot like meta policy to me (the *first* 'unresolved' issue of 
this TC :o)

b