Attendees: Hannah, DaveK, Jim, Maarten, Julie, Linda, DaveD, Mischa, Ian, Andrea, Brian, Mine, Paul
Apologies: DavidC, Tom,

Notes: 

• Hannah to recycle presentation and send around link to mailing list
• ARC
  • Send an email to work out what's going on/offer help
  • Would be good to hear what they are doing
• VOMS admin deprecation
  • Don't have a plan that's well known
  • Dates proposed in GDB sound reasonable i.e. end of 2021 could be slightly early as we don't have experience with the system at scale but may be possible
  • Meeting with ATLAS last Monday that defined some technical details of missing features. Probably need to do the same thing with other experiments.
  • CMS missing details on how IAM can interoperate with VOMS, how synchronisation is managed
  • Scalability & throughput, can we do more? Requires an estimate of number of clients etc.
  • Once we've made the decision to move to IAM, the VOMS component needs to work as well as the old one. Can we add the IAM VOMS as one node in the existing VOMS setup?
    • Complex since different backend DBs
    • Can test VOMS backend at scale, we already have the numbers
  • Not able to get a CERN Grid Host cert for openshift machine (policy block and maintenance only mode), solution could be to move to openstack but we lose many benefits of scaling from openshift. Can deploy a kubernetes cluster on Openstack for the VOMS attribute authorities
  • Other concern is operational team at CERN. This would change to be in IT-CDA but the new team needs a bit of ramp up
    • Would still like input from Andrea as key developer
    • Formal collaboration agreement between CNAF and CERN
    • Tools are familiar to CERN team 
    • Should get more involved in e.g. upgrades
    • Potentially install LHCb instance independently
  • Synchronisation script, how does this work?
    • One problem is translation between VOMS roles and optional groups
• Fermilab plans to move to tokens before VOMS admin is decommissioned 
  • Fermilab VOs would no longer support X.509
  • More important is to ensure that the entire middleware stack and resources can support tokens, before stopping support for X.509
• MyProxy
  • IAM allows a user to register a proxy cert in their account, which can be retrieved via a token
• Looks do-able to have no X.509 cert dependence at end of run 3
• Mixed authorisation models
  • Require extra text to clarify what resource providers should do in case of conflict? Effectively anything sensible is ok, add a few examples. RPs can choose what they don't want to understand
  • This is expected to evolve
  • e.g. CMS may choose mostly capabilities, LHCb may choose mostly groups
• We need a way to get all (or a subset of) capabilities based on a group/role. We should standardise this semantically so that clients can share libraries etc. 
  • We have the same thing, effectively, for groups (wlcg.groups)
  • Possibly use a different scope (i.e. not storage:/*)
  • This would solve PR 6 https://github.com/WLCG-AuthZ-WG/common-jwt-profile/pull/6
  • Use case, we want the client to use the same scope request for each person. This means that the token issuer needs to include all the logic per person, per client (e.g. must know your home directory).
  • There is some cut off between the benefit of capabilities for complex namespaces/paths/logic and using groups instead
  • A role/group maps to a set of capabilities
  • The scope needs to be a separate namespace (not one of the capabilities ones), e.g. wlcg.capabilityset:analysis -> this could be mapped to return whatever makes sense (i.e. capabilities or groups)
    • wlcg.capabilities ?
    • wlcg.role ?

Actions:

• Hannah draft AEGIS presentation
• Hannah send email to ARC
• Hannah send email to clarify technical limitations of openshift grid certs
• (hold) Andrea to follow up moving VOMS attribute authorities to a kubernetes cluster on Openstack
• Dave to add comment to PR 6 and discuss with Jim
• Hannah to schedule the next call for after Christmas