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, [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>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC