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


I haven't spent much time on this, but a few comments come to my mind. I might have said these earlier already.

Separating out admin policies means that it is no longer possible to nest a self contained policy set in a larger context, where the nested policy could contain admin policies, which are independent of other parts of the policy hierarchy. Such hierarchies may be useful in very large deployments, where different sub trees are managed by different entities, and the trees should not interfere with each other. If there instead is an "admin policy bucket" where everybody puts their admin policies, then interference is possible.

Early drafts of the delegation profile used recursive evaluations instead of the delegation graph. We thought that we had good reasons back then to instead use a graph, so it might not be a good idea to switch back to recursive evaluations. I don't remember the details but some of the issues I think we solved were the proper treatment of Indeterminate results and there might be performance benefits for the graph too, but I haven't analyzed it in detail. I know that the very early drafts were NP-complete, but that was because of the possibility to define conditions on intermediate delegates.

In any case, I don't feel very strongly about this since I don't see a market demand for it. :-)

Best regards,

On 2014-09-04 21:25, Hal Lockhart wrote:
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.



To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

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