Data Structures and APIs Working Group Charter (Draft)
Problem Statement
In teaching, learning and research, nearly every online activity relies on Identity and Access Management (IAM) services. Developers of those IAM services must follow consistent patterns around how those services are to be invoked and used . Over the last decade the higher education community has produced an impressive collection of open source components for identity and access management. Recently there have been efforts to bring these components together, to develop new components to address gaps in coverage and to package the whole into a cohesive set of complementary services. APIs will be key to delivering loosely coupled but readily integratable IAM services.
This working group on APIs and schemas has been given the challenge of setting out an overarching conceptual model for IAM interfaces and information objects. To be effective, this model must be expressible as a set of design principles and conventions so that the resulting services will collectively form a coherent and comprehensible whole. The alternative would be to let each component developer team come up with its own solutions to what is a common set of API design problems. As a result it would be more difficult for campuses to adopt such services and for the community to maintain and evolve their code base.
Stakeholders/Influencers/Influences
Different audiences can impact different aspects of this problem:
- Campus integration teams
- IAM software package designers and developers
- Application developers
- Campus IAM and Security service providers
- ...
Charter
The APIs and Schemas Working Group will:
0. Review and document lessons from directly relevant prior work inside and outside academia. Do this with design and development teams as the first audience.
- Recommend a first round set of conventions for API design and data structure development.
- Define a process for ongoing effective two-way communication with TIER developers who will deliver the API and those who will use it.
- In tandem with the development teams, complement the API definition with a corresponding set of events and messages.
- Learn from the experience of TIER development teams what improvements or additions are needed for the next iteration.
- Iterate on 1 - 5.
- In parallel with the iterations on 1 - 5, define, vet and refine an IAM functional model:
- Iterate on an inventory of relatively fine-grained IAM functions.
- Iterate on a comprehensive functional and conceptual model of IAM objects, events and actions.
- Iterate on documentation of how IAM objects, events and actions can be used by the application layer.
- In tandem with the development teams, define and recommend the use of a set of core object schemas that are extensible by design.
- ...
Membership
Membership in the Working Group is open to all interested parties. 
Members join the Working Group by subscribing to the mailing list, participating in the phone calls, and otherwise actively engaging in the work of the group.
==> KH NOTE 2015-09-10: This Working Group is on the critical path for many of the other IAM deliverables. The challenge for the group is to balance responsiveness to a variety of perspectives with a need to be decisive and to keep forward momentum on working through tasks and issues.
Perhaps we define a two-tier structure: A core team and an interest group?
<==
Work Products
Each of the Tasks listed under the Charter above result in work products in the form of documentation and guidance. The ordering of the Charter task list defines a sequencing of tasks along three parallel tracks:
- Conventions for API and data structures
- IAM functonal model
- Core object schemas
Request for Internet2 Assistance with:
- Creation of Wiki space
- Creation of mailing list api-wg@?
- Help setting up call schedule (Doodle poll or other mechanism)
- Creation of calendar invitation (Outlook or Office 365)
- Set up call coordinates (edial or BlueJeans)
- Propose and send out agendas and meeting reminders
Related Resources
- ...
- ...