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: A & D Profile: Revise reduction algorithm

I basically agree with Steven's proposal #2 in:


In summary, Administrative Policies could enable Access Policies in the same PolicySet or in any lower (further from the root) Policy sets. The reduction graph is not used, instead the regular algorithm is used, which recursively finds Authorizing Admin policies until it either hist a trusted policy or runs out of policies to try.

I am not exactly sure what we end up keeping from Section 4 of the Profile and what we need to discard of modify.

I also want to add a non-normative section describing to a Policy Author (as distinct from a PDP implementer) what the effects of various Admin policy choices are. For example, it is currently not easy to understand what the semantics of Permit and Deny are in an Administrative Policy.

It also occurred to me that when evaluating a decision against a large collection of admin and access policies, it might to compute the applicability of the situation (but not the delegate) of every Admin policy we encounter. Then when we actually try to build the delegation chains we would not spend any time on admin policies which can never be applicable. I am not completely sure 1) under what circumstances this would pay off, 2) whether this should be mentioned as a possible optimization or 3) whether it works so well it should be describes as the normative algorithm.



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