Choose timezone
Your profile timezone:
Token Trust & Traceability WG June 2025 Call
→
Europe/Zurich
Description
Rescheduled from the usual time slot.
Token Tracebility and Traceability WG
https://codimd.web.cern.ch/diskkQ57SMiDnmJwvOjO8w#
# TTT June 2025
### 27th June 2025
Attending: Matt, Maarten, DavidC, DaveK, DaveD, TomD, Luna, Jens
Apologies:
## Risk Analysis Groundwork/Kick-Off
DC - aim to build timeline, look at the previous work.
Put as milestone on the technical roadmap
September/October seems a reasonable time scale
ML - First have to decide the set of scopes?
WG has the word token in it, but should not restrict ourselves to just that.
Not only looking at tokens.
Luna disagrees, think we should focus on tokens.
DC would like to agree with Maarten, but would be a big job.
DK - focus on tokens to some extent? It's been a long time since the last Risk Analysis, for a reason - it's a lot of work.
DC -
Jens - Just came out of a meeting with SKA where a job would be stopped if an authorisation changes. That would be implimented with short lived tokens and refresh failures. Example of higher level of assurance required.
DC- Would like a tool that helps with those kind of engineering decisions.
ML - quick reaction to Jens - not comfortable with that solution. Better solution would have the WMS actively kill jobs if this breaks.
ML - agree that risk analysis should be token based. Alongside best practice and polices. We can make useful notes along the way.
Jens in agreement, there are better ways of doing things. Working on demos around token flows.
DC - nice example of tech demonstrators as ways of mitigating risks.
Shares ITSRMv2 methodology - particularly the first 2 steps of it
* System Security Characterisation
* Primary Assets
Look at primary assets for everything, then focus down later.
Notes from TIIME. Example of other preliminary work.
These were the notes from the TIIME risk assessment session: https://docs.google.com/document/d/1AcOmhxIUTKkaIaxiFH8UtD88AECAN1pBrdiq3ESPODQ/edit?tab=t.0#heading=h.xfxuay1g5bs2
Suggestion is define largest possible scope and focus in.
ML - create a google doc and have sets of things we want to consider.
* Lifetmes
* Scopes
* Audeince
* Token types for use cases
* Issuers, security of them?
** Potential downtimes, workarounds for that.
** Blurring into aspiration aspects. WLCG will have a holistic view.
Need to indicate this for assessment.
Shared google doc? Might become tdifficult as we decide what weighs the month.
In the past decided in groups, with individual scores that are compared.
DC - think we should work collaboratively, focus on scopes and assets first. So google doc for scope and primary assets first - before we go on the next step.
MD - points out EGEE spreadsheet
DK - can start with asset list first, or decide on threats first. But the new frameworks are asset first, so a different approach.
Asset list isn't easily narrowable, but is reusable.
DC - Scope that landed on at TIMME was 4 main WLCG experiments, low impact data.
Luna- already started on assets, considering assetts in wlcg risk assessment.
* Shares asset list as it stands
ML notes operational issues/risk again wich could be a small deviation. But 90% should be resuable.
DC - this shares commonality with what we decided at TIIME
Luna - different way of measuring impact in CERN risk register.
Runs through the document.
ML - will add some more details. Subitems.
Note the worries of downtimes of IAM.
Should do the common part here, and import into the token taskforce.
Agreement on avoiding overlap.
Token TF has similar timeline of ~September
DC -Common sets of assetts, but different weights/threats.
ML - differences even between VOs, but could draw conclusions for different examples, for example noting if an experiment has nautrally mitigated an issue through its workflow we can build recommendations for that.
ML - can always clarify in comments
Ideally have whole thing in a single PDF file, but would need to deal with that. EGEE compared to WLCG examples.
Would like to avoid final product being a wide spreadsheet, would like to be more like WLCG output.
DC - agreed as we need to be able to pull concrete out of this.
ML-should idnetify top risks first. But what does "dealing with them" look like?
For example recommending a software update to a specific version.
DC - indeed, this needs to be able to feed our engineering decisions.
Discussion on the document.
ML - In the end only so much technical detail needed...
## Next Steps/Actions
Share a document (possibly the existing one), and all add to it ahead of the next meeting for discussion.
DavidC suggests adding extra sheets.
Luna also notes need for a companion doc.
-DC, extra column with references.
Action to share a document (Luna share) and on all to work on the document.
Suggestion that we need to meet more then once a month.
Next meeting would be the 8th by this? Not good for ML, can do a quick poll. Fridays at this time work well.
Friday 11th at 16.00 CET
### Next Meeting
Usual time? 15.00 CET Tuesday 22nd July?
Decided on Friday 11th at 16.00 CET.
There are minutes attached to this event.
Show them.
