Choose timezone
Your profile timezone:
Token Trust & Traceability WG
→
Europe/Zurich
Description
Fortnightly for the risk assessment season.
Token Tracebility and Traceability WG
https://codimd.web.cern.ch/tEAHWaMLQDaTgBZumWXTvA?view
# TTT Meeting 5th August 2025
Attending: Matt, Maarten, Marcus, Linda, DaveK, DaveD
Apologies: DavidC
### Side notes
Mischa shared to the list:
OAuth 2.0 Threat Model and Security Considerations
Best Current Practice for OAuth 2.0 Security
Very dense reading though!
### Continuing from last time
- Matt had updated the scoring to a "matrix-like" table, review.
- some discussion that need to think about the rows, explicitly distinguishing service and infrastructure. Otherwise could lead to ambiguity as others make their own decisions.
- need to avoid adding in potential misunderstanding.
DK - services at risk because of infrastructure.
ML - need to capture differences between service and infra.
Service role set up with endpoint in mind. The more that are affected the worse it gets.
MD - didn't think it through when split between infra and services.
MD - Infrastructure is holistic
Probably don't need a separate row just for that.
ML - Service down is a problem for everybody.
Multiple rows instead of / between ideas.
Will think this through, but don't need the infra/service distinction.
ML - different roads to get there. Value in talking about the whole infra being affected.
This drifts into other assessment with the Token TF, about service failures.
Infra row would need new name, "the whole infra"
Difference between errors and DDOS. Or server down for, say, DB problem. But this is less of a concern for us (as no new tokens created).
Infra row potential for AAI affecting whole of the infra.
Tokens could be stolen, misused. Risks for types of services (say all SEs of a particular flavor).
For services row any thing goes bad the whole infra is down.
Infra in this case is a single whole VO.
Do we need an abuse of compute resource row? Need another row for compute?
MD - compute is automatically remote code execution.
ML - Compute abuse means service shutdown.
Could anything that could lead to the service being taken down just be a service issue.
Make visible that compute resources can be abused if broken into
Shouldn't all be in single service row.
How should data be separated out?
Site admin is worried most about getting hacked.
Service row is local service disrupt.
Case where a service could be being abused but work fine for users.
Need a separate row for that.
Review the table again, add more rows, but not every column needs to have something in it for every row - aim for 1,3,5.
Aim to try a risk assessment for a few cases next meeting.
* Goal laid out in last meeting was "discuss assumptions"
In the document the actual results will be kept, no need for someone to go to the spreadsheet.
Need to understand what each term means.
Aiming for early autumn, to work with the T-TF assessment.
Documents will be versioned.
Current Mitigations column is the current outstanding job. ML takes it as homework, but encourages others to add (and copy to google doc).
In the next meeting take a few weeks and see if we're all on the same page assessing impact and likelihood.
Try to fit a "dev cycle" in for the documents, letting the list know when we've made changes.
## Other news
AuthZ Token Profile 2.0 is coming along nicely, should be finished by the end of the year. Draft version of 2.0 hopefully by the end of the month, to be circulated
May not be perfect, but should be a massive step forward from v1.0.
Some discussion between Marcus and Maarten.
"Biggest change" token lifetime, lots of discussion in meeting and pull requests.
Next AuthZ meeting next week.
## AOB/Next meeting
15.00 CEST 26th August
Actions:
Matt to extend table.
ML to add in some current mitigations.
There are minutes attached to this event.
Show them.
