Participants: Julia, Andrea, DaveD, Enrico, Federica, Irwin, Jeny, Jim, Julie, Maarten, Mine, Marcelo, Mischa, Panos, Enrico, Jeffrey, Linda

Notes:

• User mapping between accounts (e.g. CERN login and X.509)
  • Issue is mapping between grid identities and CERN accounts (for which user type?)
    • Particularly relevant for EOS
    • Users will need to access EOS from both Grid workflows and logging in directly to EOS/Cernbox
    • EOS will need to be able to map X.509 and cern logins to the same user
  • Existing X.509 certificates will be pushed to IAM
  • Users also have the possibility to link further certificates
  • Information about all identifiers for a user is available via IAM API
  • Already being used by ESCAPE research community
  • Any service that needs this information will need to be a registered client in IAM with certain permissions
    • They will get a clientID and secret that they can use indefinitely
  • See https://indigo-iam.github.io/docs/v/current/user-guide/api/scim-api.html
  • Is this (the IAM API returning linked accounts for users) sufficiently generic elsewhere?
    • Fermilab experiments are using CiLogon
    • Fermilab users at CERN experiments will be able to link certs and have a CERN account
    • If there's a hybrid model without a single IdP (e.g. DUNE have both CERN and Fermilab) we might need to check further
• VOMS migration being tested
  • IAM requires a unique email for users
  • Merging is not a safe choice
  • For ATLAS some information would be overwritten, accounts have the same email but different nicknames
  • Could alternatively take the first account as the correct one and ask VO Admin to check the other details
    • ATLAS & CMS each have about 80 accounts that share an email
  • Alternative (requires development) is to support secondary and service accounts
  • Having the concept of service & secondary accounts in IAM may be nice
• Fail handling on scope requests
  • Capability sets should be a set of essential (not optional) capabilities -> if they are not all authorised then the request should fail
  • If a capabilityset is granted it MUST be the whole set. If it is not granted an error SHOULD be returned (with a useful message).
  • This is kind of re-implementing the VO roles
  • We should be consistent between groups and capabilitysets 

Actions:

• Andrea add a Jira ticket to consider service and secondary accounts in IAM
• Andrea produce list of duplicate accounts for CMS, to be passed to VO Admin to see whether many of them could be de-dup'd 
• Dave to add some clarification text to the PRs
• Hannah to add continued discussion to next time's agenda
• Maarten to clarify whether the timeline under discussion only affects CMS or the four LHC VOs?