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: [xacml] Today's meeting


Hello,

I am unable to attend the meeting today due to other commitments. Here 
is a short summary on what I have been thinking since the focus group 
meeting.

I already posted my thoughts about combining policies by different 
issuers. In short, I think the entity/authority collecting the policies 
into the PDP has to decide which combining algorithm to use. I am not 
sure if all the existing policy combining algorithms would be useful in 
that context. In any case, using policy combining algorithms would mean 
that delegation has to be handled "internally" in the PDP, not 
externally like my current implementation does.

I have not had time to think much about what it would mean to handle the 
delegation internally in the PDP, but I doubt it would pose any more 
problems than to do it externally.

What I have been working on in the last few weeks is how to make it easy 
for an administrator looking at a set of delegated policies to 
understand how the policies go together, that is, which administrative 
policy authorizes which other policies. There is a fundamental 
difficulty in the approach I have chosen in that it is possible for one 
policy to receive support from different policies depending on the 
access request. This is by design, since it allows for a local 
administrator to combine rights from several sources in a single 
permission, thus decoupling high level adminstration from local 
administration. The downside is that it may be difficult to see how 
things fit together.

A solution I am looking into is to let administrators explicitly state, 
in the form of a link in a delegated policy, which other policy they 
intend to support the policy they are issuing. These links would 
directly show the dependencies among the policies. This has drawbacks in 
itself. For instance if a policy up in the delegation hierarchy is 
replaced, the links would become invalid.

Another idea is to limit the rules/policies to such that they can be 
directly compared ahead of the access request and prevalidated. I think 
this is how Frank is imagining it. This would loose the ability to 
combine rights from several sources though.

Yet another idea is to compare delegations constraints, since they do 
not depend on the particulars of the access request. They would give an 
indication of how what the possible support relations are, and the 
administrator could "fill in the gaps" by looking at the policies 
herself. I worry that this could be computationally expensive and that 
there would be too many "false" indications of support.

So far I do not know have important these problems are, and I have no 
clear solution. I will be working on these issues in the next few weeks.

Best regards, Erik




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