Action Items from Past Meetings
Minutes
Attending: Mark Scheible, Keith Wessel, Heather Flanagan, Janemarie Duh, Eric Goodman, Tom Demaranville, Mike Grady, Matt Brookover, Judith Bush, Keith Wessel, Kim Milford
With: Ian Young, David Walker, Nick Roy, Shannon Roddy, Steve Zoppi, Kevin Morooney, Mike LaHaye, IJ Kim, Ann West, David Shafer
REFEDS Work Plan
The REFEDS 2018 Workplan is available for idea submission/+1-ing. REFEDS is gathering information now, so this would be a good time to review the proposal and provide input.
Ops Update
Two FM updates released in the last two weeks (3.2.2, 3.2.3). Most of the functionality is not user facing.
InCommon discontinued the original metadata download endpoint (incommonfederation.org - which has been redirecting to incommon.org for several years) on February 14. Ops has done several announcements and will continue to monitor the use and communication. February 27 is the end of the validation period for the last metadata aggregate including incommonfederation.org; people will feel pain at that point.
Trust and Identity Updates
Baseline Expectations Metadata Health Checks will go out on Monday, Feb. 19. There is a webinar on health checks on Wednesday, Feb. 21 (2 pm ET)
Working Group Updates
Attributes for Collaboration in Federation - Continuing to document interviews with institutions not releasing R&S, as well as data collected via a survey.
OIDC Working Group - Working on characteristics of use cases we want to collect. Nathan Dors is developing a way to collect the use cases.
Deployment Profile - Wrapping up the last few GitHub issues. The goal is to have everything worked out by March 1. Once that is finished, the plan is to submit the report for a formal community review process and plans for socializing the plan at Global Summit.
Streamlining SP Onboarding - Issued a call for feedback to the WG email list, and there are plans to do so to the participants list, as well.
TAC Mission Statement and Potential Recharter
There was a wide-ranging discussion about development of a new TAC mission statement, then evaluating the charter against that statement to determine if revisions are needed. The current charter is here: http://www.incommon.org/docs/policies/TACcharter.html.
TAC has spent some time talking about the purpose for the TAC, how it has evolved, and how it can best serve the community. Part of this is determining how the different groups within InCommon and Trust/Identity work together. There was discussion about TAC's role as it relates to the InCommon mission statement.
InCommon Mission Statement - The mission of InCommon is to create and support a common trust framework for U.S. education and research. This includes trustworthy shared management of access to online resources in support of education and research in the United States. To achieve its mission, InCommon will facilitate development of a community-based common trust fabric sufficient to enable participants to make appropriate decisions about the release of identity information and the control of access to protected online resources. InCommon is intended to enable production-level end-user access to a wide variety of protected resources.
There were two thoughts related to the InCommon statement:
- Consider alternatives to the word “release,” since that is a hot-button for some campuses
- Define what “common trust fabric” means; for example:
- Security
- Academic collaboration
- Supporting e-research
- Providing the framework for access services
The discussion turned to thoughts about TAC’s mission and role
- For end users federation is easy to use. For IT, Shibboleth and the details and data policies are all difficult to maintain.
- There are continuing discussions about privacy policies as they relate to cloud services and attribute exchange
- What will be done to ensure federation continues to be relevant and usable? One of the REFEDS work items is looking at a combination of SAML and OIDC federation work and pilots. Do we need to step back and look at how federations should operate, given some of these new challenges? Some potential questions:
- How to maintain and improve on what/how we are currently operating
- What’s the next version of federation going to look like?
- One role of TAC is to engage with the community and their needs, so both campus perspectives and how those fit with global perspectives
- Community communications aimed at getting more people active. Communicate resources: participants list, technical-discuss list, WG lists, paying attention to announcements
- TIER could help alleviate local technical problems
- With TAC as an advisory body, a primary role is to determine community needs and translate those into a roadmap to develop practices and capabilities to meet those needs (and advise Steering on same)
- The current TAC charter doesn’t speak to the international partnerships
- Help for campuses is available via TIER, with software packages to make it easier to install and configure. TAC could encourage adoption and a feedback loop
- How can TAC act as bridge between hearing anecdotes from colleagues and constituents, then identifying what the real problems are and providing information about solutions that may exist
- Security is a key benefit of federation that is not readily apparent. By not adopting federation and provisioning for access, you are actually becoming less secure, because researchers and faculty will find work-arounds
- One role/goal seems to be trying to change community behavior in prescribed ways. We keep running into the problem of data release and likely will only make incremental gains. A lot of current work is to provide tools or processes to make it easier to participate
- Incorporating into messaging/communications that federation is secure - using campus credentials vs having username and password at 500 services scattered all over the place
(AI) Next step - Mark, Janemarie, Nick will distill those.
This conversation can continue on the email list.