You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 37 Next »

Data Structures and APIs Working Group Charter (Draft)

Problem Statement

Nearly every online activity in research and learning relies on Identity and Access Management (IAM) services.  That fact puts front and center the question of how those IAM services are 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:

  1. Campus integration teams
  2. IAM software package designers and developers
  3. Application developers
  4. Campus IAM and Security service providers
  5. ...

Charter

The APIs and Schemas Working Group will:

     0. Review and take lessons from directly relevant prior work inside and outside academia

  1. Recommend a first round set of conventions for API design and data structure development
  2. Define a process for ongoing effective two-way communication with TIER developers who will deliver the API and those who will use it
  3. In tandem with the development teams, complement the API set with a corresponding set of events and messages
  4. Learn from experience of TIER development teams what improvements or additions are needed for the next iteration.
  5. Publish full data structure definitions as an integral part of the documentation of each API
  6. Iterate on 1 - 6
  7. Refine an IAM functional model
    1. Settle on an inventory of relatively fine-grained IAM functions
    2. Define a comprehensive functional and conceptual model of IAM objects, events and actions
    3. Define how IAM objects, events and actions are used by the application layer
  8. In tandem with the development teams, define and recommend the use of a set of core object schemas that are extensible by design
  9. ...

 

Membership

Membership in the Working Group is open to all interested parties. (question) 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.

NOTE: The challenge for this working group, which is on the critical path for many other IAM deliverables, to be responsive to a variety of perspectives without losing the ability to be decisive and to keep forward momentum. Perhaps we define a two-tier structure: A core team and an interest group?

Work Products

  1. Draft Doc
  2. Vet Doc

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)
  • Calendar Invite (Outlook or Office 365)
  • Set up call coordinates (edial or BlueJeans)
  • Propose and send out agendas and meeting reminders

Related Resources

  • ...
  • ...

 

See Also

TIER Data Structures and APIs Working Group Home

TIER Working Groups Home

InCommon Working Groups

  • No labels