MHonArc v2.5.2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: Re: [xacml] OASIS Standard 1.0
Hi,
>> except for the last one from Satoshi on Obligations.
I don't have a strong opinion about whether my comments on obligations
should be incorporated into the final open standard.
From my implementation perspective,
let me summarize unclear points related to obligations.
I have three points which I think unclear.
I'd like to ask the TC members to discuss them to make a decision.
-----------------------------------------------------
(1) In the first place, rules, policies, and policy sets are ordered or
unordered???
The FirstApplicable algorithm requires that they are ordered
as Appendix C.3 explicitly says so. This is okay with me.
On the other hand, it seems to me that
the spec assumes that the order is not significant in other predefined
algorithms.
So it seems to me that the XACML specification basically assumes that
they are unordered.
However, this is okay only when no obligations are specified in policies
and policy sets.
In other words, if policies and policy sets have obligations then
the order of policies and policy sets COULD be significant in the
DenyOverides and Permit Overrides algorithm.
(See below for the reason)
At the same time, I agree that the order is not significant in case that
there is no obligation specified.
I suggest that the spec explicitly says that whether they are ordered or
not is up to a particular
combining algorithm and the existence of obligations.
-----------------------------------------------------
(2) Which obligations should be returned?
As I noted before,
in case of rule combining, there is no unclear point to me.
in case of OnlyOneApplicable policy combining, there is no unclear point to
me.
in case of FirstApplicable policy combining, there is no unclear point to
me.
There are unclear points in the DenyOverrides and PermitOverries policy
combining.
I refer to my previous mail below.
>> Deny-overrides:
>> ---------------
>> Consider a policy set using the deny-overrides policy comb alg.
>> Assume that the policy set has two obligation sets OP and OD for Permit
and
>> Deny, respectively
>> Assume that the policy set has two policies P1 and P2 with different
>> obligation sets O1 and O2, respectively.
>> Assume that O1 consists of OP1 and OD1 for Permit and Deny.
>> Assume that O2 consists of OP2 and OD2 for Permit and Deny.
>> Q2.1.1.
>> Assume that the two policies P1 and P2 are evaluated to Permit.
>> Should we return both OP1 and OP2, or only one of them (in addition to
OP) ?
"both OP1 and OP2" seems to be reasonable
because the two policies P1 and P2 are actually evaluated.
>> Q2.1.2
>> Assume that the two policies P1 and P2 are evaluated to Deny.
>> Should we return both OD1 and OD2, or only one of them (in addition to
OD) ?
We have two options.
(A) Return both OD1 and OD2.
In this case, the order of policies is not significant.
(B) Return only one of them.
In this case, the order of policies is significant.
If P1 is first evaluated, OP1 is returned, and
If P2 is first evaluated, OP2 is returned.
In general, when combining multiple policies by DenyOverrides
we have two options.
(A)Symmetric:
In case that the result is Permit:
This means that there is no policy that is evaluated to Deny and
there is at least one policy that is evaluated to Permit.
We collect and return all the obligations specified in all the policies
that are evaluated to Permit.
In case that the result is Deny:
This means that there is at least one policy that is evaluated to
Permit.
We collect and return all the obligations specified in all the policies
that are evaluated to Deny.
It is important to note that the order of policies is NOT significant in
this option.
This option is a symmetric algorithm because all the obligations are
collected
in both cases: Permit and Deny.
(B)Asymmetric:
In case that the result is Permit:
The same as the option (A).
In case that the result is Deny:
This means that there is at least one policy that is evaluated to
Permit.
We return the obligations specified in the policy that is first
evaluated to Deny.
We do not collect all the obligations specified in all the policies
that are
evaluated to Deny.
It is important to note that the order of policies is significant in this
option.
This option is an asymmetric algorithm because we don't collect obligations
in case of Deny.
I suggest that we add the explanation about which option should be
implemented
to the description of DenyOverrides and PermitOverrides in Appendix C.
I think the how to handle obligations is basically dependent
on a particular combining algorithm.
>> 2.2 Permit-overrides:
>> -----------------
>> I have the same two questions.
We have the same two options.
>> 2.3 First-applicable:
>> ----------------
>> Consider a policy set, which is the same as the above policy except that
>> it uses the first-applicable policy comb alg.
>>
>> Q2.3.1.
>> Assume that P1 is the first applicable policy that is evaluated to
Permit,
>> and that P2 is also evaluated to Permit.
>> Should we return both OP1 and OP2, or only OP1 (in addition to OP)?
"Only OP1" is okay with me because the policies are ordered in this case.
>> Q2.3.2.
>> I have the same quetion in case of Deny.
>> Should we return both OD1 and OD2, or only OD1 (in addition to OD)?
"Only OD1" is okay with me because the policies are ordered in this case.
-----------------------------------------------------
(3) Obligations are ordered?
Is
<Result>
<Obligation1>
<Obligation2>
</Result>
equivalent to
<Result>
<Obligation2>
<Obligation1>
</Result>
?
When evaluating a policy set, we may have to collect obligations from
multiple child policies.
If obligations are ordered, we must take care of the order. However, no
description about this issue
is found in the current XACML spec.
From my implementation perspective, if obligations are unordered then it's
easier to implement.
I think that, in general, obligations may be ordered.
However, they should be unordered in the predefined
combining algorithms from the implementation perspective.
I suggest that the XACML spec explicitly says that "obligations are
unordered" in the
description of the predefined combining algorithms (Appendix C).
Satoshi Hada
IBM Tokyo Research Laboratory
mailto:satoshih@jp.ibm.com
Tim Moses
<tim.moses@entrus To: "'XACML'" <xacml@lists.oasis-open.org>
t.com> cc:
Subject: [xacml] OASIS Standard 1.0
2003/02/04 07:26
Colleagues - Here is a draft of the XACML OASIS Standard Version 1.0,
incorporating the errata.� I also attach the list of errata.� I have
incorporated all the errata, except for the last one from Satoshi on
Obligations.� I have added the minOccurs="0" to the schema of
AttributeAssignment.� So the xsd file will have to be changed accordingly.
Naturally, any of these revisions can be "backed out" following our
discussion on Thursday.� I suggest that Bill should NOT produce the pdf
version until after Thursday's discussion.� All the best.� Tim.
-----------------------------------------------------------------
Tim Moses
613.270.3183
#### errata.doc has been removed from this note on February 05 2003 by
Satoshi Hada
#### os-xacml-specification-01.doc has been removed from this note on
February 05 2003 by Satoshi Hada
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC