• Assume that (at least physics) workflows all go through a workflow manager
  • Sven: make sure that direct submission is not possible in that case
• Having a refresh token on the WFMS is not ideal fpr several reasons
  • Petr: too many token requests to IAM (believe that it cannot handle the throughput) 
  • Luna: only know if IAM is available at the point when you want to refresh (at that point it's too late) 
• No list of trusted token issuers permitted on the grid. This is done by the experiment publishing which issuers it uses. 
  • What should an issuer need to do to get on this list? Several policies. 
  • Luna: Such a list could also be used for revocation? Revocation of an entire issuer (would require a semi automatic way for software to read the list)
• Token issuer can effectively block itself by stopping publishing its JWKs
• Mischa: Suggestion that JWKs be hosted separately to the issuer - benefit to security as otherwise JWKs would be compromised at the same time the issuer compromised
  • Maarten: Brian B has also suggested a CDN
  • Mischa: SciTokens puts them in github
• There should eventually be 1 token issuer per VO plus probably issuers for WFMS
• Several solutions proposed for issue of how to do tokens for aynchronous workflows
  • Very long tokens (not ideal for security)
  • Local token issuers for the WFMS 
• Could you have a future token? No, can't know when a job will run 
• FTS = 3rd party copy. Flow for writing also requires reading at the end to make sure it worked fine. 
  • Identity of DDM is used 
  • Some difference of opinion on whether an individual user could be blocked inside a DDM or WFMS
• DavidC: for central suspension we need to be able to tell all token issuers not to issue for a particular user
• Marcus: one way would to have long lived but revocable access tokens
  • This can be expensive and increase load on the issuer (if the same process) 
• WFMS issuers should be constrained on audience, scope etc to mitigate risk
• In WFMS we are talking 200K running jobs. Status sent every few minutes, need a valid access token. 
  • If the compute node is talking back to WFMS every 10 minutes why can't it do a refresh flow at the same time? 
• Could refresh tokens not be stored in the data base? Perhaps with signing, but this is not commonly done
• Enrico: shouldn't this be a client credential rather than a refresh token? Possibly the wrong workflow. Client credential could be passed around the infrastructure and used wen required to get an access token. 
• Whatever gets put onto the grid needs to have a finite lifetime (client credentials current don't)
• One of the initial aims was to use standard solutions - but perhaps we've done all we can and after a certain point within the infrastructure we will have to do our own thing
• If we are doing something proprietary, how does that affect downstream parties (e.g. sites or EOSC compute or cloud). If we are non standard we will potentially lose them.
• It is still not clear exactly what performance would be required of INDIGO IAM (and by when) to avoid experiments doing workarounds
• We should escalate things to the OIDC Federation where possible to make it part of the standard
• We have to GUT working group to try and get to a unified OIDC standard, which should help integration
• Trying to extended the standard may actually help as additional expertise would join
• What would be out of the standard spec? Spec is very flexible
  • Access token revocation not done at the issuer
• How is middleware defining who to trust? Manually adding it to their config
• Anyone creating a token issuer should be aware of what policies it should follow
• Raise github issue to externalise JWK endpoint in the well-known endpoint? for several reasons: 
  • Don't rely on IAM to be up to validate the tokens
  • Can block an issuer without the input of the issuer
  • However, this does shift the risk to wherever the JWKs are hosted
  • or use RPMs for this? 
• What performance needed for INDIGO IAM? Perhaps we can make this possible, collaborate with SKA ? Separate low throughput attribute authority from high throughput access token issuer 
• This is fundamentally a cost benefit analysis, with experiments more likely (in some cases) to trust issuers that they run themselves

Actions

• DavidG DaveK Hannah (and others?): Write a page of what policies are required for a token issuer and share with TTT working group
• Petr/Maarten: provide required performance for IAM (potentially for a few models) and a timeframe for Berk/Enrico to analse faesibility 

"Thank god X.509 is still there" - M L