Attending

• Mary Catherine Martinez, InnoSoft (chair)
• David Bantz, University of Alaska  (vice chair)
• Brett Bieber, University of Nebraska  
• Rachana Ananthakrishnan, Globus, University of Chicago   
• Tom Barton, University Chicago and Internet2    
• Brad Christ, Eastern Washington University  
• Eric Goodman, UCOP - TAC Representative to CTAB  
• Jon Miner, University of Wisc - Madison  
• John Pfeifer, University of Maryland  
• Chris Whalen, Research Data and Communication Technologies  
• Ann West, Internet2  
• Albert Wu, Internet2
• Emily Eisbruch, Internet2    

Guest

• Scott Koranda, representing SIRTFI

Regrets

• Chris Hable, University of Michigan
• John Hover, Brookhaven National Lab
• Adam Lewenberg , Stanford  

Action Items

• AI (Albert) update the docket with status discussed on the June 5, 2019 CTAB Call (done)
• AI (MC) send a note (drafted  by AnnW) to Steering that the removal of a few entities is slated for July 15 (DONE) (KevinM will forward this info the Internet2 Exec leadership)
• AI (MC or David) solicit CTAB volunteers to join a task force  to work with SIRTFI around metadata accuracy.

Discussion

Baseline Expectations Phase 1 - Closing activity update (Albert) (5 min)

• Need to set deadline for removing the few entities who have not responded to outreach around meeting Baseline Expectations
• makes sense to propose a July 15 removal date.  
• CTAB agreed that a removal notice will be sent.
• AI (Albert) will update the docket with this status discussed on the June 5 CTAB Call
• AI (MC or David) send a note (drafted  by AnnW) to Steering that the removal of a few entities is slated for July 15 (DONE)
  (KevinM will forward this info the Internet2 Exec leadership)
• Note the list of entities not meeting Baseline is extremely   small compared to full InCommon membership.  
• Recent statistics from June 2019 
  All entities: 4816 of 4844 meet the metadata expectation (99%)
  IdPs: 529 of 536 meet the metadata expectation (99%)
  SPs: 4287 of 4308 meet the metadata expectation (100%)
  Orgs: 744 of 763 meet the metadata expectation for all entities (98%)```

TAC request for Badging sub group participation (Albert) 

• Badges may be used for good practices around issues such as preservation of privacy and Identity proofing
• It will be helpful to work on a closer relationship with information security - Higher Education Information Security Committee (HEISC)
• It may be worthwhile to develop conformance testing suite to certify software  

• David has joined the subgroup looking at badging, others invited to join also
• Brett and JonM will join this effort
• How does badging align with baseline expectations?
• An entity must meet baseline expectation to be part of InCommon.
  • Badges will represent additional good practices
• May create a roadmap for future baseline practices
• Who is the target for viewing the badge?
• A university may be evaluating a vendor /SP for adoption and wants to see how well that vendor integrates with federation
• Target is to evaluate an SP, and there may be other use cases
• Rachana, have been asked if  we can visually display to a user if standards are met? This is harder to do.  Will be an interesting direction.
• Don’t want to boil the ocean and create info overload.
• Other related efforts around badging
  • KevinM: There are many badging conversations going on, including in Net+, and in REN ISAAC.
  • Consumption of badges by end users, consumption of badging by vendors
  • Need to scope the work carefully. Be aware of what other efforts are doing
  • DavidB spoke w JackS, who emphasized privacy protection, and suggested working more closely w HEISC and E&I Consortium

• RA21 work is of interest around privacy profile or privacy preserving attribute release. We may want to follow what they are working on.
• TomB: there is much context needed in evaluating practices.
  • worry about badging incentivizing one size fits all solutions, though making things simple is good
  • A privacy badge for a consumer service might be different than a privacy badge for a research service

Update on collaboration with SIRTFI WG 

• Scott Koranda talked about proposed partnership with CTAB on a focused area
• Testing every day and quality assurance
• It’s about security incident response
• Excited about uptake of SIRTFI within InCommon
• Need to be sure those who agree to respond by self asserting SIRTFI for their IDP or SP
• They must get info they need, especially the contact emails must be in metadata and must be fresh and accurate
• For a security incident, it’s crucial to have a working and correct email contact
• SIRTFI thinking about what it means to keep that email contact info up to date and accurate
• How much testing to do of the security emails? How often? What’s the right balance and approach?
• SIRTFI thinking about this from a global perspective
• LIGO wants all IDPs and SPs to be tagged as SIRTFI
• SIRTFI knows that CTAB has gone thru the baseline expectations process, including getting complete contact metadata
• Proposal: SIRTFI and CTAB work together on exploring these issues of accurate, fresh metadata, for SIRTFI and then take the learnings to other federations to make this a global issue.
• Q: What is the current status of checking of contact metadata?
• A: InCommon checks when emails bounce
• First step for CTAB was to get entity's contacts into metadata
• Next is to be sure it stays current
• TomB: GEANT (Mario Reale’s  team) has looked at a tool for checking contact metadata. Is willing to share that work.
• Q: What constitutes a valid email?  Just that is does not bounce? Or that someone is checking and replies?
• A: Mario’s team’s work includes that there should be a response
• Albert: Part of responsibility as security contact is to respond to emails
• Scott: there is some requirement, but not to respond to probes
• TomB: we will need to help create definitions and modifications
• Two requirements that could be separate: 1. You assert SIRTFI 2. You have accurate and responsive contacts
• Note: it has been proposed but not yet decided if SIRTFI is part of the next version of Baseline Expectations
• What's the best way for this CTAB and SIRTFI collaboration to move forward?
• Joint work group
• To mock up small proof of concept for probing
  
  
• Brett supports a small group to work on recommendations for next version of Baseline Expectations and to be proposed to InCommon community
• This fits nicely with the direction of CTAB to look at security and email validity
• Have SIRTFI incorporate more  on what’s required for security contact
• We could ask small set of IDPs and SPs to participate in small pilot
• Two prongs
•  policy side on responsiveness / frequency of querying
• the technical/mechanical implementation
• Long term there might be infrastructure run by InCommon to help the smaller organizations
• AI (MC or David) solicit CTAB volunteers to join a task force  to work with SIRTFI around metadata accuracy.
• Scott will solicit volunteers from SIRTFI
  
  
1. Review draft Baseline Communication to Participants - (David/Brett) 
• Closing Transitioning Baseline v1
• Call for initial input on Baseline v2 
• This is a brainstorm phase, not a consensus phase
• Idea is to broaden be conversation beyond CTAB
• Suggestion to introduce CTAB a bit in the email
• Suggestion to solicit input using Survey Monkey
• Need to be carefully consider what questions to ask
• David suggests that in brainstorming phase we should not ask specific questions
• TomB: very important to have the right sample
• Concern about value to the federation,  if we are beholden to the survey would be concerned
• There is a process on how to evolve CTAB using community consensus https://spaces.at.internet2.edu/display/TI/TI.107.1
• Decision is to continue this conversation next CTAB call.
  
  
2. NOT DISCUSSED ON THIS CALL:
• BE Survey - (Albert) 

Next CTAB call:  June 19, 2019