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
