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

XACML Focus Group Meeting
29 January 2004

 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:

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

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

"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

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