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] Minutes from Focus Group Meeting 29 Jan 2004






>4. WI#18 Obligations in Rules
>
>Polar: issue with combinators.  Formal semantics document points
>out an existing issue.  Have to know there are obligations
>attached to rules; have to evaluate all policies.  Polar not
>happy with text that says "only obligations associated with rules
>that are actually evaluated are used" this because it is
>non-deterministic.

I think that evaluation of policy (or policy set) with obligations
is non-deterministic only if the policy uses either deny-overrides
or permit-overrides. Policy with Ordered version, first-applicable,
or only-one-applicable does not cause this non-deterministic
problem. If you are saying that "the spec should give more text
about this", then I agree.

>Another problem with mixing Policies and PolicySets: may have
>only a decision from a subordinate policy.  If eval PS before
>evaluating contained PS, if combinator changes its decision, then
>it ditches all obligations that may have been emitted by
>subordinate policies.  If writing a policy in isolation and
>expecting Oblig 1 to be true because effect is Permit, but these
>are thrown away because enclosing policyset returns Deny, then
>these are thrown away.
>Semantics in specification are consistent, but the behavior is
>not actually what policy writers may expect.

As far as I understand, the case you wrote is also applicable to
cases that has no obligations. (e.g. one of subordinate
policy decision is permit but it can be turned over if a higher
policy decision denies it). If you think throwing returned
obligations away is the problem, one of the solution would be
that the system generates an exception when the subordinate
policy that includes obligation is reversed.

>Tim would like to see a convincing use case.

I think this extension is for economy. One of the example:

Rule1: Silver member can access contents A at AM, provided $1
are charged per access.
Rule2: Silver member can access contents A at PM, provided $1.5
are charged per access.

<Policy algid="deny-overrides">
  <Target>Silver member</Target>
  <Rule effect="permit">
    <Condition>AM</Condition>
    <Obligation>payment $1</Obligation>
  </Rule>
  <Rule effect="permit">
    <Condition>PM</Condition>
    <Obligation>payment $1.5</Obligation>
  </Rule>
</Policy>

The same semantics can be specified using policy instead
of rules.

<PolicySet algid="deny-overrides">
  <Target>Silver member</Target>
  <Policy>
    <Rule effect="permit">
      <Condition>AM</Condition>
    </Rule>
    <Obligation>payment $1</Obligation>
  </Policy>
  <Policy
    <Rule effect="permit">
      <Condition>PM</Condition>
    </Rule>
    <Obligation>payment $1.5</Obligation>
  </Policy>
</PolicySet>

In this case, each policy includes only one rule
just for specifying a condition.

Best,
Michiharu



                                                                           
             Anne Anderson                                                 
             <Anne.Anderson@Su                                             
             n.COM>                                                     To 
                                       XACML TC                            
             2004/01/30 01:21          <xacml@lists.oasis-open.org>        
                                                                        cc 
                                                                           
             Please respond to                                     Subject 
               Anne.Anderson           [xacml] Minutes from Focus Group    
                                       Meeting 29 Jan 2004                 
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




XACML Focus Group Meeting
29 January 2004

Present:
 Anne Anderson (scribe)
 Simon Godik
 Tim Moses
 Polar Humenn
 Frank Siebenlist

Agenda: Discuss open work items and see if group can produce
recommendations on how to close them.

1. WI#58 Standard hierarchy schemas

Frank says OGSI describes "service data"; resource properties
document includes schemas for hierarchies; see
http://www.globus.org/wsrs, although Frank will send out a more
precise link.  Things have changed since Frank last looked at it.

2. WI#7 ConditionReference

Michiharu's current proposal is at:
http://lists.oasis-open.org/archives/xacml/200401/msg00035.html

Modifications to the policy schema are:
  + Create VariableDef element definition
  + Create VariableDef reference below PolicyType
  + Create VariableRef definition
  + Create VariableRef reference in ApplyCoreType
  + Modify Condition and ApplyType definition
Polar not entirely happy about ApplyCoreType, but not sure how to
fix it.  VariableDef should also be able to be the contents of an
ApplyCoreType, for example having a VariableDef that is the value
"true".  Simon agrees.  Possible: make VariableDefType a choice.

ACTION: Simon will post modified detailed proposal by Monday 2
Feb 2004, along with some text about how it should be used.  Tim
will put edited form into Draft 6.

3. WI#13 Optional Target Elements

This is being done for economy and readability; it would not be
backwards compatible.  Polar is happy with the optionality of
Subjects, Resources, Actions, [Environments] - thinks it is
actually semantically more consistent.  Simon prefers leaving it,
but does not object if others want it.  Polar notes that
<Subjects></Subjects> is false.  <Subjects> is modelled as a
disjunctive sequence - absence of any elements is an edge case.

ACTION: put Polar's note about <Subjects></Subjects> being false.

4. WI#18 Obligations in Rules

Polar: issue with combinators.  Formal semantics document points
out an existing issue.  Have to know there are obligations
attached to rules; have to evaluate all policies.  Polar not
happy with text that says "only obligations associated with rules
that are actually evaluated are used" this because it is
non-deterministic.

Another problem with mixing Policies and PolicySets: may have
only a decision from a subordinate policy.  If eval PS before
evaluating contained PS, if combinator changes its decision, then
it ditches all obligations that may have been emitted by
subordinate policies.  If writing a policy in isolation and
expecting Oblig 1 to be true because effect is Permit, but these
are thrown away because enclosing policyset returns Deny, then
these are thrown away.

Semantics in specification are consistent, but the behavior is
not actually what policy writers may expect.

Tim would like to see a convincing use case.

ACTION: Michiharu to present a convincing use case.

ACTION: Polar will try to develop a different approach based on
the formal semantics document.  That approach would require all
policies to be evaluated [which may have a high cost in a
distributed environment].

5. WI#11 XACML Extension Points

Discussed Simon's proposal in
http://lists.oasis-open.org/archives/xacml/200401/msg00046.html:
Allow element of type xacml:ParametersType as an optional child
of xacml:PolicySet, xacml:Policy, xacml:Rule, and
xacml:Obligations elements. If xacml:Parameters element is not
empty, pdp must be able to process all xacml:Parameter
elements. (Alternatives possible: 1 - pdp may ignore properties
it does not understand, 2 - introduce MustUnderstand attribute to
the xacml:Parameter element).

Has to be pretty generic, but would like to prevent abuse.  Simon
has use case, Michiharu has use case (parameters to combining
algorithms).

"MustUnderstand" attribute should have to go into Parameters, not
Parameter.  Parameters is a list, not a set.

Question about how many instances of Parameters can be in an
instance of the schema.

Question about using Parameters for Frank's policy issuer,
location information, etc. - might need multiple instances of
Parameters, each with an identifier to say what is contained:
parameters for combining algorithms, policy issuer identification
information, attribute location hints information, etc.

Polar thinks parameters should not be contained inside the
PolicySet, Policy, or Rule to which they apply, but should be
outside, in parallel, attached by the composer of the enclosing
policy[set].  Otherwise, there is no control over where the
policy, policyset, etc. is used, and weighting parameter (e.g.)
might not be appropriate in new context.

Polar's alternative: replicate the structure in the combining
algorithm, and attach parameters to elements there:
e.g. "weighting associated with first policy you encounter is 3,
weighting associated with second policy you encounter is 4", etc.
Eliminates problem of PDP not understanding parameters: they
would only occur inside the combining algorithm that does know
how to use them.

ACTION: Simon to produce modified proposal for standard way to
include Parameters in the element that has the combining
algorithm that uses them, not in the elements enclosed by the
element that uses them.

ACTION: Michiharu to study whether Polar/Simon's alternative
satisfies his use case.  If not, publish use case with
explanation for why something else is needed.

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


To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php
.





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