MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [xacml] Modeling Delegation of Rights in a simplified XACML withHaskell
From: bill parducci <>
To: XACML TC <>
Date: Tue, 18 Nov 2003 16:06:43 -0800
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
