CTAB Tuesday, January 14, 2020
New Meeting Date/Time Tue 1PM ET / 10 AM PT
Attending
Members
- David Bantz, University of Alaska (chair)
- Mary Catherine Martinez, InnoSoft (vice chair)
- Pål Axelsson, SUNET
- Rachana Ananthakrishnan, Globus, University of Chicago
- Tom Barton, University Chicago and Internet2, ex-officio
- Brad Christ, Eastern Washington University, InCommon Steering Representative to CTAB
Ercan Elibol, Florida Polytechnic University
Richard Frovarp, North Dakota State
- Chris Hable, University of Michigan
- John Pfeifer, University of Maryland
- Chris Whalen, Research Data and Communication Technologies
- Jule Ziegler, Leibniz Supercomputing Centre
- Robert Zybeck, Portland Community College
Internet2
- Ann West, Internet2
- Albert Wu, Internet2
- Emily Eisbruch, Internet2
- Jessica Coltrin, Internet2
Regrets
- Brett Bieber, University of Nebraska
- Jon Miner, University of Wisc - Madison
- Eric Goodman, UCOP - TAC Representative to CTAB
New Action Items from this call
- AI TomB outline the steps we need to talk to kick off community consensus for next CTAB call
- AI Albert consult with Nick Roy and AnnW on suggestion to state in section 3.1.1 that federation operator will monitor and report back to CTAB on compliance
Discussion
New member Introductions
- Welcome to our new CTAB members
- https://www.incommon.org/community/leadership/
Baseline Expectations (BE) 2020 consensus doc
Key documents:
- BE V2 Draft https://docs.google.com/document/d/1Ubwc4RoqEO6HtbN6t9dpGvY2eiD5zcs3Zw5gh9xHMsk/edit
- BE Clarifications doc provides more explanation and how tos
- https://docs.google.com/document/d/1Xvan2fpX8Ig-KFvI4wT1fGmJR8bc464BMFWAsREh-Ec/edit
- The BE Clarifications Doc is intended to be an FAQ published on the wiki
- Its goal is to help participants understand what each BE statement means and now to adhere
Reminder that there are 5 possible components of BE that CTAB is working to implement in upcoming phases.
Numbers 4 and 5 below will likely be postponed for a future year, beyond 2020.
- SIRTFI Framework
- Encryption for endpoints for IDPs and SP
- Inclusion of Error URL in IDP metadata (no requirement for content; point to working group)
FOR FUTURE - Support for REFEDs MFA profiles (for future)
- Need to detail how organizations would comply with this, thanks to Eric G for his work on this
- IDP supports attribute bundling (R&S now; future anonymous attribute bundle) (for future)
- It was noted that the clarification doc only included items 1, 2 and 3 .
- There is a draft of clarification for items 4 and 5, but that had been removed from the draft.
- Decision: return the material on 4 and 5 to the draft, but explain that they are for the future most likely, and explain what likely still needs to be figured out (DONE)
- Also will include clarification of 4 and 5 (items for beyond 2020) on the eventual FAQ wiki page.
- CTAB reviewed recent updates to the BE doc
- It was noted that we do NOT want to be in the position of needing to revise the BE doc every few months
- Dispute resolution will be used to resolve situations on non compliance, such as for BE statements like this:
- 1.3.3. All IdP service endpoints must be secured with current and supported transport layer encryption
- We may want to be more specific around “current and supported”
- Suggestion to add the word “strong”
- Need to work on the wording for 1.3.3 more later
- There will be some automated tests around endpoints, for the TLS security requirements.
- For the SSL Labs tests, there were a few “F”s, in the preliminary analysis performed by Shannon Roddy
- Some think we need to be more specific.
- SURFnet uses the SSL Lab grading
- If InCommon will use SSL Lab grading, we should be more explicit
- For the SP side, we do not mention Error URL
- Could specify that SPs must be ready to use an Error URL
- Whether the SP can handle Error URL impacts the user experience
- Suggestion to focus on security as the theme for this phase of BE
- And tackle user experience issues in next phase of BE
- There is a proposal for a task force that may address the user experience
- Decision: No change to the doc at this time around mentioning SP side Error URL
- Perhaps errorURL by SPs should be considered in a future rev of BE.
- Do we want to add any sub-bullets in section 3 for Federation Operators?
- AI Albert consult with Nick Roy and AnnW on suggestion to state in section 3.1.1 that federation operator will monitor and report back to CTAB on compliance
Timeline for BE announcement and moving into consensus period
- Consensus period
- Start when
- how long?
- When do we announce consensus achieved ?
- How do we field feedback during consensus?
- CTAB had hoped to have community consensus period kickoff info for the community by end of January 2020
- A future CTAB meeting should discuss logistics of running the community consensus process.
- AI TomB outline the steps we need to talk to kick off community consensus for next CTAB call
Next CTAB Call : Tuesday Jan 28, 2020 at 1pm ET