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

Compare with Current View Page History

« Previous Version 70 Next »

Problem Statement

Nearly every online activity is supported by one or more aspects of Identity and Access Management (IAM).  This is perhaps especially true in the domains of teaching, learning and research, Since these IAM services are so ubiquitous, it would be best if service developers followed consistent patterns in how they are to be invoked and used. Over the last fourteen years the higher education community has produced an impressive collection of open source components for various identity and access management capabilities. Recently, the community has taken on the challenge of bringing these components together, developing new components to address gaps in coverage and packaging the whole into a cohesive, easily installable and configurable set of complementary services. Well defined and documented APIs will be key to being able to deliver such loosely coupled but readily integratable IAM services.

This Data Structures and APIs Working Group (WG) has been asked to set out an overarching conceptual model for IAM interfaces and information objects. To be more than shelf-ware, such a model must be expressed as a set of design principles and conventions such that the resulting data structures and services will form a coherent and comprehensive whole. Leaving this task undone would certainly lead to increased complexity and needless inconsistencies as each IAM component developer team would likely come up with variant solutions to what is actually a common set of API design problems. As an outcome, campuses would find it more difficult to adopt the resulting services and the education and research community would find it more challenging to maintain, support and evolve the IAM services code base and documentation.

Stakeholders, Influencers and Influences

Different audiences will need to be invited to engage on different aspects of this work. The audiences include, but are not limited to:

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

Tasks

The APIs and Schemas Working Group will:

     0. Review and document lessons from directly relevant prior work inside and outside academia. Do this, and all subsequent tasks with design and development teams in mind as the most important audience.

  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 definition with a corresponding set of events and messages.
  4. Learn from the experience of TIER development teams what improvements or additions are needed for the next iteration.
  5. Iterate on 1 - 5.
  6. In parallel with the iterations on 1 - 5, define, vet and refine an IAM functional model:
    1. Iterate on an inventory of relatively fine-grained IAM functions.
    2. Iterate on a comprehensive functional and conceptual model of IAM objects, events and actions.
    3. Iterate on documentation of how IAM objects, events and actions can be used by the application layer.
  7. In tandem with the development teams, define and recommend the use of a set of core object schemas that are extensible by design.
  8. In association with each TIER release, produce a report on the state of TIER products with respect to the standards, best practices, and other guidance produced in the course of the WG's work.
  9. Some WG documents will be normative, all WG documents will be versioned.
  10. ...

 

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.

==> 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 stakeholders with a need to be decisive and to maintain forward momentum on WG tasks and issues. This problem is not unique to this WG, but will be encountered in several others as well.

Perhaps we could define a two-tier structure: A membership-on-approval core team plus an open community group?     <==

Work Products

Each of the Tasks listed under the Charter above result in work products in the form of documentation and/or guidance. The ordering of the Charter task list defines a proposed sequencing of tasks along three parallel tracks:

  1. Conventions for API and data structure development and design
  2. A comprehensive IAM functional model
  3. Core object schemas

Request for Internet2 Assistance with:

  • Creation of a WG Wiki space
  • Creation and archiving of a WG mailing list dsapi-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

  • Arrange for TIER developers, QA people, and others to allocate some of their time to working together with this WG as specified under "Tasks" above

  • Support the publication, promotion, discoverability and persistence of appropriate WG documents

Related Resources

  • ...
  • ...

 

See Also

TIER Data Structures and APIs Working Group Home

TIER Working Groups Home

InCommon Working Groups

  • No labels