Child pages
  • 2021-June-15 CTAB Public Minutes
Skip to end of metadata
Go to start of metadata


CTAB call Tuesday, June 15,  2021


  • David Bantz, University of Alaska (chair)  
  • Brett Bieber, University of Nebraska (vice chair) 
  • Pål Axelsson, SUNET  
  • Ercan Elibol, Florida Polytechnic University  
  • Richard Frovarp,  North Dakota State  
  • Jon Miner, University of Wisc - Madison  
  • Chris Whalen, Research Data and Communication Technologies 
  • Jule Ziegler,  Leibniz Supercomputing Centre  
  • Robert Zybeck, Portland Community College  
  • Tom Barton, Internet2, ex-officio 
  • Johnny Lasker, Internet2  
  • Albert Wu, Internet2  
  • Emily Eisbruch, Internet2  


  • Rachana Ananthakrishnan, Globus, University of Chicago  
  • Eric Goodman, UCOP - InCommon TAC Representative to CTAB 
  • Meshna Koren, Elsevier
  • Andy Morgan, Oregon State University
  • John Pfeifer, University of Maryland  
  • Dave Robinson, Grinnell College in Iowa, InCommon Steering Rep, ex-officio
  • Ann West, Internet2
  • Kevin Morooney, Internet2


Working group updates

    • Will wait until consultation is closed to make the updates
    • Next step: get the Assured Access Working Group back together to review the consultation feedback

Deployment profile and Adoption Analysis 

    • InCommon TAC Adoption Analysis looks at each section/statements and analyzes it for suitability for adoption
    • Assesses how feasible it is to adopt given today’s climate
    • Recommendations on:
    • 1. How soon should we adopt 
    • 2. How adoption should take place, what it should look like
      • InCommon TAC is spinning up a Testing working group to provide recommendations around this
      • Some items, such as related to metadata, can be enforced
      • Some are testable through testing tools
      • Some statements are not testable 
    • Some of the content may be useful within Baseline Expectations
    • Example: In Baseline Expectation : “your entity follows the standard of current security practices,”
    • some of the issues in the Deployment Profiles might connect to that
    • But others items (for example, log out behaviors) may not rise to level of Baseline Expectations
    • CTAB should become familiar with the deployment profile

    • For IDP as a Service,  technical details will be needed
    • TI.145.1
    • Deployment Profile provides a lot of what is needed in terms of expected best practices
    • For an IDP operator, if you are not configured perfectly, it’s OK, but we can point to this in examining disputes.
    • Question: which of the provisions of the Deployment Profiles are most likely to cause issues, perhaps around IDP as a Service?
    • Albert: Don’t anticipate issues, those participating in IDP as a service will comply
    • Wonder how Microsoft and OKTA will respond. 
    • Larger vendors may have a different perspective 
    • Not sure how campuses will respond to the Deployment Profile expectations
      • Depends on how we frame and position the Deployment Profile
    • Deployment Profile clarifies SAML 
      •  InCommon is a SAML federation, the Deployment Profile explains what we mean by SAML
    • There are some considerations around international
    • If InCommon deploys this but the rest of the world is not deploying this, it will become a conversation at some point
    • It would be worthwhile to compare this to edugain SAML profile
    • Focus on metadata exchange
    • Difficult for a federation operator to test 
    • InCommon is a mesh federation
    • We don’t interact with the orgs directly
    • Albert: Found some gaps in the Deployment profile as we reviewed it
    • Some R&E specific elements were omitted from the SAML deployment profile
    • There was intention for the working groups to go back and “tailor” 
      • But that has not occurred
    • Does not include non SAML issues such as attribute exchange
    • Does not address higher level stack issues, such as MFA behavior
    • Status on IDP as a Service Effort
      • Albert and Ann are working on program description of IDP as a Service
      • IDP as a Service is NOT a program where we operate a single IDP
      • It’s a program where we invite vendors to meet certain criteria so they can offer qualified solutions
      • Goal is that a handful or more of vendors will offer and IDP as a Service 
      • We need requirements and then we need criteria to measure success
      • Hope to launch IDP as a Service as part of the InCommon Catalyst program
        • Vendors who’ve expressed interest in supporting federated single sign on
        • InCommon Catalyst Program has worked out legal and procedural issues
        • Still some details to work out
      • Example: how to deal with roles and responsibility trust relationships with cloud provider in the middle
      • In order to scale, the vendor running IDP as a Service would want to have direct access to update certificates
      • We don’t have a friendly way to enable that today; need to work that out
      • Hoping larger vendors will start to pay attention and participate, more details and clear details will make it more attractive 
      • Will be interesting to use this deployment profile with NIH
      • Some chicken and egg problem, need broad adoption
      • NIH hopes to finalize new login service by end of July 2021
      • Adoption Analysis Report is being prepared by InCommon TAC for InCommon Steering review in July
      • Will there be a Community Consultation for this SAML Profile Adoption Analysis? Not sure
      • David: we should add to our CTAB agenda reports on IDP as a Service and on the the SAML profile adoption analysis
  • Early responses (if any) to Baseline Expectations v2 letter to Execs & Site Admins 
    • Letter on BE v2 is scheduled to be sent out this week. 

Next CTAB Call : Tuesday, June 29, 2021


  • No labels