CTAB call Tuesday June 2, 2020

Attending

  •  David Bantz, University of Alaska (chair)
  • Pål Axelsson, SUNET
  • Brett Bieber, University of Nebraska  
  • Rachana Ananthakrishnan, Globus, University of Chicago 
  • Tom Barton, University Chicago and Internet2, ex-officio 
  • Ercan Elibol, Florida Polytechnic University
  • Richard Frovarp,  North Dakota State
  • Eric Goodman, UCOP - TAC Representative to CTAB  
  • Jon Miner, University of Wisc - Madison  
  • John Pfeifer, University of Maryland 
  • Marc Wallman, North Dakota State University , InCommon Steering Rep, ex-officio 
  • Chris Whalen, Research Data and Communication Technologies   
  • Robert Zybeck, Portland Community College
  • Ann West, Internet2 
  • Albert Wu, Internet2 
  • Jessica Fink, Internet2 
  • Kevin Morooney, Internet2 
  • Heather Flanagan, Seamless Access, guest 


Regrets

  • Mary Catherine Martinez, InnoSoft (vice chair)
  • Chris Hable, University of Michigan
  • Jule Ziegler,  Leibniz Supercomputing Centre
  • Emily Eisbruch, Internet2, regrets

Administration

New Action Items from this call

  • AI Albert and David will provide info to CTAB members for outreach around BE v2


DISCUSSION

Seamless Access Entity Categories and  Attributes Bundles Working Group updates - Heather

  • SeamlessAccess is a service designed to help foster a more streamlined online access experience when using scholarly collaboration tools, information resources, and shared research infrastructure. The service promotes digital authentication leveraging an existing single-sign-on infrastructure through one’s home institution, while maintaining an environment that protects personal data and privacy.
  • Heather’s slides
    • In the future there will be a contract language working group within Seamless Access
    • Authentication only
    • Anonymous Authorization
    •  Pseudonymous Authorization
    • Sharing of attributes is not the mission of Seamless Access
    •  Seamless Access wants to ensure a decent discovery experience, thus working on entity categories
    • Goals:
    •   make configuration easier for IdPs
    •   offer common language/terms/expectations that can be fed into contracts
    • Expectations to be worked into contracts, such as between librarians and publishers
    • Three use cases for Entity Categories (mutually exclusive, one per SP): 


    • InCommon might provide a context for asserting one of these categories. 
    • There could be bilateral agreements that supercede these entity categories 
    • Q:   We don’t want the IDP to send all the entitlement data, just the pertinent info. How should this be handled?   A: Not sure how this is handled, looking to working group members to address this appropriately
    •  Status: Working group is finishing up some fine points on these entity categories. 
    • Then this work will be passed to REFEDS for a comment period
    • Library community and publisher community will review carefully during the comment period 


REFEDS R&S and work of the REFEDs Entity Category Working Group (Chris W and DavidB)

  • The REFEDs R&S profile needs updates
  • There are issues around 
    • Use of identifiers
    • Is an IDP  in conflict with REFEDs R&S if they release more attributes than needed?
  • Should CTAB weigh in on whether REFEDS R&S should eventually be incorporated into Baseline Expectation
  • CTAB has said it will include R&S as a potential part of a future update to InCommon Baseline Expectations . We may want to pull in the categories work of the Seamless Access group, discussed above, and the work of the REFEDs group.
  •  Issue of whether all IDPs can support what might be required around R&S? 
  • Shibboleth can support entity categories, but other frameworks possibly not
  • Any SAML implementation can support attribute release, it’s the entity category that is more challenging
  • SUNET uses  a toolkit to manage attribute release with ADFS
  • Baseline Expectation could be: If an SP requires a certain attribute bundle, the IDP can support that
    • Would be enforced through a dispute resolution process
  • Albert: Possibly we should clarify what attributes the federation expects its participants to support and how to express them
  • Seamless Access bundles are intrinsically bilateral (based  on contracts, with no third party vetting)
  • R&S bundles are intrinsically multilateral (no contracts)
  • TomB: we want to be sure InCommon Baseline Expectations are not too hard, do not require an organization to change their IAM stack in order to comply
  • Rachana:
    •  It’s helpful if InCommon provides guidelines, best practices, even if not included in Baseline Expectations, 
    • the absence of such guidance leads to bilateral agreements 


Baseline Expectations V2

    List  of InCommon participants for targeted outreach around BE V2; contact assignments - Albert

    •  Albert has the list of orgs that  received score of F and below in SSL Lab analysis around meeting encrypted endpoint 
    • done a while back, 179 entities, 67 organizations
    • It’s less than 2% of entities in metadata
    • Shannon is running an updated list and will provide that 
    • Once Albert provides CTAB with updated list, we would like CTAB members to contact the participants to ask them about the proposed BE V2.
  • AI Albert and David will provide info  to CTAB members for outreach around BE v2

  • “Silence” in the BE V2 consensus process does not mean assent 
  • How will we determine we have consensus? 
  • BE V2 Office Hours were held May 5, 2020 and were reasonably well attended
  • Concern that InCommon participants may not be paying attention to the proposal for BE V2
  • Kevin suggests we communicate by email and let people know about last chance to provide input
  • After community consensus comes community InCommon consultation
  • Possibly an implementation plan will draw more attention than a discussion around new proposed standards


 Not discussed on this call

  • Deployment profile - 10KM view and potential future BE Albert & others

Next CTAB call: Tuesday, June  16, 2020

 

  • No labels