Re: [xacml] Minutes for New Orleans F2F

[Seth Proctor <Seth.Proctor@Sun.COM>]

Bill - Thanks for the detailed minutes!

All - Since I wasn't at the f2f, I've got a couple questions/comments.

> Section 7.2: For purposes of this specification, in relation to a 
> particular Request, a given PDP is defined as a Policy Combining 
> Algorithm and a set of policies and/or policy sets. The PDP SHALL 
> return a Response as if it evaluates a single policy set consisting of
> this Policy Combining Algorithm and the set of policies and policy 
> sets.

It sounds like this text was agreed on at the f2f. I want to go on
record saying that I think this is just as confusing as what is
currently in the text, and I believe it will cause confusion amongst
people trying to work with it. Again, I'll state my preference for the
text that Anne proposed, and in fact...

> We would move the remaining existing text in 7.2 that describes
> various "MAY" models - collecting applicable policies in response to 
> the contents of the Request into a PolicySet template that has a 
> pre-defined PolicyCombingAlgorithm, etc. - into Sections 2-4.

...suggest that Anne's text be used in this non-normative section, since
I think it's much clearer than what's currently in 7.2. Now I'll be
quiet :)

> [discussion of resource hierarchies and a new proposal from Daniel]

I've been working with a small number of people who are using
hierarchical resources in XACML, so I thought I'd provide a little
information. The first point (obviously) is that yes, people are using
this feature in XACML 1.x systems.

In XACML 1.x, hierarchical resources are recognized by a scope
attribute, but there is no discussion of using the ResourceHierarchy, so
few people have thought to do this. Those that have like the idea, but
only for fairly small/simple hierarchies, since there are serious
performance costs involved. If we add support for specifying the
resource hiearchy in the ResourceContent, which seems like a reasonable
idea to me, I think we should seriosuly consider making this optional,
since there are existing users who have custom logic to resolve
hierarchical resources effeciently.

I think that Daniel's proposal is also pretty reasonable. In 1.x, a PEP
sends a request containing a scope attribute, and the context handler is
responsible for resolving the hierarchical resource identifiers and
passing on one request for each resource (effectively) to the PDP. What
Daniel has suggested, if I understand it correctly, is a way for the PEP
to do this resource resolution, and then pass that en masse to the
context handler, which again passes one request for each resource to the
PDP. This new feature is consistent with the current evaluation model.

Daniel has also suggested an Attribute that gives a resource's
ancestors. This is a separate idea, but one that strikes me as useful.
It would be more useful if you could talk about specific structure for
each path to the resource, but that may require too much structure and
may be too compute-intensive. Regardless of what we decide with regard
to hierarchical resources, I think that this new attribute identifier
makes sense.

> [Frank] presented his proposal for distributed administration. After
> several hours of discussion there weren\222t any immediate objections
> to pursuing the general model further.

Frank, will you provide a writeup/draft that describes your proposal?
Also, the minutes suggest that nothing in this conversation is slated
for inclusion in XACML 2.0. Is that correct?

> [Simon] Proposed that all time values referenced in XACML must be in
> the Canonical format defined by XML Schema.

Which time values are we talking about here? How is this not covered by
the proposal I provided for handling time values? (just want to make
sure I understand what this covers)

> WI 52 \226 Section on differences between XACML v1.1 and v2.0
> [...]
> * Semantics of missing components have changed

What are "missing components"? And in case the answer to that question
doesn't make it obvious to me, how have they changed?


seth