Present: Tom D (Notes), Stephan L, Maarten L, Francesco G, Enrico V, Matt D, Dave D, Dimitrios C, Berk B, Roberta M, Federica A, Mine AC, Julie M, Angela CB, Petr V, Doug B

Apologies: John SdS, Mischa S

Previous Actions:

• Action, Maarten: Start a VO information in token (for accounting purposes) discussion on the Mailing list late August to revisit and converge on a plan once summer holidays are more likely to be over
  • Completed - follow up in GUT WG.
    
• Action, Mischa: Mischa to look to setup a "neutral" mailing list to facilitate cross-community discussions around unified token profile
  • Completed - email inviting WLCG AuthZ to register has been sent

Proposed agenda:

• Token Profile: Open Issues and PRs
  
  • https://github.com/WLCG-AuthZ-WG/common-jwt-profile/issues
     
  • https://github.com/WLCG-AuthZ-WG/common-jwt-profile/pulls

Notes:

• Various changes and discussions around developments to the token profile, but not published - notably the development of Capability sets corresponding to sets of scopes based on group memberships.
• Another notable change is disussion around handling cases when both groups and capabilities are present - not handle the union of these, and instead take capabilities as preferred.
• Maarten encoruages the group to go through and review and comment any issues you may have
• The aim is to then close these in the coming weeks, in order to publish a new version early 2024
• There are also a number of open issues from ~August. These highlight ambiguities or issues with existing wording
  • Suggestions are in pull-requests with discussions in those comments
  • The majority of these should have easy resolutions
  • Some larger issues could be postponed for a later version.
• Proposal is for an updated V1.1 of the document
  
  • The plan is to publish on Zenodo and similar, and demonstrate that 1.0 is superseded
  • This should not have a 2.0 version, as it does not break anything detailed within the published 1.0 version
  • In order to avoid deployment issues, Maarten suggests we avoid changing the profile version number when working on backward-compatible issues
• Suggested targeting before the end of March for new profile version

Token Lifetimes in the profile:

• Maarten shared the view that the existing lifetimes in the profile are unimplementable, and rather that a certain range may be desirable
• Potentially previously dominated by pure security concerns around lifetimes without considering operational concerns.
• Looking for the middle ground between shorter secure lifetimes and longer lifetimes for operational usage
• We should make sure to use other tools to control the danger of stolen tokens - notably the scopes and the audience 
• Maarten will open an issue for further discussion on this topic
• Francesco: are the lifetime concerns related to issuing rates?
  
  • Maarten: not really, the current rates seem acceptable
  • the intention should be that experiments do not rely on high token rates
  • Operational stability should mean that if there is a 2 hour downtime, there should not be any obvious major fallout
  • And the length of tokens here should consider the different workflows each experiment may require
  • Aim for a set of ballpark figures and refine these per workflow
  • resultingly - the profile needs an update to detail that this reasoning is being considered

AOB:

• Potential DC24 discussions?
• IAM has been updated to 1.8.3
  • Enrico: have there been any tests on how the new version performs in production?
  • Berk: not done any major tests yet, but can do some and check and report back
  • Maarten: notably it at least did not get worse! 
  • A lot of implemented fixes were usability or bug fixes
    
    
  • Maarten: is there a reason why 1.8.x and not progressing to 1.9?
  • Enrico: holding 2.0 for when MITREid dependency has been removed
  • Francesco: noting that there are other dependencies to be removed as well
    
    
  • Stephan: notes that getting pattern handling and matching in place for a 1.9 release, so as to start working on storage areas for users
  • Francesco: something reperesenting the user name within the path for storage 
  • Maarten: noting that the profile will need to be updated to relfect this, and a parallel issue should be opened within the profile.
  • Francesco: agreed. Also in favour of standardising existing practices within this area, and looking for proof of concepts before working on the profile
    
    
  • Maarten: Steve from FTS team was playing around with the IAM instance for DTeam, and found that the setup was excessively permissive.
  • Found that he was able to anonymously set up a client, and then obtain various scopes as they were unprivileged.
  • This was due to the allowance that anyone who is a member of DTeam should be able to obtain these scopes.
  • However at this stage, anonymous clients cannot be blocked
  • As a temporary measure, the storage, compute and fts scopes have been restricted.
  • Patch developed so that the client credentials flow can only be used by members of the VO, i.e. registered users
  • No releases planned before DC24, to focus attention on changes needed for that.
  • Potentially make a release candidate for just this change, and then this docker image can be used where needed
  • Stephan notes that this may be different for different IAM - CMS does not protect read, where ATLAS does.
  • Suggestion to not rush this, and allow focus on DC24 potential issues and primarily target post DC24
  • DTeam could look at trying before DC24 if a release candidate is made available
  • To be followed up offline, and to be reported next meeting