Hi Erik,
I see your point. How about if we constructed ListReference as follows:
Normal single element in category case:
<ListReference Category="cat1"/>
Multiple element in category case:
<ListReference Category="cat2">
<Attribute AttributeId="xxx" Issuer="yyy" DataType="datatype">
<AttributeValue>zzz</AttributeValue>
</Attribute>
</ListReference>
With this approach typical case would be just match Category.
Multi-case would be match Category and contained Attribute w value.
Then Attr would only be synthetic in the extreme case as described in:
http://lists.oasis-open.org/archives/xacml/200901/msg00049.html
Thanks,
Rich
Erik Rissanen wrote:
Hi
Rich and all,
This sounds good to me, except that I don't like the use of the
synthetic id as the reference in the decision list. This forces all
requests to contain synthetic ids, which I think are not needed in most
cases, and is also more difficult to parse for a pre-processor since
the id is more deeply nested.
Regards,
Erik
Rich.Levinson wrote:
Hi Erik, Hal, and TC,
There have been a lot of emails on this issue so far, but I think we
are at the point where all the ambiguities and potential missing pieces
have been accounted for, so I will try to summarize where I think the
proposal currently stands.
First of all here are some reference emails that have examples that
show different aspects of the proposed solution:
* example request with XPath (in Erik's most recent email (below))
which is purported to return multiple nodes (an example response
would be helpful to augment this:
o
http://lists.oasis-open.org/archives/xacml/200901/msg00053.html
* example request with decision lists (Hal's most recent email)
(ignore the CorrelationId, because as Erik showed, it will not
work w XPath)
o
http://lists.oasis-open.org/archives/xacml/200901/msg00051.html
* example request showing multiple <Attributes> elements
having
same @Category and using "synthetic attribute" with
"...multiple-request:unique-id" (would be useful to have
corresponding response showing returned "disambiguated"
<Attributes> elements
o
http://lists.oasis-open.org/archives/xacml/200901/msg00049.html
* example response showing 5 distinct results, not using synthetic
attribute, but using "...resource:resource-id" for Result
correlation. (This shows the important concept that not only is
the <Attribute> with the @IncludeInResult returned, but
also its
parent <Attributes> element with the @Category.)
o
http://lists.oasis-open.org/archives/xacml/200901/msg00045.html
* original example request w DecisionList and w follow-up minor
correction
o
http://lists.oasis-open.org/archives/xacml/200901/msg00015.html
o
http://lists.oasis-open.org/archives/xacml/200901/msg00035.html
Based on the analysis that has been done, I have a few recommendations
that, at least to me, appear to be important enough to itemize as
suggestions for the specifications.
For the 3.0 Core spec:
1. It became inferentially apparent that a fundamental "rule" is
that a Request context that is processed by the PDP must have at
most 1 <Attributes> element with a specific Category. I
recommend that this be explicitly stated in section 5.35 in the
description of the <Attributes> [One to Many] element. What
is
there now is not unambiguous in this regard, and I recommend it
be tightened up.
2. Similarly, I think explicit text should be in Section 5.37 for
the Category [Required] description. i.e. specify that while
multiple <Attributes> elements with the same Category are
allowed in the Request element, that for the purpose of making
an authorization decision, only one <Attributes> element
per
Category is allowed.
3. Section 5.39 under explanation of IncludeInResult [Default
false] I recommend that when included in Result the Attribute
will be parented by its <Attributes w @Category> element.
Also
if multiple <Attribute> elements within one Category are
tagged,
then they will share the parent.
4. Section 5.41 under explanation of <Attributes> element, I
recommend that it be explicitly stated that there will be one
<Attributes> element for each @Category in the Request that
contained an @IncludeInResult.
For the 3.0 Multi-Decision spec:
1. I recommend that at least for the multi-Attributes @Category
mechanism that a clear explanation be included that without
DecisionLists, that there is an inferential n-dimensional
cross-product applied, where n is the number of @Categories
that have multiple <Attributes> elements within the
Request.
So, for example if there are 3 Category attrs, say cat1, cat2,
cat3 that occur in multiple <Attributes> elements, for
example
let's say there are 4 <Attributes> elements w cat1, 4 with
cat2,
and 3 w cat3, then there will inferentially be 4x4x3 = 48
individual Requests generated to the PDP, each of which will
have a Result element in the Response. It would also be worth
noting that if there are additional single element Category
attrs, say cat4, cat5, and cat6, that the <Attributes>
element
for each of those Category attrs will be evaluated in all 48
decisions. i.e. all 48 decisions will be based on
cat1,cat2,cat3,cat4,cat5,cat6, where 4,5,6 remain constant thru
the process and 1,2,3 are incremented as if to visit every cell
in a 4x4x3 3-dimensional matrix in this particular example.
2. I recommend that the DecisionLists mechanism be introduced as an
augmentation to the n-dimesional matrix in 1 above. i.e. given
the 48 decisions above, I think that DecisionLists can be used
to pare down the list so that the full n-dimensional cross
product does not get evaluated. i.e. The DecisionLists would
override the inferential processing if they were present.
* For example, if we really didn't want the 4x4 portion
above but were really interested in 2 2x2 portions, there
could be 2 DecisionLists up front that contained the
following elements:
o
cat11,cat12,cat21,cat22,cat31,cat32,cat33,cat4,cat5,cat6
o
cat33,cat34,cat43,cat44,cat31,cat32,cat33,cat4,cat5,cat6
* Each of the above DecisionLists would produce 2x2x3 = 12
results for a total of 24 results.
* i.e. the suggestion is that the presence of DecisionLists
simply override the inferential multiple effect of the
<Attributes> elements themselves and transfer the
inferential effect to the multiple category instances w
same category to within each list.
* i.e. the presence of the DecisionLists would effectively
say: regard the actual <Attributes> elements as a
pool of
referencable entities and process the request as if
multiple Request elements had come in with
<Attributes>
elements listed in the DecisionList, and process
inferentially on that basis. Everything would be returned
in a single response.
3. The only lingering "annoyance" is that the DecisionLists address
the <Attributes> elements by the xml:id, whereas within the
inferential processing we need to reference for correlation
purposes based on an internal IncludeInResult attribute. This is
not a show-stopper of any sort, but it does appear that there
are 2 mechanisms effectively used to identify the same
<Attributes> element. A couple of considerations:
* It would seem that xml:id for <Attributes> elements
that
only had a single instance is more than is needed since
one could theoretically simply identify these single
instance elements by identifying their Category value.
* It seems that what's needed for the DecisionLists that are
going to use multiple <Attributes> elements with the
same
Category is something within the <Attributes> element
that
distinguishes it from the other <Attributes> elements
of
the same Category. This seems to be deja vu all over again
(sic) wrt the analysis that left us with the "synthetic
attributes" as the ultimate decider for those cases where
nothing else would work
http://lists.oasis-open.org/archives/xacml/200901/msg00049.html
* Therefore, I am tentatively suggesting that a usable
alternative to URI,xml:id might be @Category.value(index),
where "index" would be the value of a synthetic attribute
within the <Attributes @Category> element with
AttributeId="...multiple-request:unique-id".
I believe everything above, is essentially pretty much identifying what
has already been decided and putting it all in one place, at least wrt
3.0 Core spec, plus I think that comment 1 for multi-decision is simply
stating what has already been agreed, comment 2 is some clarification
on how DecisionLists could be viewed and used, and comment 3 admittedly
is something "new" to address what appears to me to be a lingering
"rough spot" in what has been decided so far.
Comments and suggestions are welcome.
Thanks,
Rich
Erik Rissanen wrote:
Hi Hal,
I just realized that the CorrelationId will not work, and we need the
IncludeInResult.
The existing 2.0 multiple resource profile defines a few more modes of
multiple requests than multiple <Resource> elements. For
instance, it is possible to specify multiple request in the form of an
xpath expression on the <ResourceContent>, where each node the
xpath matches will generate an individual request. Like this for
instance:
2 <Request
3 xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:os"
4 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
5 xmlns:md="http://www.medico.com/schemas/record"
6
xmlns:xacml-context="urn:oasis:names:tc:xacml:2.0:context:schema:os"
7
xsi:schemaLocation="urn:oasis:names:tc:xacml:2.0:context:schema:os
8 access_control-xacml-2.0-context-schema-os.xsd">
9 <Subject>
10 <Attribute
11
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
12
DataType="http://www.w3.org/2001/XMLSchema#string">
13 <AttributeValue>Julius
Hibbert</AttributeValue>
14 </Attribute>
15 </Subject>
16 <Resource>
17 <ResourceContent>
18 <md:record>
19 <md:patient_info>
20 <md:name>Bart Simpson</md:name>
21 <md:age>60</md:age>
22 <md:sex>male</md:sex>
23
<md:health_insurance>123456</md:health_insurance>
24 </md:patient_info>
25 <md:diagnosis_info>
26 <md:diagnosis>
27 <md:item type="primary">Gastric
Cancer</md:item>
28 <md:item type="secondary">Hyper
tension</md:item>
29 </md:diagnosis>
30 <md:pathological_diagnosis>
31 <md:diagnosis>
32 <md:item type="primary">Well
differentiated adeno carcinoma</md:item>
33 </md:diagnosis>
34 <md:date>2000-10-05</md:date>
35 <md:malignancy type="yes"/>
36 </md:pathological_diagnosis>
37 </md:diagnosis_info>
38 </md:record>
39 </ResourceContent>
40 <Attribute\r
41
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
42
DataType="http://www.w3.org/2001/XMLSchema#string">
43
<AttributeValue>*[local-name()='Resource'][namespace-uri()='urn:oasis:names:tc:xacml:2.0:context:schema:os']/*[local-name()='ResourceContent'][namespace-uri()='urn:oasis:names:tc:xacml:2.0:context:schema:os']/*[local-name()='record'][namespace-uri()='http://www.medico.com/schemas/record']/*[local-name()='patient_info'][namespace-uri()='http://www.medico.com/schemas/record']/*[self::*[local-name()='name'][namespace-uri()='http://www.medico.com/schemas/record']
or
self::*[local-name()='age'][namespace-uri()='http://www.medico.com/schemas/record']]/descendant-or-self::node()</AttributeValue>
44 </Attribute>
45 <Attribute
46
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:scope"
47
DataType="http://www.w3.org/2001/XMLSchema#string">
48
<AttributeValue>XPath-expression</AttributeValue>
49 </Attribute>
50 </Resource>
51 <Action>
52 <Attribute
53
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
54
DataType="http://www.w3.org/2001/XMLSchema#string">
55 <AttributeValue>read</AttributeValue>
56 </Attribute>
57 </Action><Environment/></Request>
From this request there will be multiple results, but there is only one
<Resource> element. Each result will contain a specific
ResourceId XML attribute for correlation purposes.
In the corresponding 3.0 multiple request, it will be necessary to use
the IncludeInResult since there are not multiple Attribute elements,
which could be used for correlation, even if they had a CorrelationId.
So I think we should drop the CorrelationId proposal, and if necessary,
people will have to use a synthetic XACML attribute for correlation.
Best regards,
Erik
Hal Lockhart wrote:
As of today's meeting I believe we are
down to deciding how to do correlation. The alternative previously
proposed is to use the IncludeInResponse mechanism. This may involve
submitting synthetic attributes, not referenced by policy, simply to
correlate requests and decisions.
The new idea (at least to me) is to move my previously proposed XML
Attribute - CorrelationID - to the <Attributes> element instead
of having it in the <DecisionList> element.
This seems clearer to me, but others should express their opinions. The
new scheme would look something like this:
<Request>
<DecisionLists>
<DecisionList>
<ListReference URI="Sub1"/>
<ListReference URI="Env"/>
<ListReference URI="Res1"/>
<ListReference URI="Act1"/>
</DecisionList>
<DecisionList>
<ListReference URI="Sub1"/>
<ListReference URI="Sub2"/>
<ListReference URI="Env"/>
<ListReference URI="Res2"/>
<ListReference URI="Act2"/>
</DecisionList>
<DecisionList>
<ListReference URI="Sub3"/>
<ListReference URI="Env"/>
<ListReference URI="Res1"/>
<ListReference URI="Act2"/>
</DecisionList>
<DecisionList ... >
...
</DecisionList>
</DecisionLists>
<Attributes Category="Access_Subject" XML:Id="Sub1"
CorrelationId="FirstSubject">
<Attribute>
...
</Attribute>
<Attribute>
...
</Attribute>
<Attribute>
...
</Attribute>
</Attributes>
<Attributes Category="Intemediary_Subject" XML:Id="Sub2"
CorrelationId="SecondSubject">
<Attribute>
...
</Attribute>
<Attribute>
...
</Attribute>
<Attribute>
...
</Attribute>
</Attributes>
<Attributes Category="Intemediary_Subject" XML:Id="Sub3"
CorrelationId="ThirdSubject">
<Attribute>
...
</Attribute>
<Attribute>
...
</Attribute>
<Attribute>
...
</Attribute>
</Attributes>
<Attributes Category="Environment" XML:Id="Env">
<Attribute>
...
</Attribute>
<Attribute>
...
</Attribute>
<Attribute>
...
</Attribute>
</Attributes>
<Attributes Category="Resource" XML:Id="Res1"
CorrelationId="FirstResource">
<Attribute>
...
</Attribute>
<Attribute>
...
</Attribute>
<Attribute>
...
</Attribute>
</Attributes>
<Attributes Category="Resource" XML:Id="Res2"
CorrelationId="Secondresource">
<Attribute>
...
</Attribute>
<Attribute>
...
</Attribute>
<Attribute>
...
</Attribute>
</Attributes>
<Attributes Category="Action" XML:Id="Act1"
CorrelationId="FirstAction">
<Attribute>
...
</Attribute>
<Attribute>
...
</Attribute>
<Attribute>
...
</Attribute>
</Attributes>
<Attributes Category="Action" XML:Id="Act2"
CorrelationId="SecondAction">
<Attribute>
...
</Attribute>
<Attribute>
...
</Attribute>
<Attribute>
...
</Attribute>
</Attributes>
...
</Request>
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
