Present: Angela C-B, Tom D (Notes), Dave D, Xiaomei Z, Alexandre B, Thomas H, Petr V, Dimitrios C, Maarten L, Julie M, Roberta M, Mischa S, Linda C, David K, Mine AC, Hannah S, Berk B, Brian B, Andrei T

Previous Actions:

• Ask CiLogon how they do token verification - offline or introspection (Jim or Jeff)
• From Jim:
  • CILogon signs JWTs for offline validation and also provides an introspection endpoint.
  • For what it's worth, SciTokens requires offline validation and does not support introspection. In my opinion, introspection is a poor fit for our distributed research infrastructures. For this reason, I have lodged my objections against the AARC-G052: OAuth 2.0 Token Proxied Introspection specification. I think the WLCG AuthZ WG should recommend against using introspection.
    I think the OAuth specifications recommend short-lived tokens even when using introspection. Revocation should be a last resort.
  • AARC G052: https://docs.google.com/document/d/11Amv6kjPvVVgWB71iEaj6NcrhlNzht7HP9GJK6cNOS8/edit 
• Need to make a stance about lifetimes soon
   
• Dave K: VO information comes from issuer - does this help prevent that information being lost
• Inferring membership from the issuer is not straightforward
• Not a problem as the issuer should be tied to the group - checkin should need to put the VO in the token, so that the specific place in question is identified. Not an issue for single-VO service
• Need to understand what specific combinations authorise
• Key requirement is the need to maintain business as usual
• Currently addressed in the WLCG profile in a very black & white manner - concrete definitions
• This is less clear with something like EGI, where the VO must be determined from the token contents rather than just issuer and subject
  • Some work needs to be done to understand the issuing authority - a more elaborate mapping is needed for EGI Checkin tokens, for example a plug-in call-out ton HTCondor and ARC CEs.
    • From Nicolas Liampotis, after meeting:
      The VO information is encoded in eduperson_entitlement claim values with the following syntax: "urn:mace:egi.eu:group:<vo_name>:role=member#aai.egi.eu". 
      For further details, you can refer to Section 1 of this document: https://docs.google.com/document/d/1q67BWeFBmFmQ0crG5bVWwqecVMdN8PROYnciHO5JhRo/edit#.
    • From Dave D:
      Note that the https://cilogon.org/fermilab token issuer also encompasses multiple VOs.  We distinguish between them primarily through the paths in scopes, although we also have different wlcg.groups.  HTCondor does not need to distinguish between the different (sub)VOs, and just treats them all as a single VO.
  • in WLCG the issuer is the vo, where EGI the VO is the top level group, and a token claim
• Access to ARC & HTCondor using EGI Check-in tokens: https://docs.google.com/document/d/1q67BWeFBmFmQ0crG5bVWwqecVMdN8PROYnciHO5JhRo/edit#heading=h.ropcuc1skhp5 
• Brian: the above could be the base, but is not clear. Will need refining, but could be the basis of a profile that sites adhere to

Proposed agenda:

• Recap and review of auto-renewal of access tokens
• Dave: short lived access tokens for interactive use. Due to only lasting a few hours in an interactive session, we need to work out how to make sure it works well for users, and so that users do not need to use commands frequently
  • Two options:
    • The tool (eg Htgettoken) has a background refresh. This means that, if told to, the tool gets a toke whenever a new one is needed until informed the job is completed
      • Requires fewer tool changes
      • Complications around if someone tries to renew the same file for multiple processes - can become complex
    • Add to the WLCG bearer token discovery. This could look for another environment var, such as bearer renewer, and can execute this whenever a new token is needed
      • Cleaner, easier to implement and more user-friendly
      • "Lots of Dragons" - due to the requirement of a command to be ran on the host
  • Maarten: not too worried about user's yet - WCLG can benefit from experience of others
  • No decisions made previously due to limited audience 
  • Would need tools to process the environment variable, if the second option is chosen
    • Requires launching a process on behalf of a user, which in turn poses risks
    • Environment variable which is executed by the tool
    • Issues with if this sneaks past end-user into other tools
    • avoid creating a workflow where this is ran too trusted
  • EOS implementing bearer token discovery token, which must execute on the host as root
    • Issues with command/env variable there
  • Hope to learn and imitate lessons from OSG
• Brian: is it possible to label this as experimental, so as to be clear it's "not right first time" - meaning others can understand and be informed
  • Provide guidance such as we should say that this MUST NOT be used if stdout/err isn’t a tty
  • Avoid future collisions
  • Concern around naming something such as "BEARER_TOKEN_RENEWER" runs the risk of not allowing tweaks and changes, due to things using the "final" name
• Action: A pull request to be opened to implement prototype/experimental token renew descriptions

• Recap of client credential github issue - discussion seems to have reached a conclusion
  • Will need some way to modify the process to allow a client to belong to a group
  • This would be a better way than forcing the group as a scope
  • Github issue: https://github.com/WLCG-AuthZ-WG/common-jwt-profile/issues/24
  • Brian: worry about being too prescriptive - guidance rather than saying what you can/can't do
    • As it stands within the WLCG setup, the Client cannot be a member as part of a group
  • Client Credential flow may not satisfy traceability requirements - need to make sure the VO has a responsibility someone is responsible for the Client Credential flow.