Token Trust & Traceability WG
Fortnightly for the risk assessment season.
https://codimd.web.cern.ch/98m7o-tcR_SKCYvbH_rtrw
# TTT 17th December 2025
Attending: Matt, DaveK, Linda, Maarten, Donald, Luna, Mischa, TomD
Apologies:
## Last Meeting
A recap, and went over differences between threats 4 and 5.
Noted that ambiguity between likelihood descriptions for 3 and 4 (more then once a year/every few months).
## CHEP Abstract
Tom and Mischa polished it nicely, so I think Tom can submit.
DK notes that some overemphasis on authentication and not authorisation, but both are mentioned in the text so should be fine.
## Finishing the exercise
* 5e and 5f left, Misuse of resources from a single identity with no revocation channel for User Data Management and User Jobs.
* Also a look back at 4e and 4f and the possibility/likelihood of the need to split between "ordinary" and "power" users.
- need to do this now
- stolen needs to be removed from the vulnerability (as it's misused) - done in meeting
- writing illegal data should be mentioned in the vulnerability
DK notes that we should acknowledge the threat of experiments not using features
Luna notes TR-7 covers this
Similarities between TR-4 and 5
Splitting 5e and 5f to Ordinary and Power user rows
MS - what if the user has had their account hacked so a bad actor is using their credentials through "legitimate" channels.
Need to discuss
Some debate on this.
Luna advocates this is in TR-4.
MS-not including hacked account doesn't increase the likelihood matters.
MS - Changed risk from x509 days, SSO breaches are a factor.
Luna, TomD - seperate risk to the ones we have, including accounts is a seperate risk.
If we're just considering tokens should we consider accounts?
ML- the way tokens acquired tied into accounts.
could widen 4e and 4f, stolen, leaked, or generated from compromised account.
ML - not the same, likelhood, mitigations, different.
Lifetime a factor.
Probably needs a seperate line(s) (power user and regular user),
will revisit, but likely in scope. Intrisically tied to account.
More comfortable user experience one of the motivations for moving to tokens.
Back to 5e-P, Likehood non-zero due to the possibilities of mistakes, but actual misbehaviour neglible. Impact high
On the same for ordinary users, spread on likelhood from 2-4
Mischa notes that ideally we would work this with a spread, and group analysis.
Donald makes a comment about mitigations, and confidence levels these are in place.
Signal to any new type of mitigations? Changes in patterns could be monitored for.
MS notes that we should have the same likelihod for 4e and 5e, what should we do about this?
ML - mistakes are made almost every day or week.
- decided to put likelhood to 4 and impact to 2
On to jobs. Some wondering if power users make sense here?
-in this case production manager
Likelihood the same, some debate on 4 or 5 for impact
LC votes 5 due to risks of attacking elsewhere.
Went 5, as a signal to look at this carefully
MS - differences between power and normal users when it comes to jobs?
ML - Scale. Normal users have quotas.
Likelihiood had a big spread
DC - less likely to abuse
MS - at least as likely to see problems with job submission as data (from experience)
Went for 4 as well.
Some discussion of impact.
Mention of zero day exploits as a factor.
Decided to use a 5 again, mirroring the data management.
## AOB, Next Meeting
Next meeting 6th January, 15.00 CET. Another 90 minute extravaganza.
Plan for it:
- Split 4e and 4f into Power and Ordinary users and re-evaluate.
- Look at how to handle the case of a "hacked" user, where a bad actor is using regular token flows using a compromised account. This is a hybrid of 4 and 5.