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: Delegation and on-permit-apply-second

Hi Steven,

I don't think we change the delegation model in this way since it would mean changing the core schema, which we really don't want to do at this stage. Also, I think we did consider labeling policies like this in early stages of the delegation work. I don't remember right now why we did not go that way, but I suspect there was a reason. Probably that the current mechanism is more flexible.

Regarding your other suggestions, could you propose changes to the text in the combalgs wd? It's a lot easier to discuss and to come to agreement when there is a proposal to discuss.

After some consideration I think the ideas you posted previously; changing the status code from indeterminate from the first policy, and allowing denys from it, do make sense.

Could you post your suggestion for concrete text?

Best regards,

On 2012-08-28 14:48, Steven Legg wrote:

Hi Erik,

I neglected the fact that the administration profile uses "policy" to mean policy or policy set. Using the same convention, this is what I should have

The fact that the on-permit-apply-second combining rule restricts the
number of child policies to two means that both child policies must
be trusted policies (there is no room for authorizing administrative
policies). This will have implications for access control on the policies
themselves, which will vary between PAP implementations.

A delegation-friendly change would be to restrict a policy set using
the on-permit-apply-second combining rule to exactly two *access* policies
with no limit on the number of administrative policies. The combining
algorithm would test the first access policy (which may need to be
authorized by an administrative policy) before deciding to evaluate
the second access policy (which may also need to be authorized).

I have previously argued on the comment list that labelling each policy
as an access policy or administrative policy would improve the delegation
profile and resolve a number of issues surrounding category prefixing.
Such labelling would make it easy for the on-permit-apply-second
combining rule to tell the difference between access policies and
administrative policies.


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