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] The new advice "obligation"

bill parducci wrote:
> On Dec 19, 2008, at 7:15 AM, Erik Rissanen wrote:
>> What I mean is that if a PolicySet/Policy/Rule contains an <Advice
>> AppliesTo="NotApplicable">, then it would be returned to the PEP if
>> that policy was processed by the PDP and the final decision is
>> NotApplicable (and to be more precise, that particular NotApplicable
>> was "pushed up" all the way through combination).
> Please bear with me on this since I am still a bit fuzzy... So, you
> are proposing that any Policy/Rule in the scope of the security
> infrastructure that doesn't lead to a Permit/Deny for a given request
> returns an Obligation should the ultimate result be Not Applicable?

I don't understand what you mean. Sorry. :-)

I only mean that those Policise/Rules which actually contain <Advice>
return them. Not any of them.

>> They want to put markers in parts of the policies, which they want to
>> show to the users if the final decision is NotApplicable. The markers
>> would give advice to the user about what was wrong with the access
>> request and the reason to why no policy applied to the request.
> So, if I read of your proposal is correct, any Obligation marked
> AppliesTo="NotApplicable" in and Policy/Rule in the security realm--no
> matter who wrote it or the scope of the decision--would be sent back.
> For example a PDP that serves decisions for the front door access
> control and the accounting system would reply with any NotApplicable
> Obligations across domains should the ultimate decision be NotApplicable?
> Is this correct?

No. It would only apply to <Advice>, not <Obligation>.

And yes, if you mix policies across domains, you would get <Advice>
across domains. So in that case it wouldn't make sense to use them.

But this is really not any different from the case where you use
AppliesTo="Deny" with refactored policies, since in that case you end up
with Denys across domains, so you get interference in policy combining
as well, which is even worse.


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