[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Request for enhanced boxcarring (multiple resource and actionrequest) support
Hi Erik, I think supporting multiple XACML request per remote call (via whatever protocol) is valuable, and may prove to be easier than modifying the core request schema. I also think it's about time the XACML TC provided our own transport binding, independent of the complexity of a SAML-based transport. A simple XACML <Request> over SOAP, with a reference WSDL, would suffice. Regards, Craig From: Erik Rissanen <erik@axiomatics.com> To: Craig Forster/Australia/IBM@IBMAU Cc: "hal.lockhart@oracle.com" <hal.lockhart@oracle.com>, "xacml@lists.oasis-open.org" <xacml@lists.oasis-open.org> Date: 04/11/2008 10:42 AM Subject: Re: [xacml] Request for enhanced boxcarring (multiple resource and action request) support Hi All, What kind of changes to the core schema would be needed? From the examples you post Hal, it sounds a bit like it's just a number of multiple request requests of the kind we already have today. If so, it would be simpler to modify the transport format to allow for multiple request contexts. Regards, Erik Craig Forster wrote: > Hi Hal, > > I think any enhancement of this nature should be part of the core > specification, not part of a transport binding. > > Regards, > Craig > > > > > From: "Hal Lockhart" <hal.lockhart@oracle.com> > > To: "xacml@lists.oasis-open.org" <xacml@lists.oasis-open.org> > > Date: 04/11/2008 09:42 AM > > Subject: [xacml] Request for enhanced boxcarring (multiple resource and action request) support > > > > > > > We have recently identified a requirement to be able to specify not just a > list of resources and a list of actions and make decisions on each > combination. > > The new requirement is to be able to specify particular resource/action > combinations. This is primarily required for efficiency when making a > remote call. It would greatly cut down on unnecessary decisions or network > messages. > > For example instead of merely saying: > > R1, R2, R3 > A1, A2, A3, A4 > > And getting 12 answers: > > R1, A1 > R1, A2 > .... > R3, A4 > > We would like to be able to specify particular cases. > > This could be done by providing specific pairs: > > R1, A1 > R1, A2 > R2, A1 > R2, A3 > R2, A4 > R3, A2 > R3, A4 > > Or by some kind of grouping syntax > > R1, {A1, A2} > R2, {A1, A3, A4} > R3, {A2, A4} > > However here is the key question. > > We recently agreed to freeze the core. Since this is only needed for remote > access, it could be done by modifying the SAML Profile alone. However, this > would mean that remote and local requests would have a different syntax, > plus slightly different functionality. > > What is the feeling of the TC? Should we allow this change to the core or > only do it in the SAML 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]