[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Multiple Decison Request Proposal
Hi Hal, I think this looks good. I think it is a good idea to separate this functionality from the old multiple resource. I'm not sure if we need a separate document for it. A separate chapter in the existing profile might be good enough. We already have several modes of multiple requests there. I think the <Request> element should be called something else, and this could have its own schema. Maybe "<MultiRequest>"? We need to specify how this interacts with the old multirequest format in a PDP which implements both. It's quite simple really. The <MultiRequest> will be preprocessed by the PDP into multiple <xacml:Request>, and each such will be further processed to handle old style multiple requests. Each <xacml:Request> will evaluate into a single <xacml:Response>, which may contain multiple <xacml:Result> from the old multiple resource profile. Best regards, Erik Hal Lockhart wrote: > 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]