Present: Hannah S, Tom D (minutes), Matthew D, Maarten L, Petr V, Dimitrios C, Jim B, David C, Paul M, Berk B, Jeff G

Apologies: Dave K, Linda C, Francesco G + INFN team, Dave D, John SdS Jr, 

Previous Actions:

• Action, Maarten: Start a discussion on the Mailing list late August to revisit and converge on a plan once summer holidays are more likely to be over

Notes:

• Paul: Lattice QCD - similar issues, looking to utilize the WLCG profile as the route through which they will communicate information. 
  • attempting to encourage their engagement here, and notes the niceness of things being shared more widely
  • has been assisting where needed - team is situated at DESY with Paul
  • Maarten: notes that the profile is "not crazy" - just has a few places where decisions have changed, or where requirements have changed
  • Encourages Paul to let them explore and learn to find where issues are
  • Petr: will they be using group or scope based authn? Notes an ambitious timeline
    • Paul: scope - particularly interested in fine-grain aspects
    • Some clarity lacking from the details
  • Maarten: is the software stack similar or different?
    • Paul: seemingly completely different, though some similarities (eg dCache)
    • Notes they have interest with how things would work with cloud solutions such as amazon 
    • Conceived flow involves a permission-less token being exchanged for one with the required scopes and then returned to the user
    • Currently control both the server and the client, and so can do whatever they want (within limits) - this means that they can return the user a pre-signed URL rather than a token as a short-term fix
• Petr: preliminary timeline for VOMS servers, tied to end of Centos7 - CNAF do not want to port the VOMS(-Admin) services to EL9
  • VOMS proxies will remain available from IAM
  • Maarten: could be a good opportunity to cleanly say goodbye to VOMS(-Admin) services
  • Discussions started and belief is that things will be okay, but notes no firm deadline at this time
  • Aim is to have things satisfied by IAM instances and have these take over from VOMS
  • Looking into robustness of the IAM instances
    • Laurence Field pointed out that there is only one VOMS endpoint per IAM instance, which is down from two with the old instances
    • Lacks the client failover currently in place
    • Opportunity to redo some things we have issues with - for example, moving from OpenShift to deploy directly on Kubernetes (which has been tested by Berk)
    • Would prefer depending on Kubernetes rather than Openshift, though this would lead to an need to change hostnames and a campaign to facilitate this
      • Aim to run both together to aim for transition
    • Petr: new name for VOMS server is annoying, but can deal with. "CA" rotation - is it possible to do this with just one hostname?
      • If chain is changed, must redeploy LSC files. 
    • Do the previous reasons to keep two VOMS services still apply? If the IAM service is sufficiently highly available, we should be able to simplify configuration through a single endpoint
    • New and other VOs can be given IAM instances directly on K8s to gain experiences in production environment, which then can be followed by the LHC experiments
    • Petr: what's the timeline for K8s deployment - could we just kill the existing LSC files and use new instances?
      • Maarten: yes, we could profit from this but it would mean targetting the autumn - especially with aims around DC24
      • Test with Ops or DTeam VO to see how things work
      • Berk agrees with the timeframe - the first dev instance will be ready by Autumn
      • Maarten: this will be returned to from time to time - target a first milestone for a non-idle K8s VO to understand how things operate
      • Potential to use ALICE as a guinea-pig, as they are the least concerned with IAM abilities
      • Move forward from there, targetting a stable deployment by DC24
  • Petr: does this affect just VOMS-Admin?
    • Maarten: no, also the VOMS service - attached to the Centos7 EOL. After July 2024, everything is switched off entirely with the OS
    • Petr: notes that this will lead to OSG having to switch to tokens by the summer also 
    • Maarten: Francesco does not think it's a major deal, but notes there are always some changes (e.g. major OpenSSL upgrade) that they would rather avoid spending time on, if they can.
    • Petr: notes the ambition of OSG, and how the timeline may be affected - whether DUNE will be able to fully rely on Tokens in one year's time
    • Maarten: if there appears to be some showstopper in spring next year, the matter could be reconsidered; OSG have been using their own fork of VOMS and might even look into an EL9 port themselves, if it cannot be avoided
• Paul: having made a number of PRs, but curious at what point is it acceptable that we accept a specific PR?
  • Maarten: depends on context.
    • Small, or non-controversial things should be able to merge without involved effort
      • if 1 or 2 people confirm the change looks OK to them
    • More involved or detailed things my need further discussions
    • And if something is excepted in error, we can look back and roll back as required
  • The person committing should agree that the request should not make things worse, but ideally should be verified by a second person
  • Reviewers should be able to request reviews from specific people - this would likely block a PR until a decision has been made
  • Paul: notes dCache doesn't follow things completely (notably the union case), and investigating test cases is what prompted the review and questions
• Paul: Group Membership - currently have the wlcg.groups claim, but independent of that there is AARC and the groups membership representation
  • Interesting here is that the AARC solution is being adopted by different communities and different environments. 
  • Being adopted by Helmholtz in Germany - they have implemented the AARC profile, as has EGI Check-in
  • Is there appetite for convergence here?
    • Maarten: this would help with our VO identification issues, as the AARC profile makes the VO clear in the token
    • This would simplify things for developers, as groups are more consistent - would make things consistent/interoperable
    • Aim to avoid painting ourselves into a corner, making accounting more difficult
  • Hannah: is there a comparison between the sizes of the tokens with the extra syntax?
    • Maarten: not currently concerned
    • Petr: should be concerned, as there is a limit on the size - if the token is large this could hit the IAM token size (3kb)
  • Paul: work in progress around the jwt.groups claim - noting it returned the AARC groups
    • Bulkier part of the group is defining the namespace - which is defining the VO
    • If we do not use the issuer as the VO, we will need something to define the VO in the group, as AARC does
  • Paul: noting existence of AARC-Tree, asking if there is engagement
    • Asking about convergence, Hannah noted that CERN (her and Berk) and STFC (Tom, Dave K, Dave C, etc)
    • Hannah noted that in AEGIS (where things are approved), WLCG are somewhat of underdogs compared to others, but can contribute 
    • Should aim to converge on AARC guidelines where possible 
  • Hannah: to request Maarten to be added as a CERN representative for Aegis