Present: Tom D (notes), Linda C, Dave D, Maarten L, Julie M, Martin B, Petr V, Enrico V, Roberta M, Andrei T, Mischa S, Alexandre FB, Francesco G

Apologies: 

Previous Actions:

• A pull request to be opened to implement prototype/experimental token renew descriptions, from 23/03: https://indico.cern.ch/event/1262265/
  • Dropped as this has been decided to move away
  • Making a shell for renewal
  • Potential for a user-level SystemD service to get a token for a user
    • Doesn't need to do anything special/things in parallel
    • A simple user-level solution may be simpler
• Ticket handling, and ticket disappeared due to auto-cleanup - to be followed up offline

Proposed agenda:

• CHEP Recap and Paper
• Issuer/VO information in tokens

Discussions:

• IAM 1.8.2 release for CERN?
  • IAM released for 1.8.2 last week
  • To follow up with upgrade - allow the IAM dev team access to support upgrades, to be discussed with Berk
  • this will allow the IAM team to help sort operational issues
  • To follow up with Hannah after her leave
  • Petr to email/open ticket to look at in the future
• Token Rates
  • Seeing a lot of improvements through improved configurations
    • Token rates up from 100hz to 600hz
    • CNAF team looking at DB improvements and methods to avoid the DB (ie not storing access tokens)
  • High rates are possible - and directly connected the the lifetime of a token
    • However services should consider the affects of downtimes - can your service survive an hour outage if it happens
    • lifetimes can help reduce rates for some scenarios
  • Understanding how rates and lifetimes link through testing to Ruico and FTS
    • A note from Martin - not always connected to lifetimes. If your tokens are fine-grained, then you will have much higher token rates
    • Could have more generic create/read tokens, but modify/delete will need to be more specific and fine grained
  • Big step away from X.509 VOMs proxies - directly confronted by the type of credential needed for a specific option, no longer "the" credential
  • Can reduce the power by splitting on tasks
  • Focus is tuning, and understanding tolerance on service side should there be a glitch
  • Want to avoid causing more operational issues through use of tokens - the intention is that operations must profit from tokens
  • aim to converge soon on somethign feasible for DC24