Page Comparison

...

0180424 (Participant)

Attendees

• ~cantor.2@osu.edu
• ~raydavis
• Keith Hazelton
• Chris Hyzer
• Jeremy Hansen (U of Iowa)
• Maleki
• Dan Seibert (UC San Diego)
• Josh Hoyt (Galois)
• Jason Daggot
• ~bourey
• ~benno

Agenda

1. Discuss the features or characteristics of a hypothetical Group API, or figure out what prerequisites we need to get out of the way before we can do so
   1. Groups API Questions
   2. Federated Identity & Groups
   3. Functions vs Data Elements vs Access?
2. Scheduling next/regular calls (through spring timeline)

Notes

1. Simple vs Complex?
   1. Simple to start
   2. But may need subgroups, compound groups
      1. Sakai needs hierarchies of authorization and navigation based on group membership structure (eg: combining personnel data with academic structures)
      2. Latest Grouper APIs may be able to address some of the Sakai complexity
2. What type of identifiers does a group API need have as a reference?
   1. Opaque ID
   2. Username/NetID etc
3. If calling group API against multiple backends, how much should the API hide/handle that for you?
   1. Unclear, but API handling it implies client-side libraries beyond (eg) just simple REST calls

Action Items

New

• All: Answer Groups API Questions (and combine with meta-questions from old AIs)
  • What are projects' needs over the next 3-6 months for group data management? (To help determine roadmap and immediate work)

Old

• Benn: Set up mailing list & wiki
• All: Assemble examples/use cases
• All: Assemble pointers to existing APIs you have
• All: What are groups used for?
• Scott: Assemble examples of issues with groups in federated context