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 of Focus Group Meeting 25 March 2004


Attendees:
Anne Anderson
Tim Moses
Simon Godik
Polar Humenn

1. Updated Work Item Index

Tim needs an updated Work Item Index so he can reference the
e-mail containing it in his next draft.  The draft would
reflect the state of items in that list.

Anne may be able to issue update today, but will do by Tuesday
otherwise.

2. Deadline for action items for XACML 2.0

The group decided that 12 April 2004 would let Tim get a new 2.0
draft out prior to the 28-29 April Face-to-Face.

3. WI#10. Parameters for Combining Algorithms

Polar: do we want to be able to distinguish more than one
parameter per rule?  Current proposal supports only one (the one
could be multi-valued).  I.e. should we support a sequence of
parameters per rule?

Polar: Do we want to bring the parameters into the type system?
If so, we could allow references.  Currently, if contains
references to variables, combining algorithm would have no way to
get those unless the PDP evaluated the expression and checked
type correctness prior to passing the result to the combining
algorithm.  Combining algorithm would have to be written with/as
part of the PDP to have access to the context otherwise.  If we
now went with a parameter having "lax" content, could we later be
backwards compatible if we add type information?

Simon: probably not.

Simon: each combining algorithm would develop its own schema for
its parameters, so type would no longer be "lax" at that point.

Polar: combining algorithm itself would have to know how to
evaluate that completely, since PDP will not know the schema
semantics.  PDP won't know types to associate with elements.

Tim: seems wrong for the combining algorithm to be reasoning
about those kinds of things.

Polar: if parameters are typed, then PDP can evaluate.

Tim: I don't quite like these open content models.  It is the
PDP's job to serve up an "integer".

Polar: we have all the machinery in the PDP for evaluating
expressions.  If you need something more complex, you can define
a new DataType.

Tim: So adding types does not add complexity?

Polar: I think so.  Simpler on implementation of combining
algorithm.

Simon: Look at Michiharu's example.  You would have
<AttributeValue>...</AttributeValue>.  More use cases would be
helpful.

Polar: schema change is easy.  Change "lax" content reference to
"XACML expression", just like what goes into an "Apply".

Simon: "Apply" content is a sequence of expressions.

Tim: immediate action on this is in Simon's court.

Simon: Could Polar work up a use case?

Polar: Yes, but may take a while.

4. Organization of schema files

Tim asked about how schema files should be organized.  Currently
follow class structure.  Would alphabetical be more useful?

No preference, so Tim will leave as is.

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