Re: [regrep] XACML and Access Control Policy

[Max Voskob <mvoskob@msi.com.au>]

Hi all!

I'm not a member of your TC, but still would like to ask you to keep RegRep
free from patents.
Make the XACML optional or do not use it at all for now.
Good things take time. It's not known yet if XACML will be popular or not
and rushing it thru may do more harm than good.

Cheers,
Max


----- Original Message -----
From: "Damodaran, Suresh" <Suresh_Damodaran@stercomm.com>
To: "'Chiusano Joseph'" <chiusano_joseph@bah.com>
Cc: "'Farrukh Najmi'" <farrukh.najmi@sun.com>; "Breininger Kathryn R"
<kathryn.r.breininger@boeing.com>; "Matthew MacKenzie"
<matt@mac-kenzie.net>; <regrep@lists.oasis-open.org>
Sent: Thursday, January 09, 2003 10:04 AM
Subject: RE: [regrep] XACML and Access Control Policy


> 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>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>