CTAB Call Tuesday May 2, 2023

 Attending

Warren Anderson, LIGO
Pål Axelsson, SUNET
David Bantz, University of Alaska (chair)
Tom Barton, Internet2, ex-officio
Matt Eisenberg, NIAID 
Richard Frovarp,  North Dakota State 
Eric Goodman, UCOP - InCommon TAC Representative to CTAB 
Mike Grady, Unicon
Johnny Lasker, Internet2
Kyle Lewis,  Research Data and Communication Technologies 
Andy Morgan, Oregon State University
Kevin Morooney, Internet2
Rick Wagner, UCSD
Albert Wu, Internet2  
Emily Eisbruch, Independent, scribe 

 Regrets

Jon Miner, University of Wisc - Madison (co-chair) 
Ercan Elibol, Florida Polytechnic University 
Scott Green, Eastern Washington U
Meshna Koren, Elsevier 
Andrew Scott, Internet2
Ann West, Internet2 

Discussion

• Internet2 Intellectual Property Reminder
  

Working Group updates

• • InCommon TAC
    
    • Discussion after IIW re:Browser Changes (fairly detailed)
      
    • Deployment Profile discussion (how to move forward), entity categories
      
    • SAML vs. OIDC in mesh federations 
      
      
  •  CACTI (Richard)
    
    • CACTI chartered a short-term working group to focus on next generation credentials such as wallets and other verifiable credentials.
      
      • Call for participation should go out in the near future.
        
    • Discussed NIST IAM Roadmap, looking for feedback; it will be helpful to explain acronyms in the roadmap
      
      
  • REFEDS MFA
    
    • Moving back to “no new identifiers” and just clarifying expected behavior of the existing profile identifier
      
    • 180 degree turn
      
    • Clarifying if you signal AUTHNinstant, how to signal timing of authentication
      
    • Expectations for use of ForceAuthn
      
    • ForceAuthn is based on paradigm of how authentication is working
      
    • Can’t as SP make assumptions about what user prompt means
      
    • There is less control of the UI as we get into using various toolsets
      
    • There are various ways of mitigating risk
      
    • Idea of compensating controls
      
    • Perhaps we should wrap around the prescriptions in the draft, wording acknowledging it’s acceptable to mitigate risks in different ways
      
    • Strong authentication and multi factor authentication
      
    • Don’t want to exclude innovations
      
    • Two issues: current group is charged with clarifying the MFA profile
      
    • Core spirit is about the quality of the authentication
      
    • Moving forward we should shift towards quality of authentication, not mechanism
      
    • Baseline Expectation of strong authentication?
      
    • The point of Authncontext is to establish a signal, and there must be guidance
      
    • How finely can you specify what’s required for the signal?
      
    • Hope for consultation in time for TNC
      
    • Need to balance aspirational traits we want in profile with practical implementation issues for parties who are locked into tools
      
    • Want to avoid organizations ignoring the profile
      
    • Most “meaningful” behavior changes likely to remain as “SHOULDs” (not MUSTs)
      
      
  • REFEDS Assurance (Kyle)
    
    • This week’s working group will discuss implications of having RAF 2.0 additive (not fully upward compatible from RAF1.0 in all circumstances) than RAF 1.0, or down-adjusting RAF 2.0 to keep RAF 1.0 fully upward compatible
      
      • specifically, as the draft reads today, an example of the challenge is that if an IdP successfully implemented RAF IAP High using Kantara Classic, they may not be able to claim RAF IAP High in RAF 2.0, as the draft currently stands.
        
    • Will provide update on the decision to CTAB in 2 weeks (next session)
      
    • Hope to end consultation before TechEx
      
      
  • SIRTFI Exercise Planning Working Group (Kyle)
    

• • • Working on survey to community to poll what emphasis areas they’d like to see in SIRTFI training; hope to have this released end of May
      
    • Will ask on survey: what are best formats and venues? And what info will be most helpful?
      
    • Hope to do an IAM Online in July
      
      

 Internet Identity Workshop recap - (Johnny) 

• • https://internetidentityworkshop.com/
  • Week of April 17
    
  • Nicole Roy, Steve Zoppi, Chris Hubing, Paul Caskey, Johnny attended
    
  • Meeting at Microsoft with Google Chrome, Mozila, and other browsers
    
  • With adding new privacy restrictions to browsers it won’t be as seamless as before to log in
    
  • Users may be able to build dynamic allow list 
    
  • FedCM is one approach, helping the user create pairings for what is allowed
    
  • Storing this info a vault
    
  • SAA or CHIPS approach could work; FedCM has some advantages
    
  • CHIPS (Cookies Having Independent Partitioned State) - single key partition changes to a double key partition (access to a 3pc requires two domains). It is a hierarchical cookie jar; only goes in one direction. 
    
    • nature.com embeds SeamlessAccess iframe. The SeamlessAccess iFrame would make the institutional selection parts, and it would write to the storage of nature.com->seamlessaccess.com=[contents]choice. Would need to set the default at each top-level origin. 
      
    • No user dialogue; the sites themselves have to opt in.
      
    • unidirectional (cannot do front-channel logout)
      
    • No changes for this to do what it will do.
      
      
    • Cookie Changes
      
      • SAA (Storage Access API) - the iFrame can get the partitioned cookies for “free” but for more they have to call an API to get unpartitioned cookies which queries the user. 
        
      • also has a permission storage (not just cookie storage) that is double-keyed. 
        
      • It allows access to the things the user allows it to track
        
      • the text has a higher impact on Safari because their implementation specifically calls this “tracking”
        
      • By looking only at domains, it does not impact the protocols
        
      • unidirectional (Cannot do front-channel logout)
        
      • Significant changes to the code required.
        
    • Front-end / JS changes
      
      • FedCM - has a similar result in having a relationship in a database. 
        
      • Not looking at cookie storage. It’s about bidirectional relationship handles. The bidirectionality means you don’t have to give up as much, but the cost is in the construction of the dialogue. To construct the dialogue, there has to be a change on the IdP (it has to expose FedCM specific endpoints). FedCM will ask “is the user logged in and if so can you give me accounts”. When there are accounts, it offers an account chooser. 
        
      • By going into the accounts, FedCM does impact the protocols.
        
      • Larger changes to code and infrastructure (but more likely to satisfy what we need)
        
    • Infrastructure changes
      
      • FedCM would involve some redeployment
        
      • Would this apply beyond SAML? Or beyond, to OIDC and OAUTH?
        
      • Answer: not confined to SAML. Should work for all protocols
        
      • Related to Consent in some ways
        
        
  • Popups from browsers, your application can’t disable it
    
  • Some may find this problematic 
    
  • Comment: can think about this as generic issue of “my browser is doing something I have not given it permission to do” 
    
  • Good for users to know what’s going on
    
  • There may be some jurisdictional issues
    
  • In some cases lobbyists can drive regulation
    
    

For Reference: CTAB Workplan InCommon CTAB 2023 Work Plan

Operationalizing BE - progress review  (item 3 on CTAB work plan) 

• • See Slides
  • Track how organizations  are doing with meeting Baseline Expectations?
    
  • Tracking should be ongoing, on annual or semi annual basis
    
  • This should be informational, cooperative process, aimed at helping orgs to keep up with baseline expectations
    
  • IAM staff changes, so it’s good to make people aware 
    
  • And good to be sure InCommon is aware of new staff, especially SysAdmins and Exec contacts
    
  • Much in Baseline expectations is done via attestation
    
  • Some automated testing, such as for web security protocol
    
  • Try to leverage Federation       Manager where possible 
    
  • UI/UX reports from automated testing can be a challenge
    
  • Warren will email the CTAB email list with a link to the worksheet, encouraging CTAB   to review the Operationalizing BE worksheet and provide feedback
    
    

 Federation Readiness  (item 4 on CTAB work plan)

• • what are the use cases in which we would like to see greater maturity?
    
  • Helping (non-IAM) software vendor incorporate better federation interoperability
    
  • IAM lifecycle mgmt
    
  • Managing user information release 
    
  • Dealing with “assurance” of all sorts -> id proofing, authentication, etc
    
  • UX and federated access support best practices
    
  • Security issues
    
  • Chartering Working Group - next steps / focus on discovery/identifying the challenges/use cases
    

Next CTAB Call: Tuesday, May 16. 2023