Present: Angela C-B, Tom D (Minutes), Dave D, Stefano DP, Maarten L, Francesco G, Hannah S, Federica A, Berk B, Matthew SD, Linda C, Mine AC, Julie M, Petr V, Dimitrios C, Roberta M

Apologies: Dave K, John SdS

Previous Actions:

• Ticket handling, and ticket disappeared due to auto-cleanup - to be followed up offline
  • Resolved by Maarten

Agenda: 

Nothing proposed ahead

Raised:

• Groups for accounting and VO info in Tokens
  • Do Groups need to be adjusted, do we need a different way for VOs to be communicated
    Does Fermilab need issuers for "sub-VOs" - issuers under the Fermilab VO
     
  • Need to have something within the token, beyond the issuer, to identify the VO - as in the case for EGI Check-in
    Need to consider methods to give more flexibility
     
  • If we go in the direction where everyone needs their own issuer to be accounted correctly, then this will become cumbersome with large numbers of issuers
     
  • Petr: do we know what EGI will use? is this their own groups or something else?
    Maarten: there is an attribute within Checkin which does communicate VO - eduperson_entitlement
    Francesco: eduperson_entitlement is a more verbose way of doing groups, not VO affiliation
     
  • Hannah: there is an AARC guideline on how to express this
    How does this work for IRIS in the UK?
    Tom: IRIS conveys VO membership via group hierarchy - but this works due to only using a single issuer, and so may not completely map to WLCG
     
  • Maarten: to be careful about making decisions whilst key people are away
     
  • Francesco: we could look at more simple ways to host issuers for smaller communities?
    Maarten: Works for WLCG, but not the same for CILogon
    Dave: Can add more by adding to Fermilab, while creating a new issuer is a more heavy-weight process
     
  • Tom: Entitlements, the root group conveys the VO
    Could this cause risk of clashes?
    Maarten: this should not be an issue, if the information is parsed correctly, but would the need for such parsing be deemed acceptable?
    Currently relying on issuer to convey the information - information is signed by the issuer, and anything "harmful" is a configuration or middleware issue
    If we do away with just relying on the issuer to indicate the VO, then the issue could be more pronounced
     
  • Ordered vs UnOrdered groups claim
    Methods of determining VO may depend on ordered vs unordered groups
    In EduPerson this is not an issue, as every group contains the VO
    If you request a specific group, then that goes first and then rest come after, like we have with VOMS roles today
     
  • Petr: Do we care about order in a capability based system?
    Maarten: not likely, but it is still important to consider this for potential use cases based on groups
     
  • Dave: back to issuers - for the purpose of pilot jobs, do we need an extra claim, or will we say it depends on the issuer
    Maarten: not an easy answer - must wear multiple hats, viz. SciTokens, WLCG, Check-in and possibly others in the future
    Find an alternate strategy to allow keeping sub-vos, whilst allowing the scheduling to be done differently. And something will need to be done to support EGI tokens that all have a single issuer.
    Mine: want to hear from SciTokens, rather than just deciding on separate issuers immediately. Is there an urgency to this?
    Keep discussions open and find a more general solution in the coming months.
     
  • Maarten: few people missing, would be good to revisit and aim for a decision in September. We could invent a new attribute or let our middleware try various ways to determine the VO, depending on the token flavor.
    Stefano: would prefer the VO being named directly in the token instead of depending on an external mapping of the issuer, which can be prone to errors or possibly even security issues.
     
  • https://zenodo.org/record/6533400/files/AARC-G069%20Guidelines%20for%20expressing%20group%20membership%20and%20role%20information.pdf
     
  • Action, Maarten: Start a discussion on the Mailing list late August to revisit and converge on a plan once summer holidays are more likely to be over
     
• IAM Hackathon
  • 2 Priorities from Francesco:
    • How to scale IAM horizontally - ie if you need more capacity for token endpoints, and how to increase capacity through deploying more instances. Some work underway now, such as instance caching being correctly shared between deployed instances of IAM via Redis.
    • Possibility to have the VOMS endpoint so it can be deployed across multiple instances and then run from multiple locations
  • Also scope for Logging/Traceability investigations
  • Multiple VOMS endpoints was a discussion started by VOMS service manager, which would allow clients to switch when receiving an unsatisfactory response from a given service, typically due to a downtime. It would allow one service to be upgraded and tried out while the other is kept on the previous version as a fall-back.
    Francesco: when a new version comes with a DB change, it cannot be operated alongside the previous version.
  • VOMS schema is stable, where IAM is not quite at this stage just yet
    • Changes to the schema for performance reasons - will need to limit these and be careful, so that they are done in larger packages rather than often.
  • Testing between versions can be facilitated by directing traffic with the reverse proxy, anything between 0 and 100%.
  • Maarten notes that the introduction of multiple VOMS and/or token endpoints would be to give operational flexibility, and not just for the sake of it.