Dear EUGridPMA and IGTF members, The 41st EUGridPMA meeting is now over, and I would like to take this opportunity to thank again Mike Jones and the excellent staff at the Manchester Jisc offices: Colin Worden, Amanda Gray, and Kieran Jopson, for hosting us right in the centre of Manchester and keeping us going. I would like to share with you a few of the highlights of the meeting. Send corrections and omissions if you spot them, since these have been taken from my own scribbles and memory at https://eugridpma.org/meetings/2017-06/eugridpma40-notes-davidg.pdf Slides with background of the meeting are attached to the agenda at http://www.eugridpma.org/agenda/41 More extensive notes, kindly taken by Derek Simmel on Monday, are available on the web site as well. Subsequent meetings will be: ** 42nd EUGridPMA meeting, January 2018, Prague, CZ, kindly hosted by CESNET --- Note this meeting will start in the afternoon at 1400L, and will run till lunchtime on Wednesday, so that you can travel on the day exact dated (2nd half of January) to be announced shortly! ** and we're looking for a host for the 43rd meeting in May 2018, for which proposals are very welcome (thanks for considering it) and of course our affiliated meetings: - REFEDS at the I2TechX, Sun Oct 15, 2017, San Francisco, CA, USA - APGridPMA co-located with HEPiX, Sun Oct 15, 2017, KEK, JP - APGridPMA at the ISGC 2018, March 19, 2018, Taipei, TW See all of you in Prague, or at any of the upcoming meeting of the IGTF or elsewhere. The exact dates in the second half of January will be announced shortly. Best regards, DavidG. Subject discussed and listed below ---------------------------------- * TAGPMA update and considerations * Federated Identity Management for Research - FIM4R * AARC and AEGIS * Building on the Registration Authority Network * Assurance Profile evaluation matrix for communities * Snctfi - the Scalable Negotiator for a Community Trust Framework * Roadmap of the IGTF in a multi-technology world without the Globus Toolkit * OIDC Federation Task Force * The IGTF as a mechanism to ease research communities into eduGAIN * Experience with the TCS in the Czech Republic * IPv6 support * OGF and CAOPS * PMA operational matters, reviews, accreditations, federation support * Other updates: IPv6, AAAI Pathfinder * Attendance All presentations are available on the agenda page: http://www.eugridpma.org/agenda/41 please review these as well as a complement to this brief summary. Much information is contained therein and not repeated here. We also thank Eric Yen and Derek Simmel for presenting the updated information from the APGridPMA and TAGPMA, respectively. TAGPMA update and considerations -------------------------------- The TAGPMA has been particularly involved with discussions around the annoucement by the end of UChicago-based support for the Globus Toolkit. The effect of this annoucement is considered later in the meeting, but it should be noted that the user community and infrastructures that use elements fo the Globus Toolkit maintained by UChicago (such as GridFTP and the GSI authentication libraries) have joined forced to keep maintenance for these components ongoing. In any case, most of the work was already done by these groups anyway. If support for the underlying GSI libraries is maintained and there continues to be use case for gsi-ssh, Jim Basney is likely to continue to support this critical piece of software as well. Meanwhile, the TAGPMA is actively looking for opportunities to emphasize the wider relevant of the IGTF work in the region - where a white paper on the evolving deployments of AAI would be welcome. This could take the form of a blog or news item as well. In a complementary discussion, the European Commission has requested that the AARC project in Europe works on an 'entity relationship diagram' that brings clarity to the respective roles and functions of AAT groups including REFEDS, IGTF, GEANT, InCommon, &c (which has been asked of Licia). A need for a '1-page' paper on the relationship of policies was also implicitly requested. In general, there is the aim to engage more relying party and community members in the IGTF process, attracting more SPs and research infrastructures. Federated Identity Management for Research - FIM4R -------------------------------------------------- FIM4R, the requirements collection and expression group for the research communities, has been active in trying to extends in scope to more non-European communities. The last FIM4R meeting, colocated with the RDA10 plenary in Montreal, QC, CA atrected a wide audience and fresh input from communities in CA and the US. The two main outputs for the next period will be an updated white paper (v2) following the earlier success in 2012, and - based on that - a questionnaire to reach also new communities. The RDA FIM4R Interest Group is primarily focussed on outreach at the moment, and as of yet seems dominated by the EU and US, and lacking in particular input from the Asia-Pacific region. Also, RDA (like many forums) has issues in cross-connecting interest that spans multiple working grous. Getting a wider range of applications might also be achieved by co-locating with e.g. the PEARC conferences (application-oriented successor to the XSEDE conference series) AARC and AEGIS -------------- The AARC project, taking care of bringing federated authentication and authoritarion to research and e-Infrastructures in Europe, has entered its second phase. One of the key general results up to now is the Blueprint Architecture (BPA) for AAI, ensording the use of SP-IdP proxies for bridging between traditional federation and research and collaboration needs, and helping to align policies around Snctfi, Sirtfi, and R&S. To ensure long-term sustainability of the results, it is engaging with existing bodies (amongst which the IGTF) and has established a new group to coordnate the incorporation of the BPA in existing infrartuctures. This "AEGIS" group has the major implementing global infratructures on board (EGI, ELIXIR, EUDAT, GEANT, PRACE, XSEDE) and DARIAH-EU is joining as well. For more details see the presentation by Christos Kenllopoulos. The specific request to the IGTF is to align policies and share the resulting experience, and support AEGIS in implementing best practice. For communities that are prodominantly national (like the ones supported by the autority members at the moment), the Community Engagement Forum (CEF) through FIM4R is the best vehicle for communications. Building on the Registration Authority Network --------------------------------------------- The bottom-up regisrtation authority and agent network that has been established to support the credential issuance by IGTF authorities can be seen as one of the main 'assets' that fluels the IGTF, and in some places the unique and only way for researcher and collaborative efforts to have access to good-quality credentials. As detailed in the presentation, the this network itself is technology agnostic, and many bridging solutions allow credential formats to be translated into eachother (via automatic or manual translation services - the graphic shows the spaghetti-like possibilities). Consilderations to keep in mind: the scheme of migrating registration agents is known to work well, as demonstrated by the ASGC authority is managing and devolving RA networks around the AP region. Yet, without a concrete credential issuing service, the network would quickly fall into disrepair and shrink. The support to users is thus essential, even if the format of the credential can be different (e.g. registrtion in a high-quality research IdP in a country without an existing federation). The continued use would also warrant the costs ssociated with maintaining the registration network. Where research-friendly federations exists, these should be encouraged to take up as much of this role as possible, but the coverage is (on a global scale) very limited, and moreover very different even in the countries that do have federations (but which then are targetted primarily at office automation outsourcing scenarios, making them for now cumbersome for research collaboration). We should ensure that subscribers continue to have access to a global registration network and credentials - keeping in mind the FIM4R requirement for global single sign-on.Even in view of changing credential formats, keep the vetting network and authentication process alive in your country! Assurance Profile evaluation matrix for communities --------------------------------------------------- The IGTF has traditionally benefitted from assessment matrices and guidance for review and self-assessment based on the TAGPMA work on 'spreadsheets' and the GFD.169 'audit guidelines' document. With the new generalised Assurance Profiles, and the introduction - via Snctfi - of combined assurance by AuthN providers and communities, there is a need to give guidance (for architects and assessors) on how the Assurance Profiles apply to community registries. There are of course many ways in which to distribute the assurance, and there may be more than just the (EGI basic) two parties involved. In general, every source of attributes will have assurance and provanance information attached to it (e.g. in the CLARIN IdP, Jens). For for the first version of the assessment matrix, we assume that one registry belongs to one assurance profile (and to support multiple profiles will imply multiple identifiable registries). The guidance for communities, based on the Generalised Assurance Profiles, was reviewed and amended - up to and including section 3 - in: http://wiki.eugridpma.org/Main/AssuranceAssessment Snctfi - the Scalable Negotiator for a Community Trust Framework in Federated Infrastructures ---------------------------------------------------------------- The Snctfi framework (https://www.igtf.net/snctfi/) was developed by AARC to help communities assess the internal consistency of the set of services behind an SP-IdP proxy, and - based on that - assert existing commonly-useful qualities (entity categories like DPCoCo, R&S, Sirtfi) about the proxy to the IdP federations. It provides a framework, inspired by SCI (see https://wise-community.org/sci/) that can be used for self-assessment. At the moment, the SCIv1 guidance suggests different 'maturity levels', and a peer-review process, such as the IGTF model with peer infrastructures reviewing each others' policy suite, would implicitly bump eveyone up to level 3 (document and reviewed). Although a simple 'yes/no' could be sufficient, the review process itself will bump that up to a higher level. Having the baseline stated in the Snctfi document is necessary, and will ensure the infrastructures can actually interoperate (unlike some ISO standard that allow you to document "I don't do anything", and then you meet the standard by doing nothing ... :) But the baseline should likely target some specific use cases ("80/20 rule") and allow more specific requiremetns to be added only when needed. Since there is much implicit background behind the numbered Snctfi statements, an FSQ, explanations, and guidance must be developed. This will be done as part of the initial review of some 'friendly' communities, such as EGI and maybe LIGO. Based on Snctfi, EGI ahs developed its new Community Membership Management and Community Security policies, and a brief review of the feedback received does indicate that the term 'community' can be read in very different ways. Also, in those communities exposed to the earlier EGI VO framework, the requirements are at times over-interpreted. The element of 'risk-based assessment' needs to be emphasised. The intial documents, developed jointly by AARC and EGI, can be viewed at Community Operations Security Policy: https://docs.google.com/document/d/1TFE4T4hyFFrVKHyTjh4K8cJlrrvJGfpVvIvL4GCzYFM Community Membership Management Policy: https://docs.google.com/document/d/1vPcAja1EyTp-kJPvJpwu3NSd8e1aVcytY3nSGthWNLU Roadmap of the IGTF in a multi-technology world without the Globus Toolkit -------------------------------------------------------------------------- The TAGPMA has been particularly involved with discussions around the annoucement by the end of UChicago-based support for the Globus Toolkit (GT). In some cases, issuign authorities suspended their operations based on the impression that it has already gone (it has not: UChicago keeps providing security atches till the end of 2018), or that the use case for their credential issuance has disappeared (it has not: GT is just one of the many software product that use PKIX credentials - and even through the use of PKIX was pioneered by them, it is used in many other products). Looking at the community, also EGI FedCloud, Slipstream, DIRAC, many of the WLCG services are using PKIX at the core; there are an unknown number of use cases that apparently use federated PKIX because they download and use fetch-crl from EPEL (feature requests do come in through Fedora once in a while); and the S/MIME personal use case remains as well. Anyway, the announcement did trigger global discussion, also because other products at times rely on the software libraries provided by GT, such as the GSI libraries for RFC3820 proxy support and relying party defined namespace constraints (RPDNC, GFD.189). And although in the US the packaging of GT components was done by the UChicago team, the standard Fedora and Debian (Ubuntu) packaging is done by Mattias Ellert of Uppsala University and the EPEL/Debian packaging is what is used in EGI, WLCG, and elsewhere. The major infrastructures, including EGI, OSG, WLCG, and XSEDE, have agreed to support the necessary components via the community, since most of the patches were already done by them anyway (and not integrated back upstream since the bugs files were not addressed). CERN looks for supporting Mattias in packaging - there need to be a sufficient number of trusted committers for Fedora and Debian to ensure sustainability and ROBAB-proofness. Although XSEDE will likely keep their alignment with GlobusAuth - the UChicago proposed alternative for GT - it seems unlikely that at least the European infrastructures would subscribe and pay into such a single central service which is closed-source and non-replicatable. In looking for alternative authN models, the major Infrastructures in Europe move to a standards-based OIDC model (without bespoke extensions), and there move could well in the direction of OIDC Federation. Despire the push via Kantara, SAML-ECP is unlikely to gain global adoption, and Moonshot suffuers from lack of installed-base on which to build globally, and thus appears to have less chance than SAML-ECP. OIDC Federation --------------- OIDC Federation in general still has some ongoing discussions as to the model itself (lead by Roland Hedberg, e.g. in the TNC2017 workshop), and - for general R&E federation might well be 4-5 years away still befire reaching 'production' status. But for the research and e-Infrastructures, the push to 'quick' OIDC federation can come earlier, and since the problems in better scoped, we can move quickly in this area. Also, the IGTF has the distribution infarstructure in place to propagate e.g. trust anchors for OIDC, so that key distribution can be handeled centrally, and service registration can use ".well-known" scaling. The one thing to be reviewed (and discussed with the OIDC standards groups as to how to implement it best), is the scoping and RPDNC like behaviour. That seems doing within the standard, althoguh scoping is not always commonly implemented. Also, we can push for full OAuth2 with delegation (needed for the Infrastructure use cases). The IGTF DECIDES to set up a task force to push OIDC Federation next to its current trust anchor distribution. This group will - identify objectives - scope the needs and requirements - verify compatibility of the AP policy framework for technology- agnosticity with OpenID providers - test the scenario with the WLCG use case (what to distribute, involving Brian Bockelman as well) - assess the structure and needed meta-data in the trust anchor distribution, how to address RPDNC, and how it links with dynamic client registration through .well-known (with caching) - liaise with other OIDC Fed efforts and Roland Hedberg The size of the IGTF OIDC federation would again be O(100) organisations (but maybe more dynamic services), and not 10k+ - we expect to address the research and collaboration use case, not solve the general R&E fed problem here :) Limiting it to a enumarble set of organsiations will be implicit through the need to adhere to the IGTF baseline assurances, the membership process and review model, and maybe some coertion towards collabroation for projects in the same space. This worked well for keeping the number of authN providers reasonable over the last 15 years. The working group will be open, and initially consist of: JimB, Jens, DavidG, DaveK, Derek, Eric Yen, and Sang-Un. A mailing list will be established shortly. The IGTF as a mechanism to ease research communities into eduGAIN ----------------------------------------------------------------- Traditionally, the national R&E federations have been set up with non-research use cases in mind. The AARC project and developments in GEANT and eduGAIN itself have changed the landscape significantly and opened it up to collaborative use cases, but still some cross-national communities have issues 'getting federated' because of issues at the national level. Also, it is not always obvious how to get in, since there is no over-arching global entry point into eduGAIN. Several issues come up repeatedly: the need for having a legal entity to enrol in a national federation, which research communities (typically based around MoUs or implicit understandings) do not have; the very slow process in some federations to get even trivial bits of text added to federation meta-data (like entity categories such as Sirtfi or R&S); and lack of a natural national home. Also the research community lack a way of directly engaging in the steering of (inter)federation, since the governance is closed to existing R&E federations (eduGAIN SG) or hidden (like the FOG list). Recently, eduGAIN has opened up to non-national federations in principle (one group tried but then abandoned it), so we could use the IGTF as a vehicle to ease some of the above. IGTF members do not have to be legal entities (we have other control processes), we can innovate quickly (writing SAML meta-data is not rocket science), and are scaled such that processes work more quickly. Would it be theoretically possible for the IGTF to join eduGAIN as a federation? - the requirements listed in the eduGAIN Declaration are all met. There is no liability involved, no need for a legal entity (surprisingly!) but there is an undefined process of voting by the current (steering group) membership without criteria (like a beauty contest :) https://technical.edugain.org/doc/eduGAIN-Declaration-v2bis-web.pdf - the eduGAIN Constitution has more requirements, but all of these have already been met by the IGTF by virtual of the Charter, our Federation Document, and the Membership Guidelines. We also avail over an incident response capability (RAT) and a control mechanism over our members (dependent on the PMA, but either through reregistration such as the letters in TAGPMA, or through the suspension-review subcommittee in the EUGridPMA). We appear to meet all requirements of the document: https://technical.edugain.org/doc/eduGAIN-Constitution-v3ter-web.pdf - the technical issue is simple: generate some XML (for a federation the size of the IGTF this is trivial), and sign it in a secure way (HSMs for this frequency are cheap). Also, the registration manamegemtn process is something we already have for the current trust anchors The target entities would likely all be SP entities (maybe apart from the IGTF-to-eduGAIN bridge :) and have Snctfi in place. In this respect, the IGTF could just join - the lack of documented policies was one of the reasons that TERENA (years ago) did not pursue the route to set up a catch-all federation. The other question in the seed from the community. We have identified interest from a few communities (LIGO, EGI, Belle-II) or can expect interest (e.g. NERSC, SKA). To make it attractive, through, one would have to gear up an empty federation first, so that the enrolment of a new community culd be done in a couple of days. The initial delay of getting into eduGAIN may take long (many, many months). But for a community: once you're in eduGAIN and you found a federation to host you that is research-friendly, then the need for getting in through the IGTF would disappear. Only the 'influence' in the steering might have benefit, but that can be arranged also through other means (AEGIS, AARC, FIM4R, &c). So if there are just 4-5 communities that would need this, it is more effective to not invest in registering as a federation, but to use this effort to pressure for changes in (one or more) national federations to make them research-friendly quicker - and contribute effort where useful. In terms of effort-return, pursuing the SAML road for IGTC is a lower return on investment than, say, the OIDC Fed. Based on the limited number of communities that would benefit, we conclude that at this time it maked no sense for the IGTF to join eduGAIN as a federation. We will focus on pressuring existing national federations to be helpful, and would welcome e.g. exising cross-national organisations close to eduGAIN to consider providing a inter-national home for research and e-Infrastructures to register directly with eduGAIN (provided they can cough up some SAML meta-data), even if they are not legal entities, to just make it easier for everyone involved. Conclusion: IGTF will not apply for eduGAIN membership now. Experience with the TCS in the Czech Republic --------------------------------------------- The CESNET service uses its own web portal front-end, and then uses the API to the TCS provider (DigiCert) for requests and issance. This poses some interesting challenges, detailed by Jana in her presentation linked ot the agenda. Being a non-English speaking country, there are issued with the naming, but also with validation as usual "US" things like DUNS are not commonly used in CZ, or lack validation info commonly used for OV and EV validation. Validation - it being a manual process - will always be challenging, and the fact that DigiCert recently acquired Symantic will surely put of the pressure on the validaiton staff, but - on a case by case basis - these can be resolved through support. However, the use of the API and the local portal make changes less transparent. This is something to keep in mind when you decie on building your own portal :( Unfortunately, the DigiCert portal is not available in Czech. Translations provided (by Marc) for French and by GARR for Italian have not been taken up fully - email messages can now be in french, but not the portal which is only US English and Spanish. In contrast, EJBCA 6.10+ now has customisable CSS and language support. Maintaining your own portal also has other issues: the removal of KEYGEN support in browsers makes them suddenly break. The UKeScience CA uses a stand-alone tool (CertWizard) or scripts (see also http://www.ngs.ac.uk/ukca/pecr.html) for requests. Bypassing KEYGEN with Russian Javascript cannot write to disk. But there are new development in industry (to be announced shortly) with plugins that would restore request functionality to some browsers. In Jan 2018 this should be there. There are also command-line tools for DigiCert's API. See http://software.nikhef.nl/experimental/tcstools/ And Google Business is not a good source of validation, at least not in CZ. IPv6 support ------------ The larget date by which ALL authorities must have an IPv6 capable CRL URL endoint is March 2018. You can use Couldflare to offload this for free if you cannot get native IPv6 to your current web servers. Short status updates: CNRS will install a proxy for IPv6 for the new government-operated CAs also for the IGTF use cases; DarkMatter will have IPv6 on their native infrastructure (not in QV); DigiCert recently changed CDN provider and could now maybe do it (to be investigated via the TCS PMA); GridCanada is now hosted by ComputeCanada, lilely at Fraser, and needs an status update; KISTI will get it shortly (weeks); and PolishGrid should have no issues given that it's at PSNC. OGF and CAOPS ------------- The OGF has - dependent on area - a varying level of activity. Networking is extremely active, for example. And OGF offers a document publication process and the ability to push recommendations to ISO/IEC through JTC1 SC38. However, the immediate value to the IGTF community for an ISO standard is not obvious yet. The work output from the OIDC Fed group could have outputs that are suitable for OGF. Yet the consistency of the OIDC specs managed in the IETF should be maintained. CAOPS OGF meetings can be co-located with the IGTF meetings (and have been once in a while), although that tends to disengage non-IGTF members, for which co-locating with an open meeting would be preferable. PMA operational matters, review, and accreditations --------------------------------------------------- - For the pending self audits, the one for DZeScience was completed successfully, others are pending either updates or reviewer comments. We remind authority members that it should be the intention to complete also the review process in time. Other notes are in the members-only Wiki - DarkMatter will send the response to the open June 12th questions which have already been addressed. Then it will be accredited based on two positive reviews and distributed (the self-hosted ones as well). - PLEASE look at the validUntil date of your Root and ICAs once in a while, when you get a warning from the Chair, it's too late ... Other updates ------------- - We should register our assurance profiles with IANA actually as per RFC6711. This needs a URI (e.g. "http://igtf.net/ap/loa/dogwood") in addition to the current oid. An "urn:oid:1.2.840.113612.5.2.5.4" would look strange and opaque in the registry at https://www.iana.org/assignments/loa-profiles/ - Please enable IPv6 for CRL downloads as soon as possible. Use the mechanism described by Jim Basney for free use of CloudFlare if local IPv6 is not yet available. Please ensure IPv6 connectivity before the March 2018 target date. - The AAAI Pathfinder service AAAI Pathfinder is a service to use the Jisc Assent (Moonshot-based) service to issue BIRCH-assurance credentials in the UK for selected organsiations. The need for BIRCH comes form the fact that they need to be useful to access PRACE resources [although: PRACE could do DOGWOOD as well, given their central LDAP registry - this is for PRACE to discuss :)]. The pilot service is ready, and will now be based on explicit whitelisting of compliant IdPs, since Assent is nto able to prove the assurance or compliance framework for IdPs. A new CP/CPS will come soon. Attendance ---------- We would like to thank the following members for the in-person attendance: Jan Chvojka, Jana Kejvalova, Dave Kelsey, David Groep, Marc Turpin, Derek Simmel, Eisaku Sakane, Hiroyuki Matsunaga, Eric Yen, Sang-Un Ahn, Jens Jensen, Cosmin Nistor, John Kewley, and Mike Jones and for their extensive presence in the videoconference: Reimer Karlsen-Masur, Miroslav Dobrucky, Angelo de Souza Santa, Licia Florio, Jim Basney, Christos Kanellopoulos, Alejandro, and Lidija Milosavljevic