...
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 |
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. |
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. |
+1's | Nick Roy, InCommon |
...
Title | Investigate and test privacy enhancing technologies |
---|---|
Description | During REFEDs at TechEx2017,and later-on during TechEx2017 itself, a interesting discussions developed over the future of federation, the role of users and the use/rise of proxy technology. This activity investigates and showcases privacy enhancing technologies including, but not limited to, PEP (Polymorphic Encryption Pseudonyms) (1) and IRMA (I reveal my attributes) (2) and tests and validates applicability and usecases of these in the context of R&E federations and eduGAIN.
|
Proposer | Niels van Dijk, SURFnet |
Resource requirements |
|
+1's | |
References | (1) https://blog.surf.nl/en/privacy-surfconext-using-polymorphic-pseudonyms/ |
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 |
Title | eduroam DEEP Learning |
---|---|
Description | Based on Brooks idea, we train a DEEP network to detect eduroam breakage based on log-data. Possible joint work with Juniper Research. Leif will provide more information |
Proposer | Leif |
Resource requirements | To be better scoped, but certainly resources. |
+1's | I'll give this one a "sounds cool, need more info" Nick Roy, InCommon |
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. |
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 |
You do not have to fill in every field, just give as much detail as you have right now if you know them.