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


Rich's recent comment (which I agree with) drew my attention to a mistake I made in my original message.

It was my intention that all the elements within <DecisionList> be the same, i.e. <ListReference>. Because of an editing error, one of them is <ActionReference> in the example.

Hal

> -----Original Message-----
> From: Hal Lockhart [mailto:hal.lockhart@oracle.com]
> Sent: Wednesday, January 14, 2009 1:12 AM
> To: xacml@lists.oasis-open.org
> Subject: [xacml] Multiple Decison Request Proposal
> 
> Last Thursday I promised to propose a scheme asking for multiple decisions
> in a single request. It was agreed that a request could specify arbitrary
> combinations of attribute categories (with no duplicates), but that the
> actual attribute values would only be specified once. The scheme would not
> require the entire cross product of all combinations to be used, but
> rather specific combinations could be specified.
> 
> After thinking about it for a bit, I concluded the following.
> 
> 1. I would propose a prefix of lists of items to be used in decisions as
> we previously discussed. This list uses references to XML Id Attributes to
> indicate which set of attributes to use.
> 
> 2. Since all categories could be specified (not just Resource and Action),
> it would be too confusing to allow for the cross product of the duplicate
> category types in each list to be specified. Instead I am proposing lists
> of exactly the attribute category values from which a virtual request
> context for each decision is constructed.
> 
> 3. The prior scheme of echoing back selected attribute values to correlate
> requests and responses would become too cumbersome and potentially
> ambiguous. Instead, I am proposing the an arbitrary string label on each
> decision list (specifically an XML attribute called CorrelationId) be used
> for this purpose.
> 
> 4. It seems to me that it might be a good idea to retain the Multi-
> Resource Profile in much the same form as in 2.0 and define a totally new
> Multi-Decision Profile using this scheme.
> 
> Here is roughly how this new style of request would look.
> 
> 
> <Request>
> 
>   <DecisionLists>
> 
>     <DecisionList CorrelationId="FirstDecision">
> 
>         <ListReference URI="Sub1"/>
> 
>         <ListReference URI="Env"/>
> 
>         <ListReference URI="Res1"/>
> 
>         <ActionReference URI="Act1"/>
> 
> 
>     </DecisionList>
> 
> 
>     <DecisionList CorrelationId="SecondDecision">
> 
>         <ListReference URI="Sub1"/>
> 
>         <ListReference URI="Sub2"/>
> 
>         <ListReference URI="Env"/>
> 
>         <ListReference URI="Res2"/>
> 
>         <ListReference URI="Act2"/>
> 
>     </DecisionList>
> 
> 
>     <DecisionList CorrelationId="ThirdDecision">
> 
>         <ListReference URI="Sub3"/>
> 
>         <ListReference URI="Env"/>
> 
>         <ListReference URI="Res1"/>
> 
>         <ListReference URI="Act2"/>
> 
>     </DecisionList>
> 
> 
>     <DecisionList ... >
>     ...
> 
>     </DecisionList>
> 
> 
>   </DecisionLists>
> 
> 
>     <Attributes Category="Access_Subject" XML:Id="Sub1">
> 
>       <Attribute>
>       ...
>       </Attribute>
> 
>       <Attribute>
>       ...
>       </Attribute>
> 
>       <Attribute>
>       ...
>       </Attribute>
> 
>     </Attributes>
> 
>     <Attributes Category="Intemediary_Subject" XML:Id="Sub2">
> 
>       <Attribute>
>       ...
>       </Attribute>
> 
>       <Attribute>
>       ...
>       </Attribute>
> 
>       <Attribute>
>       ...
>       </Attribute>
> 
>     </Attributes>
> 
> 
>     <Attributes Category="Intemediary_Subject" XML:Id="Sub3">
> 
>       <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">
> 
>       <Attribute>
>       ...
>       </Attribute>
> 
>       <Attribute>
>       ...
>       </Attribute>
> 
>       <Attribute>
>       ...
>       </Attribute>
> 
>     </Attributes>
> 
> 
>     <Attributes Category="Resource" XML:Id="Res2">
> 
>       <Attribute>
>       ...
>       </Attribute>
> 
>       <Attribute>
>       ...
>       </Attribute>
> 
>       <Attribute>
>       ...
>       </Attribute>
> 
>     </Attributes>
> 
>     <Attributes Category="Action" XML:Id="Act1">
> 
>       <Attribute>
>       ...
>       </Attribute>
> 
>       <Attribute>
>       ...
>       </Attribute>
> 
>       <Attribute>
>       ...
>       </Attribute>
> 
>     </Attributes>
> 
>     <Attributes Category="Action" XML:Id="Act2">
> 
>       <Attribute>
>       ...
>       </Attribute>
> 
>       <Attribute>
>       ...
>       </Attribute>
> 
>       <Attribute>
>       ...
>       </Attribute>
> 
>     </Attributes>
> 
> 
> ...
> 
> 
> </Request>
> 
> Let's discuss this on the call and then I can proceed to define Schema and
> text.
> 
> 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
> 



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