Powered by Indico
v3.2.5
To connect remotely to the Garden Room: with a web browser and Zoom client, go over to https://eugridpma.org/z/61 or connect via H.323 (e.g. on the Zoom AMS endpoint at 213.19.144.110). The meeting ID is 938 1494 9602. The passcode is known to IGTF members and participants.
(no-host)
And: candidates for the annual chair election are always welcome!
Review of IGTF Trust Fabric (PKIX rendering) issues and changes: updates from transitioning CAs, TCS, and continuing challanges explaining the RHEL9/OSSL breakage of self-signed roots.
The AARC TREE project provides for enhanced effectiveness of the AARC community, including the Policy Area. We will putthe AARC TREE Policy Activity into the community context, and highlight where the new EC AARC TREE project and "WP2 - Policy and Good Practice" may help us!
The GEANT Project (5-2) is taking shape now, but of course also GN5-1 is still under way. Maarten and Casper will review the progress in GN5-2, and draft the venn diagram on the EnCo vs AARC TREE main activities
Discuss plans for
* TNC24 and the AARC Policy talk
* TechEx24 workshops (there is already a submission for a Sirtfi/federation TTX workshop)
* FIM4R colocated with TechEx24
* FIM4R in Europe? (Colocate with TIIME?)
The AARC TREE project provides for effort for an in-depth survey of Research Infrastructure requirements (supported by the Use Cases activity WP3: "This work will use as the starting point the FIM4Rv2 paper together with requirements that AARC TREE partners may have collected via other activities. In addition, it will engage with relevant forums and stakeholders (such as FIM4R, AEGIS, EOSC AAI Task Force, National RIs and European initiatives such as the EU dataspaces) to gather the initial set of requirements and use cases. Based on this, an initial set of the requirements and use cases will be captured, to drive further work."
* https://wiki.geant.org/display/AARC/Survey+development+area
AARC TREE and others have a dedicated action line to support FIM4R and the requirements collection process. Discuss planning of FIM4R meetings and how to ensure global engagement, specifically also beyond Europe.
Review the relationshiop between AARC (TREE) and WISE, and how we can both leverage and re-invigorate the policy aspects in WISE.
AARC-G040 "preliminary recommendations for the LS AAI" presented initial ideas on how to show terms-and-conditions and privacy notices for dynamic proxies. What does the current proxy landscape look like, and what are the current practices, e.g. in SURF SRAM on triggering notice presentation?
What should we keep, and what should we question in G040? Whom to ask for requirements, and how?
This is to be a working session with updates to the (presentation of) the Common AUP and Privacy notices
The Brewery Tap
42 Ock St, Abingdon OX14 5BZ
(no-host)
https://sharemd.nikhef.nl/isAZ1VG9Ria7BhyYoom9cg?both
Opportunity for input and feed-back from our Australian colleagues. Do we need to revise and 'template' terminology? What should the new PDK structure look like, and what is the role of the 'top-level' policy document?
And are all things actually policies, where some are more like procedures, and some information guidance or a glossary?
Nick will summarize the feedback from the Australian Access Federation as they reviewed adoption of the AARC PDK and the challenges and new ideas they encountered.
The EGI policy on data protection (for personal data collected as a result of users operatin gin the infrastructure, rather than personal information contained in research data) is rather antiquited and needs an update. While we recognise that a 'fully legally robust' option is not feasible, how can be update the model of 'pretty binding not-quite-corporate rules' and get that in a new (EGI) policy document?
This work stalled in the WISE SCI-WG because of formal compliance reasons, but the Infrastructures need it anyway.
The Unified Token Profile and the WLCG Tansition To Tokens (TTT) working group are progressing. Matt Doige gives updates on https://twiki.cern.ch/twiki/bin/view/LCG/WLCGTokensGlobusWG and (potentially) Mischa Salle on the Grand Unified Token profile.
What do we need as input from the communities (via the questionnaire or otherwise) in order to provide token lifetime guidance? This should likely be based on a risk assessment, but there are several use cases, both set by the CIA classification of the data (services) involved, but also on the interaction model and the presence of mitigating controls (like revocation, or relying-party suspension lists, or ...)
Follow-up from the AARC Policy Call "initiate trust and tracability working parties (CT-like append-only logging by proxies: Jens; TTX exercise models: DavidG & Maarten)"
Assurance profile for DCV only, server-only eKU for the IGTF
Does G071 give us enough info to trace users through the mesh of proxies, where you have multiple proxies in the mix, and you might need to trust all the proxies that are somehow connected. You will need to know who issues the statement, but also that it was not altered somewhere inbetween.
You usually follow upstream, but does that work operationally?
* do we need exercises/ Sirtfiv1 exercise showed some may be accidentally left out, like SURF then
* in a perfect world, all data is available and people react fast, but do they?
This was also discussed in the architecture meeting… but there is also good practice?
If you want any entity in the chain downstream to use these, the traceability to a community is lost?
If all entities in the chair record correctly (and share), the communication will work in case of an incident, but does that work?
* c.f. work in tracability of 3820 that Akos Frohner did
* RFC 6962 CT logging of these translations in an (external) registry. Would proxies want to do that? Encrypted?
And we need to run some ‘fake’ exercises to check if any proposed policy is possible. This does not need a real proxy or software, just a TTX with a few people thinking they are a proxy … inspired by the eduGAIN TTX from March '24.
This also implicitly validates (or not) elements of G071 …