**Token Traceability WG Kick Off** ---- https://indico.cern.ch/event/1303454/ Matt's email: m.doidge@lancaster.ac.uk Attending: Matt D, Petr, David C, DaveK, Maarten, Vincenzo, Enrico, Sven **Opening Round Table** ---- * A quick run around the virtual room. * Matt - Site Admin hat, something to ban, trigger on. * DaveK - Trust and Policy issues in general. Previous discussion on building trust and assurance in tokens. Identity Vetting/Proofing. Policies based on risk assessment. Trust and Risk - where does this work sit? * Maarten - agreed, new overall risk assessment. Difference between what we'd like to do and what can be done in practice. With a changing landscape shouldn't use old, stale documents. Broader risk assessment diserable. Not focus on tokens, but broader. * Current WLCG AuthZ working group has a lot going on. * Want to look broader than WLCG. * Other forum that enages then this is AEGIS group - number of guidence documents. * Many groups interested in move away from x509. * Workflow documentation is needed. * Maarten brings up the fact that policy makers don't always run services. Example - non-revocable access tokens. * Broad spread of experience involved. * Vincenzo site admin hat on too - want to ban a token without banning a VO. * David C - critical to have a group centred on needs of incident response, tools needed. Disconnected from work to "operationalise" tokens. For incident response what do we need to have? Note input from SKAO would be useful and valuable. * Petr - notes that in the current climate we don't have individual user identity baked into the jobs. Changing that would require huge changes. This hasn't changed for "token times". * ML: Good point. Cost/benefit analysis needed. The current only recourse is ban the VO when something bad happens. Wishlist would be more controls, but not the thing we can expect in the short term. * DK - this is not an ideal situation. But we have acceptable traceability. Do we lose any traceability with tokens? Need to confirm this. * MD - thought about sticking an identity into the job chain * ML - Probably possible, but expensive. Bigger fish to fry in the short term. Something to document in the short term. But move to tokens should make things better. * Enrico wearing Indigo IAM/StoRM dev hat. Can share thoughts from the dev side (for IAM and a service provider with StoRM) * PV - concerned about pushing id through whole chain. Several issues with approach, individual user problems mean hard to reproduce indvidual user's work. Load on the IAM server also a concern. * VC - a mid-way between using one token for all and tagging all jobs with user id. Some way of quickly feeding back user id. * DC - concern ourselves with traceability of the *system* not any particular leg. * SG - There are issues that should have been looked at in the design phase. We're not too far in yet to make changes. Need ways of communicating malicious tokens and acting. Need experiment representation in this group (as they have the most to lose). * ML - Lucky so far as incident rate low. Alice and Atlas represented, but could do with adding more. * SG - currently ill equipped to deal with token based problems. Need to make sure that operational security team has options. * Act on identities, not whole communities * Need clear documentation on token usage, good goal for this group. * Document how to deal with misplaced/misused credentials. * Currently no real documentation on this. * Need to do this in a sustainable way. **Review of Previous Work** ---- * Last call of the Traceability and Isolation WG was in 2019, "mission accomplished" * AuthZ group work in the area? * Decided not to look back, but VB was contacted by ML. Would be useful to get him involved. **Discussion: Setting Goals (and Boundaries)** ---- Rename Token Trust and Traceability WG? ( T3 :-) ) * subgroups Do we want to keep tokens in the title? Risk assessment will lead to questions, who to sort out issues. * Balance what we'd like with what we *need* with what is technically possible. * Who do we need to be involved? * Policy * Dev Work * Implementation Experiments and other groups (like SKAO) Site Admins (SG - incident reponse procedure sketch for a site) "Policy People" Operational Security Token Devs Service Devs **Actions** ---- -Start work on token workflow document - Token Incident Reponse Procedure. -Matt will take this on. -Mailing list - don't have yet. -Matt will do this too. (Done - see below) DK notes we're all EU. -Action - identify people who should get involved, try to rope them in. (all) -Discuss on the mailing list once it's formed. **Next Meeting** ---- August is probably a no go, either end of July (would that even be useful?) or early September? Aim for early September. **Working Group** ---- token-trust-and-traceability-wg