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: [xacml] [glossary] Comments

The following is my comments on the XACML glossary.

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.

This is also close to the notion of PolicyAction defined in the Policy
Core Information Model (RFC3060)

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
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
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

2. Policy Conflict

I think Policy Conflict would not be a right term in the XACML context.
I agree to that a set of access control rules may conflict each other.
But such conflict should be resolved before making an authorization
decision using meta-policy etc. Thus, it would be nicer to call it as
a conflicting rule or rule conflict. The meta-policy (I am not sure how we
should call it here) used to resolve conflicts could be called conflict
resolution policy.

My suggestion is to use "Rule Conflict" instead of "Policy Conflict"

3. Meta-policy

I suppose different people may have different idea on the Meta-policy.
It can imply from conflict resolution policy to role-assignment policy.
My simple suggestion is to use "Rule Interpretation Policy" or
"Rule Interpretation Rule" in the case of rule interpretation
such as how to resolve conflicts (if occurred) and how to propagate
rules on authorization hierarchies (group hierarchy etc.)

Michiharu Kudo

---------------------- Forwarded by Michiharu Kudoh/Japan/IBM on 2001/10/25
13:22 ---------------------------

From: Michiharu Kudoh on 2001/10/25 10:55

To:   Tim Moses <tim.moses@entrust.com>@internet
cc:   "'XACML'" <xacml@lists.oasis-open.org>@internet
From: Michiharu Kudoh/Japan/IBM@IBMJP
Subject:  Re: [xacml] Glossary telecon Friday at 10:00 EDT  (Document link:
      Michiharu Kudoh)

Hi, Tim

Since I am not available on that date and time,
I will try to post some comments by e-mail.

Michiharu Kudo

From:     Tim Moses <tim.moses@entrust.com> on 2001/10/25 05:22

Please respond to Tim Moses <tim.moses@entrust.com>

To:   "'XACML'" <xacml@lists.oasis-open.org>
Subject:  [xacml] Glossary telecon Friday at 10:00 EDT

Colleagues - Here are the details of the telecon to discuss glossary.

North America:  613-688-3270 passcode: 2048#

The proposed glossary can referenced at ...


All the best.  Tim.

Tim Moses
Tel: 613.270.3183

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

Powered by eList eXpress LLC