Token Trust & Traceability WG May 2025 Call

Europe/Zurich
Zoom Meeting ID
64974356171
Host
Matthew Steven Doidge
Useful links
Join via phone
Zoom URL

https://codimd.web.cern.ch/F0lP-IBkQle2x_DSq5JQtQ

 

# TTT May 2025 Meeting 
27/5/25  

Attending: Matt, Maarten, Mischa, DavidC (first half), DaveD
Apologies: Linda, DaveK

## Actions, News
- Token Lifetime document (pretty much) wrapped up
-- Need to properly formulate scope of document.
-- For example data access token at the end of the job is considered out of scope.
ML - document is kind of a default, if using the recommendations covered from a security point of view, but maybe not for operations  
Deviations from these recommendations should be defensible, and perhaps mitigated in someway.  
ML - Need to add early on (in introduction) that these are default recommendations, there could be exemptions.  
MS - puts comment in document. Aim to have same group work on a more "classical grid" version  
ML - See if Marcus wants to take that up, or delegate to this group.

 

## Discussion
MS - the other urgent thing is accounting. WLCG profile has groups claim, intended for authorisation but doesn't work with capabilities. Now start to use for accounting. So don't know if group claim used for authorisation or accounting. Might need to update profile with statement like "if you have groups and capabiltiies only use groups for accounting"

ML - move to deliver version 2.0 of the profile in the next few months. Don't want to perpetuate ideas from years ago that haven't worked out. Making note of scopes vs. groups. No longer using "OR" when considering these. Instead scopes have priority. Groups provide context information (for example accounting)  
MS - go stronger, if have both make sure that groups are forbidden from being used for authorisation.  
ML - might be preferred to not rely on wlcg.groups for accounting, instead mapping issuers to accounting groups (same way as mapped to user accounts). Both mechanisms will be available for accounting. Best to not rely on wlcg.group contents.  
MS - ideally we need a new claim (as discussed in GUT)  
DD - that won't impact if clients don't request it.  

ML - look further into new claim, due in part to the string "wlcg" in there.  
MS - make sure semantics of the claim are okay  
ML - noted that in CMS some internal use of the claim, if we use it for accounting restricts what can be done with the claim (cms/somegrouporrole), need to start parsing the string if go this route.   
If we define a new attribute can easily be a year or two before it can be relied on to be everywhere. Want to have a plan B to allow us to move on.  
Allowing sites to apply mapping to accounting. Not accepted yet. But is a natural point to do this. On ARC is recommended solution.  
Zero dependence today on wlcg.groups  
MS - HTCondor using same mapping plugin, along lines of lcmaps.  
ML - accounting where EGI concerned seens as an external addon.   
DD - also issues of subgroups/sub-VOs, one case where site only excepts fermilab NOVA subpilots.  
ML - this is part of the pilot machinery, submitting jobs for certain VOs to certain sites  
Brian notes that this is a fermilab decision that we shouldn't work around. If you use sub-VOs a site cannot distinguish from credentials.  
He noted need to draw a "line in the sand" on this.  
It shouldn't be an issue for cilogon to use different issuers, but might have trouble with the workload management system.  
DD - also an issue with EGI, having one issuer.  
ML - Can be considered more critical for EGI then OSG. But there is an attribute in EGI with this information, but not elegant. No proposed solution other then VO information attribute should be used.  
From ARC side need some logic to determine which account to map to. Need to tie it all together.  
ML - it would be good if a checkin token was tested on ARC to see if the mapping works. Token needs own plugin, so having its own attribute not nessicerily a problem. WLCG and scitokens are closely aligned, so would be nice to maintain that and agree if issuer and subject are not enough. The only stands outs are the fermilab sub-VOs.  
Issuer is most of the time sufficient for accounting.

MS- tries to find EGI checkin plugin

ML - would like to discuss what a common attribute would look like (GUT)
MS - would like to find time for GUT

ML - notes that an adopted solution might be temporary and replaced with a better one.

Some discussion if this good fit for this group, decided yes, as we cover both best practice and accounting goes hand in hand with tracability.

- Thread on the list regarding the token user experience. (message forwarded)
Keep in mind "de-mystifying" of tokens, still a mystery for most.

Issue of users getting the right scopes.  
MS - the user knows the VO, then it stops.   
ML - CMS seems most advanced in this area, and how they see users doing their thing. Agreed that users should be shielded. "token-init"  
MS - for ht-token things are quite good.  
ML - ligo (from the email) where probably pushed harder and faster and hence the rough-edged document. Hopefully they'll become more user friendly.  
DD - not sure what the user experience. Doesn't think the motivator was cilogon switching off x509.  

ML - notes the x509 being winded down around the place. google starting to throw weight around with x509. Motivation to have something suffiently working sooner rather then later. But at the moment half in.

From the last AuthZ meeting:  
*"long lived but tightly scoped tokens seem to be acceptable to all parties"*  

This is not a controversial statement, but I think we should look to codify it. Thoughts?

- no time to discuss properly today. 
- Ultimately in profile document (maybe not 2.0) will document use cases that need reasonings for deviation (tying into AARC doc). These cases need their own mitigation. This gets away from the "one size fits all" approach. 

### Risk Assessment
Next meeting


## Actions, Next Meeting

- Next meeting slot on the 24th of June clashes with the EGI CSIRT F2F, skip June or poll for an ad hoc timeslot?

David suggests polling, and focus on risk assessment with a methodology/technical milestone discussion.  

ML - rereading the previous documents as good start. Can profit from the previous work, despite their age.

- Action on Matt to poll for next meeting, anyone interested to re-read the risk documents.

There are minutes attached to this event. Show them.
    • 15:00 15:05
      Actions, Since Last Meeting 5m
    • 15:05 15:30
      Discussion/Presentation 25m
    • 15:30 15:55
      Discussion 25m

      https://github.com/TTT-WG/TTT-WG/issues

    • 15:55 16:00
      AOB, next meeting 5m

      Next scheduled meeting would be the 24th of June, but this clashes with the EGI CSIRT F2F. Any suggestions for other dates?