• 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    


  • Scott Koranda, representing SIRTFI


  • 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.


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

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
    • Decision is to continue this conversation next CTAB call.


    • BE Survey - (Albert) 

Next CTAB call:  June 19, 2019



  • No labels