Child pages
  • 2019-Dec-11 at TechEx in New Orleans
Skip to end of metadata
Go to start of metadata


CTAB Open Meeting at 2019 TechEx,  Dec 11, 2019

Thanks to John Krienke for these notes

For reference


 Welcome  and Intro

Baseline Expectations (BE) next phase 

Review 5 items for proposed community consensus:

  • TLS 1.2

What issues do you anticipate we’ll encounter with each of these?

What timeframe should we ask the community to meet each of these requirements?

A rough timeline framework for BE next steps:

  • Begin Community Consensus process in Q1 2020
    • This will be our first official use of the Community Consensus process.
  • Assess timeline from the community to meet the specific
  • Finalize recommendations in a community consensus process

All these steps may take up to one year from concept presentation, consensus process, implementation, and may vary based on community uptake.

Additional topics and notes: 

Community Dispute Resolution Process. To remedy disputes between and among InCommon Participants. 

Important to note: There is no unilateral decision that CTAB will make to change Baseline Expectations. The community consensus process is always invoked for changes. 

A Guidance Document is being created by Albert Wu of CTAB. ( v1 adherence draftclarifications on new items

Discussion of the 5 proposed changes: 

SIRTFI:  SIRTFI is also making some changes. How will the changes and requirements be managed? SIRTFI will manage versions with version control numbers (i.e., 1.0, 2.0). 

  • Does Sirtfi risk lawyers being involved?
  • Attesting to compliance might present a legal risk to the organization 
  • CTAB and SIRTFI members are discussing ways to field test compliance and report back to the GEANT task force. There is also a peer review process in the HPC community, involving a questionnaire, feedback, discovery, remediation, etc. 

TLS: Moving targets may also be an issue with TLS as well. There might be a way to use a benchmarking tool like SSL Labs. 

  • Dependency noted that we would be dependent on how SSL Labs updates its own rankings/grades
  • SUNet, Only allow B or greater, only allow a slack time of a week.
  • Need to figure out how to make people aware of impending SSLLabs changes
  • TLS is a technology. SIRTFI is a set of practices and policies. Are there differences to be aware of? 
  • Nick - Can we require TLS for endpoints and then drop the attribute encryption requirement for SP endpoints that is often a problem for SPs?
  • Active scanning of endpoints. Nick. We updated the InCommon participation agreement when Baseline Expectations were added. There is latitude now that would/could include permission for InCommon to actively scan endpoints in published metadata. 
  • TLS: if we get too restrictive, we will start having to drop support for certain browsers. This could also be very problematic for hospitals who must run old versions of browsers in patient-facing services. 
  • Can we have a report-back interface that summarizes browser versions in the TAP versions and instructions for non-TAP?

Ways to measure each of the components of BE.  The guidance document (URL above) intends to capture how we will implement and measure meeting each requirement. 

ErrorURL: This one speaks to a consistent user experience. What content should be on the page? Comments? 

  • General advice. What is the error related to? Missing attributes, MFA, etc?  
  • Sweden: send back a cropped URL related to the issue. 
  • Basically all errors that SP's can't do anything about 
  • SAML2Int mentions requirements for this as well
  • Perhaps also include a few standard SP-related problems that IdP support can forward to the SP operator. 
  • Let's get a working group of some kind together to develop a standard around this (a possible Advance CAMP topic for later in the week)
  • SP error Guidance. Do we take this up, or just mandate IdP ErrorURL? 
  • Proxies! (how will they handle specific error URLs?) 
  • Error URL is *only* about critical problems where the user cannot proceed. Agreed?
  • We can get better incrementally. We don't have to mandate a perfect, all encompassing solution.  
  • Logos for both IdP and SP could also be included in the guidance for good error reporting behavior. 
  • There was agreement  that ErrorURL is for sending users to on a fatal error where the SP can't function.  Otherwise the SP should continue, perhaps suggesting the user contact the IdPO about the "problem".

MFA:  Just the ability to signal MFA. 

  • Are we excluding any commercial vendors? An important consideration. 
  • Can ADFS do this? Does all IdP software support this capability? 
  • Some other component (bridge, hub, proxy, IdPaaS) could provide this capability. 

Begin communicating now that changes are afoot, even though we may not be ready with the actual recommendation. 

Maybe a Roadmap that we will eventually be going here. 

SP side.  We need to tap into new voices. 

End of session.  


  • No labels