[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Delegation and Policy
> That is, for a set of tags T, assuming may-delegate,
>
> KX!(KY,T) validates KY!(KZ,T') for T' = subset(T).
>
Nicely and succinctly put. That's how I see it.
> The nature of the issuer, subject and tags make some delegations natural and
> others absurd. "Subject, may-login" seems a natural candidate to delegate, and looks like a capability. "Subject, has scar on left cheek" appears more like
> an attribute, and delegation seems out of the question. Unfortunately this distinction likely cannot be codified.
>
It's nice to know that absurdities can be certified. Again, I agree.
To save space, I won't quote you, but the thought you bring up in the
license example is the difficulty of determining an intersection where
the thing delegated is not actually granted to those who can delegate
it. Your example of policy would likely solve the problem, but
inelegantly, it seems. A more straightforward solution would involve
the ability to grant only the ability to grant or delegate a privilege
without being able to make use of it directly.
I also should not bring up the conflict-of-interest possibilities whereby
someone privileged to grant a license should not be allowed to grant it
to himself, so I won't. This could, of course, be handled by a policy,
and probably no other way.
Overall, it highlights my belief that intersections must be calculated
in the set-specification language in which the privileges are expressed
unless they are explicitly enumerable.
brian
Brian Thomas, CISSP - Distributed Systems Architect bt0008@entropy.sbc.com
Southwestern Bell bthomas@primary.net
One Bell Center, Room 34G3 Tel: 314 235 3141
St. Louis, MO 63101 Fax: 314 235 0162