OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[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