Participants: David C, Sven, Linda, Julie, Hannah, Mischa, Maarten, Jim, Jeny, Andrea, Petr, Tom, Romain, DaveD, Federica, Brian, Enrico, DaveK, Jeff, James

Notes: 

• Overriding security concern is traceability i.e. tracking activity. Made harder with dynamic environment
• User activity traceability
  • Split traceability (pilots hide information from sites, VO and site must collaborate)
  • Opaque tokens typically have randomly generated strings. We are really thinking about privacy preserving tokens with non-human-readable subjects 
• Token issuer
  • Tokens contain history of issuers and accrue history (how can we get at this data)
• Central suspension
  • We are missing site level blocking for tokens (Argus)
  • Possibly with short lived tokens we are less exposed to risk, if user is blocked centrally then fairly quickly cannot perform actions
  • VO level token blocking would be equivalent of suspending DN at the VO level (but works faster).
    • However, there is no cross-VO blocking (which sometimes worked for X.509)
  • Can we purge currently running jobs? This is a secondary activity.
  • Central suspension = user not able to get more access tokens 
  • Have not been incidents that required immediate purging of jobs. Such tools may need to be tweaked for token based infrastructure. 
  • Even big sites always had problems blocking users, was very over-engineered. Critical that suspension in new model is simple
    • Much stronger choke point at VO level
    • Suggestion that security team able to block at each VO's IAM instance
  • When user suspended, token issuer stops issuing new access tokens to them
  • Do we need JWT security event tokens?
    • If spanning multiple federations, how do we tell others that an identity should be suspended?
    • Might be a secondary question, focus on blocking for WLCG
  • What done in OSG?
    • Rely on VO's ability to handle users 
    • Eventually may block the full VO if response is inadequate 
  • Focus on good procedures rather than tooling
  • Relationships disappear with people, need to design procedures that allow new people to execute.
  • Jeny proposes separate security tabletop exercises (traceability & security incident) 
    • Call out to the different security teams to document current security capabilities to be able to adjust expectations with tokens (whilst workflows are being finalised)
    • Aim to have multiple tabletops (DavidC happy to organise)
  • An API for blocking may be useful, avoid having additional admins in IAM instances & going through training. Could just pick up a list of blocked user IDs from a trusted endpoint. 
  • Work ongoing for workflows (CEs and delegated transfers), sensible to have a tabletop when ready and only then write an API
  • Previously just put DN in a ban list and it happened (sometimes), do we introduce more conversations in the new model
    • VOs and sites always had the final word (could always be overwritten)
  • VOs running with few identities risk having the entire VO switched off
• HTCondor Audience Values
  • There is an RFC https://datatracker.ietf.org/doc/html/rfc8707#section-2
  • We provided guidance in the profile, maybe the profile is not clear enough (i.e. URI) https://zenodo.org/record/3460258#.YVXBji0RoUF
• IAM deployments
  • Aiming for Monday but trying to do things properly, aiming for common configuration before deploying instances for ALICE and LHCb 

Don't forget the token transition workshop coming up: https://opensciencegrid.org/events/Token-Transition-Workshop/ .  It's a touch OSG-centric but of course, all you folks are welcome!

Also please don't forget WoTBAn&Az 2021 (https://opensciencegrid.org/events/2021-NSF-Cybersecurity-Summit-Workshop/) the following Monday. We'll be posting the schedule (including the WLCG AuthZ presentation) at https://sciauth.org/workshop/ soon.