Re: [regrep] XACML and Access Control Policy

[Matthew MacKenzie <matt@mac-kenzie.net>]

I am not yet sure, I will probably have a better idea once I'm through 
reading the XACML stuff.

-matt
On Tuesday, January 7, 2003, at 02:42  PM, 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?
>
> -----Original Message-----
> From: Matthew MacKenzie [mailto:matt@mac-kenzie.net]
> Sent: Monday, January 06, 2003 8:09 PM
> To: Farrukh Najmi
> Cc: Damodaran, Suresh; regrep@lists.oasis-open.org
> Subject: Re: [regrep] XACML and Access Control Policy
>
>
> I would help on this one.  I see it as important.
>
> -Matt
>
> 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)
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Farrukh Najmi [mailto:farrukh.najmi@sun.com]
>>> Sent: Thursday, January 02, 2003 9:00 AM
>>> To: regrep@lists.oasis-open.org
>>> Subject: [regrep] ebRIM and ebRS 2.33 distribution
>>>
>>>
>>>
>>> Team,
>>>
>>> Happy new year to all of you.
>>>
>>> The ebRIM and ebRS 2.33 specifications may be downloaded respectively
>>> from:
>>>
>>> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ebxmlrr/ebxmlrr-spec/
>>> doc/ebRI
>>> M.doc?rev=1.10&content-type=text/vnd.viewcvs-markup
>>> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ebxmlrr/ebxmlrr-spec/
>>> doc/ebRS
>>> .doc?rev=1.9&content-type=text/vnd.viewcvs-markup
>>>
>>> Thanks to Nikola, Matt, Suresh, Monica and Sanjay for their
>>> contributions to this version.
>>>
>>> Please review this version of the specifications and be prepared to
>>> discuss the changes during our TC meeting on January 9th 2003.
>>>
>>> The changes to the documents were driven by the Action Items List,
>>> the latest version of which is
>>> found at:
>>>
>>> http://ebxmlrr.sourceforge.net/ebxmlrr-spec/specActionItems.htm
>>>
>>> Good news is that we have closed most of the Action Items on the
>>> actual specification documents in version 2.33!
>>>
>>>
>>> The latest XML Schema files may be found at:
>>>
>>> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ebxmlrr/ebxmlrr-spec/
>>> misc/sch
>>> ema/v3/rim.xsd?rev=1.10&content-type=text/vnd.viewcvs-markup
>>> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ebxmlrr/ebxmlrr-spec/
>>> misc/sch
>>> ema/v3/query.xsd?rev=1.7&content-type=text/vnd.viewcvs-markup
>>> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ebxmlrr/ebxmlrr-spec/
>>> misc/sch
>>> ema/v3/rs.xsd?rev=1.11&content-type=text/vnd.viewcvs-markup
>>> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ebxmlrr/ebxmlrr-spec/
>>> misc/sch
>>> ema/v3/federation.xsd?rev=1.7&content-type=text/vnd.viewcvs-markup
>>> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ebxmlrr/ebxmlrr-spec/
>>> misc/sch
>>> ema/v3/event.xsd?rev=1.4&content-type=text/vnd.viewcvs-markup
>>> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ebxmlrr/ebxmlrr-spec/
>>> misc/sch
>>> ema/v3/contentManagementServices.xsd?rev=1.2&content-type=text/
>>> vnd.viewcvs-m
>>> arkup
>>>
>>>
>>> Changes in RS 2.33
>>> ------------------
>>>
>>> -Updated Contributors list for Joe's affiliation change.
>>>
>>> -Updated figure 4 in section 6.3 for HTTP binding
>>>
>>> -Updated 6.6.4, 6.9.1 and 6.9.2 for SignatureList. Now defines how
>>> signed request/responses are
>>> handled by HTTP binding.
>>>
>>> -Fixed UpdateObjectRequest semantics to only allow updates and not
>>> allow new submisison per Nikola's suggetsion.
>>> Fixed 7.4.1.2 appropriately.
>>>
>>> -Added UndeprecateObjects protocol in section 7.9
>>>
>>> -Specified in 9.10 that repositoryItem input is specified via a
>>> $repositoryItem variable.
>>>
>>> -Updated chapter 10 (event Notification) and corresponding schema
>>> after design review with following changes:
>>>    -Now uses base type AdhocQuery in Selector instead of choice
>>> between FilterQuery and SQLQeury
>>>    -Now only supports 2 notificationOptions (ObjectRefs and Objects)
>>>    -Now allows multiple EmailAddresses and Services in
>>> NotificationAction sub-types
>>>    -NotificationType no longer abstract
>>>    -Notification element defined to allow the simplest Notifications
>>> (used in Object Relocation)
>>>    -Notification is now a RegistryResponseType
>>>    -Removed GetNotificationResponse as it is replaced by
>>> NotificationType.     -Updated section 11.4 Object Relocation as
>>> follows:
>>>    -Now uses AdhocQuery to select objects being relocated.
>>>    -Decided that Object Import/Export was not adequate alone and that
>>> an Object relocation protocol was still needed.
>>>    -Updated fig 70 sequence diagram to show use of EVent Notification
>>>    --Updated fig 70 sequence diagram to show use AdhocQueryRequest
>>>    -Updated  11.4.5 and 11.4.6 to spec how notifications are used for
>>> Object Relocation protocol.
>>> -Updated chapter 12 and appendix F to clarify that User that submits
>>> content is the owner of the content.
>>>
>>> -Removed RegistryProfile from appendix and rs.xsd and merged
>>> attributes into Registry class.
>>> The registry class replaces all prior functionality of the
>>> RegistryProfile element.
>>>
>>> -Updated appendix E2 SQL BNF to use hyperlinks
>>>
>>> -Updated Appendix C for Canonical ClassificationSchemes and their
>>> proposed locations.
>>>
>>> Changes in RIM 2.33
>>> -------------------
>>>
>>>
>>> -Updated Contributors list for Joe's affiliation change.
>>>
>>> -Updated chapter 11 Event Notification for design changes in Event
>>> Notification itemized in RS changes above.
>>>
>>> -Updated 12.1.1 and sub-sections to add missing attributes to
>>> Registry class.
>>>
>>> -Updated figure 2 Registry Object Inheritence View in chapter 7 to
>>> add Subscription, Registry and Federation classes
>>>
>>> Looking forward to your comments on the January 9th TC meeting.
>>>
>>>
>>
>>
>>
>>
>> ----------------------------------------------------------------
>> 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>