[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]