Participants: Hannah, Andrea, DavidC, DavidK, Brian, Dave, Enrico, Irwin, Jeffrey, Jeny, Jim, Julie, Maarten, Mischa, Petr, Marco

• ARC
  • We already have defined workflows for other software, we probably need to involved them in the DOMA group
  • We should understand whether they need anything non standard, e.g. exchange
  • https://www.nordugrid.org/arc/arc6/misc/oidc_tokens.html
  • Probably similar to e.g. HTCondor work, mostly done in the US
  • Need discussion on which scopes should be required
  • Future Hackathon to focus on token propagation workflow
  • We should have a future meeting where HTCondor etc present
• vCHEP
  • DaveD to submit on command line
  • Andrea to submit contribution on IAM evolution
  • CERN SSO team submitting as well (could include WLCG IAM instances)
  • What’s left?
    • Bearer token discovery
    • Token flows for managed data transfer (DOMA TPC)
• IAM Users Meeting https://indico.cern.ch/event/970568/
• ID Token Claim for Kerberos
  • You need a claim from an OIDC token to map to a kerberos identifier
  • Must be unique and can map
  • For CiLogon have created a new claim called vault.uid (possibly better to rename, easy to change)
  • At Fermilab also want to be able to map to robot principals. uid/something/something 
  • CiLogon token issuer is removing @fnal.gov when token is coming from FNAL IdP (robot support)
  • We need something similar for CERN, CERN SSO must forward an identifier that IAM can forward inside tokens (i.e. hshort@cern.ch)
  • Probably best unique ID is coupling of issuer + subject
  • Suggestion for vault to store a mapping to go from uniqueID to kerberos claim, not rely on the claim being the same as the kerberos principle directly 
  • CERN SSO should release a claim that contains the kerberos principal (only for valid users)
  • preferred_username is not a good choice for a persistent claim (From https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims "The RP MUST NOT rely upon this value being unique, as discussed in Section 5.7.")
  • Current system propagates HR name changes (e.g. middle name removal) which causes bugs down stream with DNs
• Capability Set PR
  • Need a few lines on motivation (i.e. client doesn't know which scopes to request, perhaps scopes are templated for the user)
  • May not be trivial to implement
  • How to remove scopes? Suggest that should not be included as rather complicated
  • Deduplication
  • What happens if issuer doesn't understand the capability set? How can we let the user know that the capability set was not granted fully?
  • Capability set coming back as an aggregate might be a future point to discuss
  • Jim - we also need to define the iss claim (complex in multi VO issuer) 
• Comment from Brian, can we avoid using WLCG in schema? (for next time)

Actions

• Hannah start Google doc to gather thoughts on token propagation workflows (done)
• Hannah to start CE scope requirement discussion on Github (done)
• Brian send URL about how to contribute to Globus retirement
• Hannah set up Overleaf for vCHEP submission (done)
• Andrea forward IAM Users Meeting invitation
• Hannah, DaveD and Andrea set up CERN SSO claim that can contain kerberos principal, and define claim name
• DaveD add examples/motivation for why capability set needed, e.g. production role, multi-VO issuer
• DaveD to add grammar rules for capability set 
• Hannah send update on IAM transition to CERN progress (done)
• Hannah schedule next call