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] | [Elist Home]

Subject: RE: [xacml] [glossary] Comments

I just wanted to describe two different scenarios, not one scenario that
two different interpretations for one conditional statement. In other
a system in some company may use a condition statement as a precondition.
In that system, the PDP always returns a binary answer according to the
result of the condition evaluation. On the other hand, another PDP in
company may use a condition statement as a postcondition like "if all the
conditions are met, one of the required actions is to enforce the
I think this flexibility allows wider applicability of XACML policies.

Michiharu Kudo

From: Hal Lockhart <hal.lockhart@entegrity.com> on 2001/10/26 22:23

Please respond to Hal Lockhart <hal.lockhart@entegrity.com>

To:   Michiharu Kudoh/Japan/IBM@IBMJP, "Tim Moses <tim.moses"
cc:   xacml@lists.oasis-open.org
Subject:  RE: [xacml] [glossary] Comments

I don't see any reason why the same attribute can sometimes be a
precondition and sometimes a post condition. I do think the distinction
between a precondition, that a PDP can satisfy itself is already true and a
postcondition, that the PDP must ask the PEP to enforce is a useful one.

I hope you are not proposing that we have a policy language that can say
"try to determine if this condition is true, but if you can't, ask the PEP
to try to enforce it."

I would much prefer a language that can clearly say "don't allow the
unless this is true" and also say "if all the conditions are met, one of
required actions is to enforce the following."


> 1. Policy Condition
> XACML's definition is similar to SAML's definition. It is close to
> the notion of post-conditions as suggested by Carlisle's requirement
> draft, item 16.
> http://lists.oasis-open.org/archives/xacml/200109/msg00100.html
> This is also close to the notion of PolicyAction defined in the Policy
> Core Information Model (RFC3060)
> http://www.ietf.org/rfc/rfc3060.txt
> On the other hand, I think we have to define a term for the condition
> that is associated with each access control rule stored in the PRP.
> That condition is evaluated in selecting access control rules
> in response
> to each decision request. It is close to the notion of
> pre-conditions or
> PCIM's PolicyCondition.
> But I think pre-conditions and post-conditions are not necessarily
> separate.
> Suppose that there is a rule saying "Access is allowed if Initiator is
> older than 18." If the decision request contains a birthday
> attribute of
> the Initiator, then the above rule potentially means grant.
> The statement "if Initiator is older than 18" associated with
> that rule
> is pre-condition of the rule. In this case there is no need for
> post-condition
> in the authorization decision.
> But, it may be the case that birthday attribute is not
> available in PDP
> side. Then PDP may make a decision such as "access is allowed, if
> Initiator is older than 18." In this case, we can call the additional
> condition as post-condition or Policy Condition.
> We should use two different terms in each case described above.
> My suggestion is the following:
> pre condition: Rule Condition
> post condition: Policy Condition

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

Powered by eList eXpress LLC