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: On delegation constraints

Hello everybody,

In the current delegation draft (draft 1) there is a formulation in
section 3 (on line 93) that defining a constraint for the subject of a
delegated delegation right "seems too complex to be workable". I don't
think this is the case and my experimental implementation has this
feature. During the focus group meeting last week I raised a question
about this and during the brief discussion there was a question about
what the use cases for such a feature would be.

I can see use cases in the application I am involved in. There is a
desire to limit administrative rights to only certain people. In our
case it could be to limit the administrative rights to people within a
headquarters or to only people who have certain training.

I can also imagine (though I don't have real knowledge on this
personally) situations in a commercial setting where there is a legal
liability to perform administration in a particular way. For instance at
a hospital, it could be the case that only certain certified people
should be able to administer rights in order to reduce the risk of
errors. Under such ligal liability to follow certain procedures, it
would be useful to be able to specify the policy in the administrative
rights in XACML, and not to rely on human communication only.

It is of course the case, as Frank pointed out in the discussion about
restricting delegation depth, that prevention of delegation cannot be
enforced in the strict sense. If I have a right to do X, a computer will
not be able to enforce a ban to grant X to someone else, since I can
simply do it myself on behalf of the other person. (The SPKI
specification, among others, discuss this.) However, I still believe
that specifying such a policy has value, in the sense that it
communicates to people what the policy is and keeps the rights cleaner
by preventing the explicit creation of  undesirable rights.

For those who have studied my implementation in detail, I can say that
the model in it is more general than I have use cases for. The
implemented model permits the specification of constraints of arbitrary
depth, which likely is not very useful in practice. In our application
we use constraints of depth one only, which cover the use cases above.

I would suggest that the model for administrative rights for the
upcoming XACML would include at least one level of constraint on the
possible subjects of delegation rights. In case of long chains, all the
issuers in the whole chain would have to meet the constraints. In my
implementation this is equivalent to a constraint of length one with the
"MaySkipOrRepeat" attribute set to true.

Best regards, Erik

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