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 these components into a complementary set of easily installable and configurable services. Consistent, well defined and documented APIs will be critical to the broad adoption of such loosely coupled, but readily integratable IAM services.

This Data Structures and APIs Working Group (WG) has been asked to spell 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. It will be important for team members to bring the perspective and represent the interests of at least the following stakeholder groups:

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

Charter

The TIER Data Structures and APIs Working Group must keep in mind that TIER design and development teams are the first and most important audience for WG deliverables. Those teams will be the ones implementing concrete APIs, using them to integrate component services with each other and with other systems at the adopting campuses. To that end, the WG must establish and maintain effective two-way communication with the design and development teams.

The Working Group must sequence its work in a way that provides the design and development teams with what they need in order to complete their next round of deliverables.

This Working Group is on the critical path for many of the other IAM deliverables. So the challenge for the group will be to balance responsiveness to a variety of stakeholders with a need to be decisive and to maintain forward momentum on WG tasks and issues.

1. In tandem with the development teams, define and recommend the use of a set of core object schemas that are extensible by design.
2. 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.
3. Some WG documents will be normative, all WG documents will be versioned.
4. ...

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 contributing to the work of the group. The chair of the Working Group is appointed by TIER and is responsible for keeping TIER and InCommon TAC informed regarding Working Group's progress.

Work Products

The first iteration of Deliverable 1) above, the data structures and APIs Guidelines for API Developers, should be published by the end of the year (2015). It must be delivered in time to inform API development in the Release 1.0 Grouper and COmanage component APIs. 

documentation and/or guidance.  proposed sequencing of tasks along three parallel tracks:

Deliverables Timeline

By year end, 2015

• Review and document lessons from directly relevant prior work inside and outside academia

• Publish a critical evaluation of the basic group and membership management APIs in Grouper, VOOT2 from SURFnet, and SCIM.
• On the basis of that work, publish and promote the adoption of a first round set of conventions for API and data structure design. The goal is to inform and hopefully influence API development for Release 1.0 Grouper and COmanage components.

By April 2016

• Publish the first iteration of a comprehensive IAM functional model that encompasses the full scope of currently envisioned TIER deliverables.
• Publish the first iteration of core schema for the basic resources relevant to IAM (people, groups, services). Make extensibility and customization of schema easy but in a way that does not break existing service deployments.
• Pair the basic group and membership management APIs with an event-driven messaging approach to the same functionality. Clarify the circumstances that favor one approach over the other.
• Assess possible models for APIs and data structures around consent.
• Document the first round requirements for administering and monitoring IAM infrastructure and specify the kinds of instrumentation needed in each component to support administration and monitoring. 

Later, to be determined

• After each release, learn from the experience of TIER development teams what improvements or additions are needed
• Vet and refine the 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.
• Promote effective use by the application layer of IAM objects, events and actions by the application layer. In other words, domesticate applications.

Request for Internet2 Assistance:

• Already completed
  • Creation of a WG Wiki space
  • Creation and archiving of a WG mailing list TIER-api@internet2.edu
  • Set up an initial call schedule: Every other Wednesday starting Nov. 4, 2015 at 3 pm Eastern, noon Pacific
  • Set up BlueJeans for WG meetings
    
    
• In the queue
  • Creation of calendar invitation (Outlook or Office 365)

• Ongoing assistance
  
  • 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