Re: [xacml] Proposed resolution to PM-1-02: Post-Conditions

[Michiharu Kudoh <KUDO@jp.ibm.com>]

Hi, Anne

>Could you clarify what this issue is?

I have one question since you are a champion w.r.t. the typical policy
combiner algorithm. Are you considering another policy combiners other than
GLOBAL-DENY, such as Take-first-decision and Evaluate-all for inclusion in
the spec? I mean that Take-first-decision takes the first Permit or Deny
decision the specified order. Evaluate-all means that it evaluates all the
rule (or policy). I thought it might be worth including in the spec. This
is what I meant at that time.

I agree to your second comment. I rephrased the resolution:
---------------------------------
ISSUE: PM-1-02: Post-Conditions

We use the term "obligation" to mean what we have previously been calling
"post condition". The issue of the term is addressed in  PM-1-03.

The obligation is an annotation that MAY be specified in a policyStatement
and/or policyCombinationStatement that should be returned in conjunction
with an authorization decision meaning that the obligations(s) SHOULD be
executed by the PEP. The obligation is specified using URI reference with
optional arguments. The processing rules of the obligation is defined by
ruleSet combiner or policySet combiner. XACML provides a couple of combiner
examples that deals with obligations in the informative section. The actual
meaning of each obligation differs from application. It also depends on the
configuration of the PEP and/or PDP. If the PEP does not understand an
obligation, the PEP should deny access. The PDP just collects obligations.

(from F2F#4 minutes)
The set of obligations returned by each level of evaluation includes only
those obligations associated with the effect element being returned by the
given level of evaluation.  For example, a policy set may include some
policies that return Permit and other policies that return Deny for a given
request evaluation. If the policy combiner returns a result of Permit, then
only those obligations associated with the policies that returned Permit
are returned to the next higher level of evaluation.  If the PDP's
evaluation is viewed as a tree of policyCombinationStatements,
policyStatements, and rules, each of which returns "Permit" or "Deny", then
the set of obligations returned by the PDP will include only the
obligations associated paths where the effect at each level of evaluation
is the same as the effect being returned by the PDP.

Best
Michiharu Kudo

IBM Tokyo Research Laboratory, Internet Technology
Tel. +81 (46) 215-4642   Fax +81 (46) 273-7428



From: Anne Anderson <Anne.Anderson@Sun.com> on 2002/03/23 00:00

Please respond to Anne Anderson <Anne.Anderson@Sun.com>

To:   Michiharu Kudoh/Japan/IBM@IBMJP
cc:   XACML TC <xacml@lists.oasis-open.org>
Subject:  Re: [xacml] Proposed resolution to PM-1-02: Post-Conditions



On 22 March, Michiharu Kudoh writes: [xacml] Proposed resolution to
 PM-1-02: Post-Conditions
 > agreements. Besides this resolution, I would like to raise a new issue
 > "Combiner example for obligations".

Could you clarify what this issue is?

 > ISSUE: PM-1-02: Post-Conditions
 >
 > We use the term "obligation" to mean what we have previously been
 calling
 > "post condition". The issue of the term is addressed in  PM-1-03.

Let's also close PM-1-03.

 > The obligation is an annotation that MAY be specified in a
 policyStatement
 > and/or policyCombinationStatement that should be returned in conjunction
 > with access meaning that the obligation(s) should be executed in
 > conjunction with access. The obligation is specified using URI
 > reference

I think this resolution is fine except for one thing.  We can
return obligations on "deny" as well as on "permit, so the
resolution should probably say "should be returned in conjunction
with an access decision meaning that the obligations(s) SHOULD be
    ^^^^^^^^^^^^^^^^^^

executed by the PEP.
        ^^^^^^^^^^

 > with optional arguments. The processing rules of the obligation is
 defined
 > by ruleSet combiner or policySet combiner. XACML provides a couple of
 > combiner examples that deals with obligations in the informative
 section.
 > The actual meaning of each obligation differs from application. It also
 > depends on the configuration of the PEP and/or PDP. If the PEP does not
 > understand an obligation, the PEP should deny access. The PDP just
 collects
 > obligations.
 >
 > (from F2F#4 minutes)
 > The set of obligations returned by each level of evaluation includes
 only
 > those obligations associated with the effect element being returned by
 the
 > given level of evaluation.  For example, a policy set may include some
 > policies that return Permit and other policies that return Deny for a
 given
 > request evaluation. If the policy combiner returns a result of Permit,
 then
 > only those obligations associated with the policies that returned Permit
 > are returned to the next higher level of evaluation.  If the PDP's
 > evaluation is viewed as a tree of policyCombinationStatements,
 > policyStatements, and rules, each of which returns "Permit" or "Deny",
 then
 > the set of obligations returned by the PDP will include only the
 > obligations associated paths where the effect at each level of
 evaluation
 > is the same as the effect being returned by the PDP.
 >
 > Michiharu Kudo
 >
 > IBM Tokyo Research Laboratory, Internet Technology
 > Tel. +81 (46) 215-4642   Fax +81 (46) 273-7428
 >
 >
 >
 > ----------------------------------------------------------------
 > To subscribe or unsubscribe from this elist use the subscription
 > manager: <http://lists.oasis-open.org/ob/adm.pl>
 >

--
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692