...
| Title | eduGAIN Federated Service Catalogue |
|---|---|
| Description | At the moment, the only way you get an overview of services in eduGAIN is via metadata. While this is how the system is designed to work (machine to machine), service info is also interesting to humans e.g. to browse, to know if an SP already exists etc. A preliminary WG is starting in REFEDs to look at how service catalogs could be built. An eduGAIN level catalog should build on that work and also integrate with other relevant catalogs e.g open science cloud, NREN's own catalogs etc. |
| Proposer | Ann Harding |
| Resource requirements | Standardisation/spec via refeds Prototype implemention for aggregation. Protoype implementation for federation level infra. Pilot. |
| +1's | Wolfgang Pempe (DFN): encourage cross-federation support for mdui:Keywords. SURFnet: no catalog will survive if the (meta)data is not/cannot be maintained or is not of sufficient quality. I think therefore we need to address the root cause (as well). How prevent keeping a shadow "metadata" registry for this? José Manuel, SIR/RedIRIS: We are developing such a service catalog for our federation now, and am interested in this. Also, agree with Wolfgang, and SURFnet... regarding the SURFnet question, the catalog could have both "static" (collaborative information, with the possibility of letting the providers administrate its own information) and "dynamically gathered" information (from metadata) for a certain entity in the catalog. Rhys Smith, UKf: I think it's a laudable goal, and one worth exploring. For me, there are two main issues - deciding categorisation in way that works for everyone, and appropriate resourcing to both do the initial step of building the catalogue and effort to maintain it moving forwards. As soon as it's not kept up to date, it's not useful any more. Mario Reale (GARR) - Relevant to ease human-friendly interaction with eduGAIN. |
| Title | Scope verification based on DNS |
|---|---|
| Description | The scope part of attributes means critical security context for many applications. Currently the only way for an SP to check whether an IdP is allowed to use a scope is based on verification of shibmd:Scope metadata extension. As metadata might originate from a massive number of sources, an organization and/or an SP might want to provide additional means to verify scope usage. If the scope equals to a real domain name, it can be easily implemented by adding TXT records to the domain record that describe the allowed entityIDs which can assert the scope. (Similar to SPF - Sender Policy Framework.) This should be an optional measure in addition to existing metadata-based scope verification technique. |
| Proposer | Kristof Bajnok (eduID.hu) |
| Resource requirements | standardization - REFEDs? implementation for Shibboleth and SimpleSAMLphp |
| +1's | Nick Roy, InCommon Constantin Sclifos, RENAM Rhys Smith, UKf: Sounds like an interesting idea. Would require changes to SP software though, of course, which means it'd be a very long term rollout. Worth exploring the idea in principle though. Worth taking a closer look at this (Mario Reale /GARR) |
| Comments | SURFnet: Can this be solved by making this the responibility of the registar. Speaking for a hub-and-spoke registrar that already does it this way, forcing IdPs to administer TXT records for this is quite a burden for them. Kristof: the concept is to provide an end-to-end solution to protect the scopes that works even with broken metadata sources/registrars. Wolfgang Pempe, DFN: "can be easily implemented" sounds harmless, but carrying this out on federation level implies contacting several hundreds of IdP operators and providing support to them... |
...
| Title | Statistics for federation |
|---|---|
| Description | Development of statistical solutions for federation that show the number of federated accesses from the member institutions of a federation, besides the indication of the most accessed Service Providers. |
| Proposer | Jean Carlo Faustino |
| Resource requirements | Standardisation and collaboration |
| Comments | Wolfgang Pempe, DFN: How is this supposed to work for a full mesh federation? |
| +1's |
| Title | SOC tools |
|---|---|
| Description | GEANT should develop and maintain a toolchain for security operations (SOC) teams. This includes work on stuff like grr, plaso, timesketch, information sharing platforms, threat intelligence platforms etc |
| Proposer | Leif |
| Resource requirements | To be better scoped, but certainly resources. |
| +1's | This is similar to a proposal submitted under the security white paper planning. Talk to Sigita Jurkynaite about this. |
| Comment | SURFnet: We support the notion of having good security operations in trust and identity but in the geant project this should probably be developed in the security activity. Rhys Smith, UKf: Agree with SURF, sounds interesting, but isn't this a security area topic? |
...
| Title | Identity Discovery |
|---|---|
| Description | GEANT should operate a discovery service for the global identity ecosystem based on the outcomes of the RA21 process and dialogues with the research infrastructure community. If possible the service should be useful for the eIDAS community aswell. |
| Proposer | Leif |
| Resource requirements | To be better scoped, but certainly resources and budget |
| +1's | Nick Roy, InCommon SURFnet Rhys Smith, UKf: +1 in principal, but reserving judgement until we see the output of RA21 to be able to understand the scope of this. Wolfgang Pempe, DFN: agree with Rhys. An embedded DS should always be the first choice, anyway. Mario Reale, GARR: agree with Rhys Smith's comment. |
| Title | Enhance eduGAIN ops instrumentation with general metadata dashboard and augment existing eduGAIN API to query said stats |
|---|---|
| Description | The eduGAIN technical website would benefit it's members by having a central overall status dashboard that renders a single page with eduGAIN stats with initial focus on latency estimates for metadata circulation. This page should auto-refresh every X seconds/minutes as a configuration. It would be a 'nice to have' if this were operationally friendly such that someone could have it presented in their NOC control center on a screen and also have the data published at an API endpoint such that someone can publicly poll the information in JSON and then in turn render it on their own. The problem this addresses is the knowledge gap about the state of the system without requiring operational questions or gueses. Many federations exhibit latency on republishing stemming from operational practices and offline signing techniques. It would be helpful to know in a dashboard fashion the following:
This will go a long way in managing expectations of when to expect data to circulate beyond '24-48hrs'. I suggest a simple table view of flag and age difference from MDS so we may know how far we all drift from each other republishing data from the eduGAIN MDS 'creation date'. |
| Proposer | Chris Phillips, CANARIE |
| Resource requirements | This is an effort item, likely on eduGAIN OT with some API work too. I estimate it to be small (few days/1 week?), but highly useful and potentially a marketing tool as well. |
| +1's | CAF, obviously SURFnet Rhys Smith, UKf: We've actually just been talking about how something like this would be good. I'm sure Sirtfi folks would be interested in this as well as it directly impacts on the time to full resolution for security incidents mitigated by MD changes. Wolfgang Pempe, DFN |
...
| Title | A Global Trust & Identity Management Lab Platform |
|---|---|
| Description | The most interesting session that I had at TechEx 2017 ACAMP was asking "How do students federate an application?" with Fed-Lab.org and TestShib.org existing - but not solving all of the edge cases for new applications and especially new developers. A student can pick a framework off the self - run through tutorials and then connect their application to a host of services (Github, Twitter, Facebook) but SAML often isn't an option - and even if it is - there is a lack of enviornments that a student/new developer can jump into to make their tool work. This needs to be solved to support new developers, create a sandbox for development and expose SAML integration for various frameworks. Include OIDC |
| Proposer | Brook (stolen from Andre Marins idea @ TechEx ACAMP 2017https://docs.google.com/document/d/1mvD27mGJQIkvaqXESijDKWrYKvF_ZlC-Ucb-gWRCJjo/edit ) |
| Resource requirements | |
| +1's | Mario Reale / GARR |
| +/-1's | Potentially a nice idea, but would need to consider the use cases more to decide whether i'm +/- 1 on this - if there would be enough users, and it'd be useful enough to them, then +1. Otherwise, it's a distraction. |
...
| Title | Response Testing for Security Contacts |
|---|---|
| Description | Simple response testing process for security contacts in federation metadata. Could replicate the process currently used by Trusted Introducer. |
| Proposer | Nicole Harris |
| Resource requirements | money, infrastructure |
| +1's | Thomas Lenggenhager (SWITCH) provided you are careful not to annoy the security contacts Wolfgang Pempe (DFN): our plan is to perform some test alarm at least once a year Tom Barton: +1, and let's try to ensure that each contact is tested by only one testing activity, ie, perhaps the Geant activity should be formulated as a complement to other activities that are/will test contacts in their federations/areas. Scott Koranda for LIGO +1 Rhys Smith, UKf: Exactly the same comment as Thomas. Good idea in principal, but have to be VERY careful not to annoy security contacts, as they'll stop responding in a timely manner if all they generally get is test messages. Would suggest consultation with CSIRT folks about how they do this today, and follow that model. Mario Reale: +1 - of course avoiid spamming |
| Title | Query service for Sirtfi |
|---|---|
| Description | API to query whether an entity supports Sirtfi. In addition, a mechanism for asserting Sirtfi compliance outside federation metadata. |
| Proposer | Hannah Short (with Nicole Harris and Ann Harding) |
| Resource requirements | money, infrastructure |
| Comments | Rhys Smith, UKf: Wot Lukas said - Can find this out from MD already? Is there enough evidence from potential users that a different way to get this info would significantly improve their lives? Scott Koranda, LIGO: No, one cannot find this out from MD already because immature federations do not support their entitites being able to register SIRTFI compliance. This is not likely to change soon enough to satisfy the needs of large international projects like LIGO and CERN. Having a separate SIRTFI registration process outside of eduGAIN metadata is necessary and strongly desired by those communities. Rhys again: My comment is not about helping federations that can't register Sirtfi, it was purely about the first part - an API query to find out whether an entity supports Sirtfi. These two items are separate things and shouldn't be conflated, as neither / either / both could be worked on. So i'm unsure about the API bit, c.f. my comment. I'm broadly +1 for the second bit - not a fan ideologically, but pragmatically can see the benefits. |
| +1's | (Wolfgang Pempe, DFN: outside federation metadata? IMHO not a good idea. This would lead to inconsistencies.) Tom Barton: Once Wolfgang hears the details, he'll say it's a good idea! Lukas Hämmerle, SWITCHaai: I don't exactly see the need for a query service if this information can be relatively easy retrieved from metadata. Then again I suspect this would be relatively easy to implement and given that there is already an API (https://technical.edugain.org/api.php) to query all sorts of eduGAIN-related things, this would probably be only a small addition. (Comment from Scott Korand to Lukas–it cannot be easily retrieved from metadata because not enough federations are mature enough to support entitites registering Sirtfi. The descrition includes "outside federation metadata" as it should.) SURFnet:
Scott Koranda for LIGO +1 Mario Reale / GARR |
| Title | Reputation Portal |
|---|---|
| Description | A way to flag bad (or good!) behaviour of entities, e.g. Sirtfi compliance, LoA misuse, CoCo violation |
| Proposer | Hannah Short (with Nicole Harris and Ann Harding) |
| Resource requirements | money, infrastructure |
| Comments | Rhys Smith, UKf: Interesting idea in theory, but need to articulate potential users of this portal, how they'd consume the information, who would moderate it (could easily do bad things with such a portal), and who would manage it. Wolfgang Pempe, DFN: I agree with Rhys |
| +1's | Scott Koranda for LIGO + 1 Mario Reale / GARR |
| -1's | SURFnet: Sounds like trying to solve a non technical problem (trust) using technology |
...
| Title | Adoption & Outreach Support for eduGAIN BCP |
|---|---|
| Description | BCP for eduGAIN will be launched in 2018. Federations should be supported to gain adoption by campuses |
| Proposer | Ann H on behalf of several |
| Resource requirements | Funding for outreach and adoption efforts at each GEANT partner, strategic/materials support for all. |
| Comments | Wolfgang Pempe, DFN: What about SPs? "Campuses" means IdPs, right? Please refer to my -1 comment on the IdP Maturity item below. |
| +1's | Nick Roy, InCommon, SURFnet Rhys Smith, UKf: Yes. Mario Reale / GARR |
| Title | Allow eduGAIN OT to enrich MDS metadata |
|---|---|
| Description | Currently, metadata is controlled exclusively by federation operators, which is generally good. However, there will pop up use-cases where it is more efficient, a lot faster and definitely more agile to allow eduGAIN OT to enrich eduGAIN metadata centrally with some entity categories because if all 50+ federations have to do something, it will take years and effort to set some entity category is duplicated for each federation. |
| Proposer | Lukas Hämmerle, SWITCH |
| Resource requirements | Policy might need to be changed, it would have to be defined what/what not eduGAIN OT reasonably could and should do. Some (limited) implementation effort on MDS might be needed. |
| +1's | Nick Roy, InCommon Tom Barton: Although "Query service for Sirtfi" above is formulated as a query service, it might best be implemented as an enrichment by eduGain OT to metadata. Should these two proposals become one? Niels van Dijk, SURFnet: I would be really interested in how distributing the trust between decentralized federations and central OT would work. Hannah Short, CERN Constantin Sclifos, RENAM Scott Koranda, LIGO |
| +1-1 = 0's | Rhys Smith, UKf: -1 because federations should really do this, not eduGAIN, which should just be an aggregator of MD, not producer. But +1 because I understand many federations don't and won't have the ability to do new stuff. So my votes cancel themselves out. So ignore me. Mario Reale / GARR : I am not sure is a zero or is slightly positive nevertheless. I fully understand the need, but role change for eduGAIN sort of worries me. |
| -1's | SURFnet: Many worries: role of aduGAIN of aggregator that is now going to modify metadata (SURFnet) Wolfgang Pempe, DFN: I agree with SURFnet. If there's a really strong need for this approach (which I don't see at the moment), we could perhaps consider a solution, where federations can (actively!) delegate the task of adding ECs (or whatever) to their metadata to the eduGAIN OT - which would be very pleased, I suppose |
...
| Title | IdP Maturity |
|---|---|
| Description | In the current eduGAIN SAML Profile work there is an effort to develop BCP to position a lot of the current "step-up" processes we have as a set of best current practice for eduGAIN. Within eduGAIN, these will be positioned as what we consider mature entities / federations to look like...and this could even possibly be flagged somehow. The current requirements of eduGAIN will be promoted purely as a baseline and a "first step" to interoperability (acknowledging use cases that don't need any more than that). The next logical step from that is to review whether there is any need to offer a central service to manage that maturity level for federations / entities as a bolt on to existing federation operations. This could take on a variety of forms and draw in a lot of the areas that have been proposed here. Options and areas could be: |
| Proposer | Nicole Harris |
| Resource requirements | It depends on the direction taken. Man hours in eduGAIN-OT for developing services, work for a policy lead, work to enhance eduGAIN support service. Possible infrastructure development |
| +1's | Nick Roy, InCommon Rhys Smith, UKf: Sounds interesting, as long as long as we can decide what a "mature" federation/entity is, and who would be consuming this information, and for what purpose. |
| -1's | Wolfgang Pempe, DFN: I'd rather favour some work on SP Maturity. There are so many crappy SPs around, especially commercial ones. It seems to me that the prevalent tendency in the T&I-related GÉANT activities (and REFEDS) is to impose more and more obligations on IdP operators, for instance in terms of levels of assurance. That's IMHO a bit unfair... |
| Comments | SURFnet: It is unclear to us what is the purpose for this work and who will be the users. Mario Reale / GARR - same sort of concerns as previous item. However in general, I prefer to address the trust issues at the lower level of the stack: the federation themselves. |
| Title | Jupyter Notebook for Metadata Management + Decoration |
|---|---|
| Description | The predominate metadata aggregator used by federations joining eduGAIN is pyFF.io and having a Jupyter Notebook to allow these people to work through the metadata aggregation, selection or exclusion and decoration would be useful in training people to use this tool. |
| Proposer | Brook |
| Resource requirements | People smarter than Brook, time, money |
| +1's | Mario Reale / GARR |
| Title | Two Factor (something) |
|---|---|
| Description |
|
| Proposer | From data gathering exercise |
| Resource requirements | <money? effort? coordination? infrastructure?> |
| +1's | <for others to voice their support - add your name here> |
| -1's | Wolfgang Pempe, DFN: I believe this is out of scope for GÉANT, you would need a dedicated organization for that purpose |
...
| Title | Global Push-MDQ Infrastructure |
|---|---|
| Description | Build a global, shared infrastructure for federations to submit/publish per-entity metadata to eduGAIN, and have those updates be pushed via messaging infrastructure to subscribers. This will enable more rapid metadata updates and a global per-entity metadata distribution infrastructure. It should be possible to accommodate multiple federations submitting/publishing metadata for the same entityIDs, and consumers can subscribe to whichever version they choose. NOTE: This may also facilitate a solution to IdP discovery in a per-entity metadata world. |
| Proposer | Nick Roy |
| Resource requirements | Money, effort, standardisation, coordination, infrastructure, operations |
| +1's | Chris Phillips - CANARIE – see related collab area: https://wiki.refeds.org/display/GROUPS/Incubator Rhys Smith, UKf: Still not 100% convinced of the use case as MDQ is still immature so we don't yet understand its characteristics fully. But an interesting topic to investigate that might have nice properties. Wolfgang Pempe, DFN: agree with Rhys |
...