AARC TREE & EnCo policy coordination call Monday June 17 2024 ============================================================== **Present**: MarcusH, Baptiste, MaartenK, Nicolas, Licia, DavidG **Apologies**: DaveK [TOC] ## Actions from the coordination calls ### New action items as of June 17th - What is missing today in G071? bounce to the AEGIS group for operational input: **Action by DavidG or DaveK** - "lifetime of tokens" new guideline document: **Action by MarcusH** - Create (and write draft ToC of) the 'framing' document (Informational AARC-I* document) to describe the challenges before starting to write guidelines: **Action by DavidG** to start a shared document on sharemd/gdocs/overleaf ### Ongoing items - initiate trust and tracability working parties (CT-like append-only logging by proxies: **Action by Jens** - no further progress for now - TTX exercise models: **Action by DavidG & Maarten** - See also https://sharemd.nikhef.nl/s/_pNTbKy9f#Table-top-exercises-TTX-for-proxies-and-federations - TTX at EGI in Lecce (and pennding positive response from TechEx/Boston) - WP3 survey: **Action by _all_** - TO ADD to the survey: "add who is the community policy contact?"" (Policy input by June) - Collect any EOSC SMS onboaring documents for community input: **Action by Baptiste** - pending - Start with a ToC of the AARC documents: **Action by DavidG** - end of June/early July - Milestone early september - writing completion during the September 23+24 workshop /PMA62 - Actions based on AARC PDK Feedback: - capture stories from smaller communities - separate the PDK into policies and procedures as ancillary documents - look at the top-level policy to see if it recasts into foundational principles - split the policies (and procedures) by topic area - review and draft something by July (DaveK) - token lifetime and revocation guidance: **Action by MarcusH** - MarcusH to set up a google doc - Document good practices what communities are currently doing. Via the questionnaire in AARC TREE WP3 or ask that later. - What do the communicaties have configured with the AAI providers? - Do one-on-one interview with policy/security experts from the communities - there are two more token types to consider: SSH keys and KRB TGTs ### Completed items - overlap GN5 and AARC - DONE: actual work in AARC (output driven), and GN5* EnCo will ensure continued coordination and sustainability ## Document status: AAOPS and T&C presentation guidelines Missing today in G071: - bounce to the AEGIS group for operational input - **ACTION DavidG or DaveK** - what about life time of tokens? current discussion will fit in here. E.g. how to get rid of refresh tokens that should no longer be valid - the operations needs to ensure that there is a way to get rid of them - lifetime of tokens: new guideline document - **ACTIONS MarcusH** (this document will refer to it) - transparency of the proxy: maybe that one for later in the context of OpenIDFed? Questions from the ArchWG: when discussing the attribute profile, what about compliance of home IdP (upstream) to policies. The question is: should this be transparent and should ti be relayed by the proxy to the end-service? - We had (some) of this discussion in the past (at the CERN AARC meeting 2019) where the proxy (eduTEAMS) took on the entire responsibility. We then said 'yes' but never documented documented nor on how (or whether) to expose it. But is that sufficient for the downstream services? If there is an infra-proxy inbetween now, should that one be transparent? Then the proxy cannot statically signal, say, Sirtfi, for everyone? There is a use case as seen in SRAM (with the custom assertion on eduPersonAssurance with the /eduteams.org/ namespace inserted by SRAM, as shown by Maarten). - should this be an informational document or guideline? - or part of the attribute profile document? Start writing as a new document or section for 'transparency' of the proxy (generalised, but inspired by R&S (SP side) and Sirtfi (IdP side) - things like Personalised are simpler since the proxy can autonomously do it? - Even if R&S is only ~95% OK, it's still valuable - not to be overly formalistic - other attributes to communicate [external identifiers](https://docs.google.com/document/d/1jO1X7GSXWf_R604j5LXinr37ZUf96YVdIXSvjpS_Vyk/edit#heading=h.qg2prggyj0p0) of the user (like ORCID), and for that the proxy has to have some transparency anyway - and that must be communicated as-is. - and conveying original identifier of the user (which one?) and should be proxy relate this and forward? It is allowed to do so (keeping in mind data minimisation/privacy by default)? Write a separate 'framing' document (Informational AARC-I*) to describe the challenges before starting to write guidelines. **Action by DavidG** to start a shared document to write that (sharemd/google/overleaf). ### Evolution of G040 Similar framing doc for the T&C presentation? The attribute profile (from the Arch WG) already has a multi-valued ["Agreement to policies"](https://docs.google.com/document/d/1jO1X7GSXWf_R604j5LXinr37ZUf96YVdIXSvjpS_Vyk/edit#heading=h.6gx8etqyba0s) attribute to express acceptance of a policy (examples include T&Cs, privacy notices, and AUPs already accepted). ## AARC Community Survey: input for questions and context An updated questionnaire (accessible to AARC TREE participants) is available at https://docs.google.com/spreadsheets/d/1NXj0T0u2JkC_-htaDE7_whVcgTcZKL8amB42NuqTYds Actions: - Policy input by beginning of June (~TNC time) - Interviews will be over July and August. ## AARC Strategy Help out Licia before the end of the month! ## AOB - planning for FIM4R meetings: how to get the right people from the AARC community in, and what would we like to get out of it? Both for "us" and for the communities. July 1st and July 15th at 1600 CEST (and then first and third Monday of each month). - Colocation of ~one day AARC with TIIME in Reading, UK (March 31st .. April 4th). Ian Collier organising. Meeting closed at 15:51 CEST