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

Compare with Current View Page History

« Previous Version 2 Next »

Working Group Agenda/Notes

These notes are live-scribed at: https://docs.google.com/document/d/1KuCp_q_oJfeFlA37XNsK4eB7zKdlWTAt42reHS2scDw/edit?usp=sharing

Working Group Chair: Walter Hoehn, University of Memphis

Email List:  fed-interop-wg@incommon.org . To subscribe this list, email sympa@incommon.org with the subject line subscribe fed-interop-wg

Problem Statement

When InCommon was created 10+ years ago, it was an explicit goal to keep the bar for membership and operational participation as low as possible. This helped to grow the Federation to its current size. However, this has also helped to hinder interoperation. Members cannot make any real assumptions about policy, practices, and the supported functionality at other members sites when attempting to interoperate. Both IDPs and SPs suffer from this problem. Areas that are affected include 1) the functionality provided by a SAML implementation (whether open source or commercial), 2) the sites policies implemented within that SAML instance, and 3) the way that a site configures that package to operate within InCommon. This Working Group is charged with developing both minimal and best practice statements in order to improve the "interoperate by default" situation.

Stakeholders/Influencers/Influences

Different audiences can impact different aspects of this problem:

  1. Companies/software developers who build this software need a list of the required functionality. This should build on existing SAML standards, specifications, InCommon standards/recommendations, and REFEDS/eduGAIN standards/recommendations.
  2. Deployers will need a list of functions that they will need to configure/enable in their chosen SAML software
  3. Campuses will need a list of policy issues/questions and operational practices that promote "interoperate by default" that they will need to address before configuring their SAML software (eg  support for R&S, etc). A separate group will develop trustmark related recommendations which will address policies related to IDM practice.

This Working Group will need to develop lists for all three audiences.

Charter

The Federation Interoperability Working Group will:

  1. Develop a list of minimal requirements for implementers of SAML software, in order to minimally interoperate within InCommon with a minimum of IDP Admin involvement.
  2. Develop a list of minimal requirements for deployers configuring SAML software, and seeking a baseline of interoperability with other InCommon entities.
  3. Develop a list of policy issues that promote "interoperate by default"  that campus should address as part of the process of deploying an IDP. (are there comparable policy questions for SPs?)
  4. Develop a list of Operational Practices that promote "interoperate by default"  that deployers should adopt (e.g. responsibilities for user support and incident response).
  5. Identify which of these requirements could be "tested" if InCommon OPS were to deploy a testing framework.

This Working Group is charged with developing the "WHAT" of interoperation in several different areas. Follow on efforts will be charged with developing specific technical recommendations for "HOW" sites can accomplish the WHAT.

This group is encouraged to think in terms of "levels" of compliance in each area (e.g. baseline, better, best).

This group is encouraged to coordinate, as appropriate, with other Federations and via REFEDS.

The group might want to have separate subgroups working on implementation vs deploy requirements.

Note: The InCommon Priorities item also mentions developing a replacement for the POP. The TAC has asked the AAC to approve and begin work on the TrustMark WG Charter that they developed, and to send the resulting report back to the TAC. The TAC will then develop a cover memo and assemble a package of documents to complete the Steering 2015 item.

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.

Work Products

  1. Sept 2015
    1. An initial list of baseline requirements that a SAML software implementation must meet
    2. An initial list of baseline requirements that deployers of SAML software must meet.
  2. Dec 2015 
    1. A complete, fully specified set of baseline requirements that a SAML software implementation must meet
    2. A complete, fully specified set of baseline requirements that deployers of SAML software must meet.
    3. A LIst of which items can be "tested".
  3. ??
    1. A list of "better" requirements that a SAML software implementation must meet
    2. A list of "better" requirements that deployers of SAML software must meet.

Related Resources

  1. It maybe worth listing items in SAML 2 CORE that [vendors] often do not implement.
  2. The saml2int Deployment Profile.
  3. draft IdP Deployment Checklist.
  4. Net+ guidance for services 
  5. CIC cloud services cookbook
  6. Scott's list of OASIS specifications (see below)
  7. https://github.com/rohe/fedlab
  8. http://fed-lab.org/
  • No labels