Participants: Andrea, Andrii, Brian, Dave D, Dave K, David C, Enrico, Federica, Ian C, Irwin, Jeny, Jim, Julie, Linda, Liz, Maarten, Marcelo, Mine, Petr, Tom, .....

Notes:

• User sync
  • CMS: working OK
  • ATLAS: code development in progress, ETA ~end of this week
  • no further obstacles foreseen for other VOs

• Use of the audience claim
  • specific case: what to do for DUNE EOS at CERN?
  • this was already summarized in our profile document
  • in a nutshell: SE audience == SE hostname / alias
    • the SE code needs to allow real hostnames and any relevant aliases
  • audience can thus be auto-derived by FTS for a token exchange operation
    • and similarly by other frameworks and tools
  • this is also discussed in our vCHEP paper "WLCG Token Usage and Discovery"
    • e-mail thread "vCHEP Submision Final Comments" (sic) has ~final draft as a PDF
  • audience claim is required
  • IAM clients need to request it using the current API ATM
  • at some point we may want to move to the proposed standard for that:
    • https://datatracker.ietf.org/doc/html/rfc8707
    • https://github.com/indigo-iam/iam/issues/381
  • the end user does not have to know about such details (and generally had better not)
  • for stage-out, the token has to be restricted by the submit service before being given to a job
  • how that happens depends on the VO's job framework and use cases it needs to support
    • 1) pilots could be submitted with (coarsely or finely) restricted tokens
    • 2) pilots could obtain restricted tokens from a central service at run time
    • the frameworks of some VOs may need to support both approaches for different use cases
    • for example, HPC WNs may not have outbound connectivity
    • NorduGrid ARC CEs already deal with HPC restrictions since many years
    • ALICE use option 2 at the expense of continually high load on central services
    • each VO needs to decide on a sweet spot between various desirable features
  • HTCondor already has functionality to keep refreshing job tokens of limited lifetimes
  • HTCondor may need some development to support such use cases even better
  • htgettoken already supports restricting the audience
  • these matters will be discussed further in the CE hackathon, June 3-4 (TBA)
    • and possibly in the pre-GDB on Worker Nodes
  • note: ATM we are mostly concerned with submitting the pilots themselves
    • the user payloads can still use X509 proxies

• User tools for dealing with tokens
  • in the GDB on Wed, Will presented how SSH resources can be accessed using IRIS IAM
  • there will likely be a set of tools for different use cases
    • htgettoken, oidc-agent, PAM modules, .....
  • those developments currently are represented in the AuthZ WG
  • we will keep presenting and discussing such tools as needed
  • we will try and aim for common ground where desirable

• WLCG Token Transition Timeline document
  • we mainly started discussing the VOMS-Admin use cases detailed in chapter M.3
  • a VOMS-Admin API service could be added to IAM
    • estimated to take less than 1 week of development and testing
    • as it still is a non-trivial effort, it would need to be defended
    • we go through the list of use cases and see if a critical mass remains
  • IAM can serve mappings to EOS instances that need them (very few do)
  • we are not worried about the DPM clients of our VOMS-Admin services
    • no LHC experiment should depend on that functionality
    • if some instance were found with a peculiar configuration, it can be fixed ad-hoc
  • when VOMS-Admin has been stopped for a VO, it can still be resurrected for a while
    • it just would keep getting staler
    • critical DNs could still be added manually by VO admins
  • to be continued...

Actions:

• none