2011 01 25 Conference Call

Bridge Info

1/25/2010 4:00 PM, US/Eastern

+1-734-615-7474 (Please use if you do not pay for Long Distance)
+1-866-411-0013 (toll free US/Canada Only)

0167481# (Participant Code)

Attendees

• Jen B
• Keith H
• Chris H
• Scott C
• Benn O

Agenda

1. Group API Data Structures and Operations and Client-Provider Interface Considerations
2. API Phase 1 Deliverables and next steps
3. Integration with frameworks? (eg: Spring)

Notes

1. Query API vs Management API? (ie: read/write groups vs read/write permissions)
   1. Who needs a management API? COmanage, Atlassian, Oracle, uPortal
   2. Common group permissions: Admin the group (add/remove members), public (self-subscribe), readable (eg by a portal but not by the public)
2. Groups of non-Persons and Groups?
   1. uPortal portlet administration is through groups
   2. Role Based Accounts, Services, Portlets, Agents, Hardware Devices (switches, etc)
      1. Probably better not to try to enumerate all possible attributes
      2. Though it might make sense to borrow from existing schemas
3. Do we have too many group identifiers?
   1. Scott: single unique ID for all use cases, probably a URI with some segment holding a serial number to make it unique
   2. Alternate: URN+Display Name (URN could equal systemlocalprefix+systemname)
      1. URN or URI? URI -> URL for REST
      2. "Renaming Problem": political entity is renamed, or VIP wants the existing name
         1. Can this be handled by a "MOVED" reply? (In the latter case, if you want the new group with the old name, you have to explicitly ask for it.)

Action Items

New

1. Chris: Find out why subject type was dropped from I2 subject API
2. Benn: To put together new identifier proposal
3. Benn: Clean up Group API Data Structures and Operations for wider distribution
4. All: Identify use cases for renaming

Old