[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [regrep] XACML and Access Control Policy
Yes, but at the same time as an OASIS TC, we should feel free, encouraged and unencumbered to incorporate other OASIS standards into our specification. :) "Damodaran, Suresh" wrote: > > Yes, [2] looked easier on the TC, but IBM's[1] looked more problematic. > In any case, wouldn't you agree, as good citizens of the spec developer > world, > we do need to worry about the pains the implementers would go through as > well. > > Regards, > > -Suresh > Sterling Commerce (on loan to RosettaNet) > > -----Original Message----- > From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] > Sent: Wednesday, January 08, 2003 2:46 PM > To: Damodaran, Suresh > Cc: 'Farrukh Najmi'; Breininger Kathryn R; Matthew MacKenzie; > regrep@lists.oasis-open.org > Subject: Re: [regrep] XACML and Access Control Policy > > From [2]: > > <Excerpt> > "Upon approval by the OASIS Board of Directors of the Specification, > ContentGuard is willing to offer nonexclusive licenses to the patents to > persons wishing to pursue compliant implementations of the > Specification. These licenses will be provided under reasonable and > non-discriminatory terms and conditions, in accordance with > ContentGuard's then current licensing practices." > </Excerpt> > > Based on this, it appears to me that this binds the implementors of the > specification, not the developers of the specification itself. > > Thoughts? > > Joe > > "Damodaran, Suresh" wrote: > > > > Here is a thought that we may need to confront sooner or later. > > XACML is not free of IP claims [1,2]. Since we don't want reg-rep v3.0 > > to be encumbered by IP claims, one option we have is the following: > > > > 1. Make a meta model and then bind XACML to it. This should leave the > option > > of making other > > bindings as well. I don't claim I know exactly how to do this as yet, > > but that is something we would need to figure out together. > > > > The second option is to forget about the metamodel and let the burden fall > > on > > the implementers. > > > > Any other thoughts or other options? > > > > In any case, it looks prudent to cleanly identify and compartmentalize > > the spec portions that deal with XACML and Custom Access Control. > > > > Regards, > > > > -Suresh > > Sterling Commerce (on loan to RosettaNet) > > [1] http://www.oasis-open.org/committees/xacml/ibm_ipr_statement.shtml > > [2] http://www.oasis-open.org/committees/xacml/cg_ipr_statement.shtml > > > > -----Original Message----- > > From: Farrukh Najmi [mailto:farrukh.najmi@sun.com] > > Sent: Tuesday, January 07, 2003 8:03 PM > > To: Breininger, Kathryn R > > Cc: Matthew MacKenzie; Damodaran, Suresh; regrep@lists.oasis-open.org > > Subject: Re: [regrep] XACML and Access Control Policy > > > > I believe that proposed changes for custom ACP are largely orthogonal to > > the the set of changes proposed to be reviewed this Thursday. The only > > overlap in in the security chapters of RS and RIM where the changes for > > 2.33 were fairly minor. We could defer these chapters review until we > > finish the Custom ACP task. > > > > -- > > Regards, > > Farrukh > > > > Breininger, Kathryn R wrote: > > > > >Sounds like this should be the first agenda item. Do you anticipate > other > > sections of the specs changing as a result? If the second agenda item is > > reviewing the current changes, are there sections that will be affected by > > this proposal that we should skip in our spec review? > > > > > > > > >On Monday, Jan 6, 2003, at 17:03 America/Vancouver, Farrukh Najmi wrote: > > > > > > > > > > > >>Suresh, > > >> > > >>XACML based custom access control policy was planned for V3 and is in > > >>fact the only task that was planned for V3 that we have not addressed > > >>for V3. The task was dropped for two reasons: > > >> > > >>-XACML was a moving target > > >> > > >>-We had no one signed up for the task > > >> > > >>Given that XACML is now a month away from becoming the next OASIS > > >>approved standard ( I believe it will get approved) and given that you > > >>are offering to take ownership of the, I completely agree with your > > >>suggestion that we should do it for V3. > > >> > > >>My experience with several strategic ebXML Registry pilots using the > > >>ebxmlrr project has shown that this is a *MUST* feature for V3. In > > >>fact the ebxmlrr project has been implementing XACML based custom ACP > > >>as a implementation specific feature already. The experience further > > >>suggests that XACML is ready for building our specs on top of and that > > >>we *SHOULD* do custom ACP for V3 based on XACML. > > >> > > >>I believe we could accommodate the increase in scope with about 1 > > >>month slip to our V3 schedule. I think that the benefit of having this > > >>strategic feature far outweighs the cost of the delay to V3 schedule. > > >> > > >>I would be very willing to help you with this task. Maybe Sanjay could > > >>help as well (Sanjay?) and we could get our security sub-team charged > > >>up for V3. > > >> > > >>Kathryn, I propose we add this issue to this week's TC con-call. > > >> > > >>-- > > >>Regards, > > >>Farrukh > > >> > > >> > > >> > > >>Damodaran, Suresh wrote: > > >> > > >> > > >> > > >>>Hi all, > > >>> > > >>>It would be great to have XACML based custom access control policy > > >>>for V3. Is this something we are considering for V3? > > >>> > > >>>I may even volunteer sometime:-) > > >>> > > >>>Best regards, > > >>> > > >>>-Suresh > > >>>Sterling Commerce (on loan to RosettaNet) > > >>> > > >>> > > >>> > > > > ---------------------------------------------------------------- > > To subscribe or unsubscribe from this elist use the subscription > > manager: <http://lists.oasis-open.org/ob/adm.pl>
Attachment:
Chiusano_Joseph.vcf
Description: Card for Joseph Chiusano
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC