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:
- example request with decision lists (Hal's most recent email)
(ignore the CorrelationId, because as Erik showed, it will not work w
XPath)
- 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
- 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.)
- original example request w DecisionList and w follow-up minor
correction
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:
- 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.
- 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.
- 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.
- 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:
- 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.
- 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:
- cat11,cat12,cat21,cat22,cat31,cat32,cat33,cat4,cat5,cat6
- 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.
- 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:
497988C9.3060000@axiomatics.com" type="cite">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
|