Hi Hal and Erik,
I agree w the overall thrust of this profile effort and I think Hal's
original suggestion of having a prefix element, <DecisionLists>,
conceptually is not inconsistent with the existing multi-resource
profile, because in theory, I believe that the existing multi-resource
profile violates the notion of a "simple core schema", because it
already requires external pre-processing of the request in order to
only pass one resource at a time to the PDP.
This was an issue that caused me some problems understanding exactly
what the "core schema" was, however, the discussion earlier with Erik,
I think clarified that situation better, namely that each Attributes
element in a "regular XACML request" must have a different Category;
i.e. in a single XACML request to be processed by the rules in the core
spec, there may not be more than one <Attributes> element with
the same Attributes@Category xml attribute.
As a result, this forces even the existing multi-resource profile into
a "pre-processor" unspecified domain.
The Subject Inconsistencies issue was related to this in that extending
the multi-profile to include Subject as well as Action, Environment,
and Resource, was problematic because Subject inherently had multiple
Categories already, and for 2.0 that was ok, because there was no
multi-subject and these subjects never got broken up. However, the 3.0
multi-profile breaks that, and as was discussed, maybe it's not all
that bad if people understand it and choose how they want to do this.
However, Hal's proposal, can easily include cross-products of arbitrary
complexity by simply including multiple <ListReference> elements
that point to <Attributes> elements with the same @Category. For
example:
<DecisionList CorrelationId="FirstDecision">
<ListReference URI="Sub1"/>
<ListReference URI="Env"/>
<ListReference URI="Res1"/>
<ListReference URI="Res2"/>
<ActionReference URI="Act1"/>
<ActionReference URI="Act2"/>
</DecisionList>
would result in 4 requests issued to the pdp for (R1,A1), (R1,A2),
(R2,A1), (R2,A2).
This approach would contain everything for existing cross-product 2.0
and 3.0 profiles, as well as more specific pruning of the request lists
w singleton <DecisionList> elements.
Thanks,
Rich
Hal Lockhart wrote:
I think the <Request> element should be called something else, and this
could have its own schema. Maybe "<MultiRequest>"?
<Request> is the existing outer element of a Request context. My notion
is that <DecisionsLists> is an optional element which appears prior to the
first <Attributes> element.
Yes, but I thought that it would perhaps be better to not put this
boxcarring stuff into the core schema, but in it's own schema. I think
it would be neater if we have a "simple" core schema which defines the
processing model. Additional preprocessing and transport formats would
go into another schemas.
But I don't feel too strongly about it, and importing schema files can
be a bit of an annoyance to work with given the current state of XML
parsers.
First of all as I have said several times, I only see this feature as being important when a remote PDP is used. (In fact I don't think an imbedded PDP should be using an XML Request Context at all.)
Given that, I have no strong preference for how we deal with the schemas. I would like to hear from implementers on this issue.
Hal
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php