OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml] Multiple Decison Request Proposal


Hi again Rich,

There is one more problem. Not all XACML data types have a defined 
equality function. So it wouldn't work in all cases.

Regards,
Erik

Erik Rissanen wrote:
> Hi Rich,
>
> I still think that a ID reference is simpler than digging up the 
> datatype, attribute id and possibly issues, and going through all the 
> attributes in the request section looking for nested elements 
> containing matches for all two/three values.
>
> Also it's more verbose, making it more difficult to read by humans 
> (for debugging, development, audit, etc) and means less data to move 
> around.
>
> Regards,
> erik
>
> Rich.Levinson wrote:
>> Hi Erik,
>>
>> I see your point. How about if we constructed ListReference as follows:
>>
>>    1. Normal single element in category case:
>>           * <ListReference Category="cat1"/>
>>    2. 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
>
>
> ---------------------------------------------------------------------
> 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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]