...
| Title | IdP / SP 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. |
eduGAIN "Disruptive"
Changes to Metadata Approaches
| 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 | 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 |
| Title | Storing History and Evolution of Metadata in a Distributed Ledger (this sounds too far down the TRL for a proposal to GNX?) |
|---|---|
| Description | The aggregated metadata of eduGAIN is under constant change as entities get added, removed, or changed. While daily backups are made, there is no event-based changelog and no trace of which change was made when. When an entry of interest is examined, the search for the exact event timestamps of changes pertaining to that entry are tedious by searching old copies of the entity database manually. The proposed system stores any change to the metadata aggregate one-by-one in a ledger as soon as it happens. That way, even intra-day changes (between daily database backups) can be observed and a "rewind" of the entity list to specific point in time becomes simple. For improved traceability of any changes, the ledger can be made distributed and authenticated in the way that both the publishing eduGAIN participant (sending side) and the eduGAIN OT (receiving side) both sign the change in a distributed ledger. The ledger would be distributed so that each eduGAIN federation maintains a copy. With that, changes made automatically synchronise between federations and a manual polling of per-participant feeds (by eduGAIN OT) as well as a periodic download of the aggregate (by eduGAIN participants) becomes superfluous. eduGAIN OT still maintains its role as metadata policy verifier by signing only such changes in metadata which result in eduGAIN policy conformant metadata. As a positive side-effect, this changes the granularity of metadata rejection from a per-participant (country-wide) effect to a per-entity effect, reducing outages due to metadata of entire participant federations vanishing. The solution developed here is not limited to eduGAIN exclusively; it can also be used inside a federation to collect and sign individual pieces of metadata, thereby assembling its own metadata set in the same way. Where IdPs or SP choose to maintain a copy of the ledger, they can immediately and in real-time see any changes and implement them in their entity; resulting in an experience similar to the MDX proposal above. They can choose to incorporate only entries signed by their own federation, or a superset to their liking. |
| Proposer | Stefan Winter (RESTENA) |
| Resource Requirements | VMs, storage for the ledger, a blockchain implementation, someone to work on that so it fits our needs |
| +1's |
| Title | Metadata Entity Decoration Distributed Ledger (this sounds too far down the TRL for a proposal to GNX?) |
|---|---|
| Description | This proposal is to experiment with distributed ledger technology as a pilot aimed for production to provide a live and auditable record of who has claimed what about any entity and in turn, leverage these entity claims to augment existing metadata as well as other future protocols in a variety of ways. Metadata decoration, regardless of protocol(SAML,OIDC,ABFAB,etc) is challenging to do at scale and equally challenging to do in a trustworthy way economically. By using the features of a distributed permissioned ledger there is an opportunity to leverage our rich set of entities in our respective trust fabrics. Each entity already has cryptographic keys to ‘go on record’ and assert things about other peer entities. These assertions in the distributed ledger would be signed using the existing keypair that each entity controls to indicate the authenticity of the claim. These claims can be verified leveraging the existing key distribution in our metadata. The distribution of said claim is handled by the decentralized ledger and thus reduces overhead in overall operations and has resiliency aspects over a centralized service. These claims could indicate almost anything. Some interesting ones may be:
Anyone publishing or handling metadata can then choose to merge (metamerge?) their choice of any or all of the above into their metadata and sign it. Similarly, use cases exist for those already receiving our metadata to ‘listen’/read’ certain things from the distributed ledger to augment the metadata for their own purposes: e.g. render enhanced discovery for service only showing SIRTFI compliant entities or showing entities that are in my community of interest, etc This is especially interesting as our federations move toward MDQ as a way to achieve more near real time delivery of elements about entities. Decision of what to merge and consider ‘appropriate decoration’ is always in the hands of the person/process merging the data be them federation, identity provider, or service provider operator. This is done by determining which keys sign which claims and which keys will be considered anchors for the claim. If another entity attempted to sign a same claim, the validation would fail because it would not be signed by the right anchor or authority. Other interesting features of this approach is that it is a distributed ledger system and thus decentralized and lends itself well to our geographically diverse community. Another benefit is the ledger technique is agnostic to underlying trust-fabric technology. Usage examples: Populate only SIRTFI OIDC Ops for discovery. Show only members of a community of interest in a given user interface in moonshot, indicate which IdPs are in govroam and/or eduroam etc. |
| Proposer | Chris Phillips |
| Resource requirements | A group of interested participants to assist with initial structure and would contribute a portion of time to the activity 3 – 18 months depending on how robust one would want things and who participates. I can better elaborate if there are more +1's here Niels: This might be build on top of existing work in GEANT project from Linus (certificate transparency) |
| +1's |
Training and Support
| 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 | 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 |
Software / Service Development
| Title | Last_seen() |
|---|---|
| Description | Federated AAI is poorly equipped to support SPs in dealing with the depreciation of users by the IdP. Outside of at login time, the SP basically has no way of finding out the user is no longer a user at an institution, save perhaps sending out emails. A mechanism to allow SPs to learn about a user status would help SPs immensely to keep data accurate and at the same time improve privacy and data protection. This activity should investigate push and pull scenarios and propose and implement example solution(s), in collaboration with entities that produce commonly used software products in our space. Retaining the privacy of the enduser in the process is paramount! |
| Proposer | Niels (SURFnet) |
| Resource requirements | money, software dev, standarization |
| +1's | Wolfgang Pempe (DFN): the current approach (at least in our federation) is to perform periodical attribute queries with SAML2 Persistent NameID, which leads to quite some problems. SURFnet: +1 |
| Title | Reference implementation of an IdP and OP in Python |
|---|---|
| Description | The current GN4-2 projet has invested heavly into the Python stack for OpenID Connect (federation) and it should be good to put together a full blown home organisation IdP/OP based on this work and earlier work with the SAML stack. This imlementation should support all current best practices in eduGAIN and retrie attributes from different sources. |
| Proposer | Pål Axelsson on behalf of Sunet |
| Resource requirements | money, software dev |
| +1's | Stefan Winter Nick Roy, InCommon Niels van Dijk, GEANT 4-2 Project; This should be carried out in close collaboration with the pyid.org community |
| 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 | (SURFnet) |
| References | (1) https://blog.surf.nl/en/privacy-surfconext-using-polymorphic-pseudonyms/ |
| Title |
|---|
Two Factor (something)
Drive two factor towards ubiquity with low cost - create an eduToken (for the users that do not have a phone; critical mass can bring down the price even more. It can be implemented as a kickstarter campaign).
Challenges in deploying multi-factor in EU, partially due to the costs and partially due to the cost involved. A cost-effective approach would help.
An edu-token as a separate ‘token’ may reintroduce token management aspects (losing the token etc)
management is (will be even more) a non issue as the majority of people will use phones. We should strike for that.
- Technically this problem can be solved, taking the above considerations into account.
The real problem is how to scale the token vetting over EU. This is especially challenging for research collaborations.
update SAML tracer - get this done in GN4-2 | |
|---|---|
| Description | The SAML Tracer (https://addons.mozilla.org/nl/firefox/addon/saml-tracer/) is a highly rated firefox plugin which was developed in our community (UNINETT, with contributions from others). As the browser is the central entity in any SAML transaction, it is extremely convenient tool for testing en debugging SAML transactions. There are not many alternatives to this tool Unfortunately, Firefox has changed its plugin framework, rendering the existig plugin useless and a major rework is needed. |
| Proposer | Niels van Dijk, SURFnet |
| Resource requirements | Money, a (junior) developer |
| +1's | Stefan Winter Scott Koranda, LIGO Nick Roy, InCommon Thomas Lenggenhager, SWITCH:Feasibility to provide also a version for Safari compatible version? Thanks José Manuel, I now found the SAML Chrome Panel! Pieter van der Meulen (SURFnet) Michael Domingues (University of Iowa) José Manuel, RedIRIS/SIR. Regarding Thomas question, there's a SAML Chome Panel extension for Chrome Wolfgang Pempe, DFN MIchael Brogan (University of Washington) Nate Klingenstein (The California State University) Marcus Mizushima (The California State University) Andrew Morgan (Oregon State University) David Bantz (U Alaska) Brent Putman (Georgetown University, Shibboleth Developer Team) Liam |
| Title | update SAML tracer - get this done in GN4-2 |
| Description | The SAML Tracer (https://addons.mozilla.org/nl/firefox/addon/saml-tracer/) is a highly rated firefox plugin which was developed in our community (UNINETT, with contributions from others). As the browser is the central entity in any SAML transaction, it is extremely convenient tool for testing en debugging SAML transactions. There are not many alternatives to this tool Unfortunately, Firefox has changed its plugin framework, rendering the existig plugin useless and a major rework is needed. |
| Proposer | Niels van Dijk, SURFnet |
| Resource requirements | Money, a (junior) developer |
| +1's | Stefan Winter Scott Koranda, LIGO Nick Roy, InCommon Thomas Lenggenhager, SWITCH:Feasibility to provide also a version for Safari compatible version? Thanks José Manuel, I now found the SAML Chrome Panel! Pieter van der Meulen (SURFnet) Michael Domingues (University of Iowa) José Manuel, RedIRIS/SIR. Regarding Thomas question, there's a SAML Chome Panel extension for Chrome Wolfgang Pempe, DFN MIchael Brogan (University of Washington) Nate Klingenstein (The California State University) Marcus Mizushima (The California State University) Andrew Morgan (Oregon State University) David Bantz (U Alaska) Brent Putman (Georgetown University, Shibboleth Developer Team) Liam Hoekenga (University of Michigan) Terry Smith (AAF) Dalia Abraham (AAF) Daniel Lutz (SWITCH) Etienne Dysli Metref (SWITCH) Martin Haase (DAASI) Rod Widdowson (Steading System Software, Shibboleth Developer Team) Allan West (University of Florida) Dominique Petitpierre (University of Geneva) Cédric BRINER (University of Geneva) Eric Yurick (Gettysburg College) Vlad Mencl (Tuakiri/REANNZ) |
Above and Below eduGAIN (inc. eScience requirements driven activities)
...
eduTEAMs Related
| Title | eduroam SP-as-a-service |
|---|---|
| Description | With eduroam Managed IdP, there is a service which takes all RADIUS hassle off of Identity Providers. There is no equivalent for eduroam SPs. I.e. a future eduroam SP either needs to set up a local RADIUS server and connect it to the NRO, or (if the NRO supports it) connect the Wireless Controller directly to an NRO server - losing all advanced features such as VLAN assignment. For small hotspots, there is a possible additional complication if the hotspot has a dynamic IP address, which makes the interconnection via RADIUS' shared secrets infeasible. Right now, such potential hotspots are not serviceable by eduroam infrastructure. The goal of this activity is to create a self-service web portal where any prospect SP can register his hotspot (requiring sign-off by the NRO; comparable to eduroam Managed IdP) - regardless whether he has a static IP address, a dynamic one, or doesn't even know what an IP address is in the first place. The new hotspot's RADIUS connectivity is tested in real-time (e.g. using a credential from eduroam Managed IdP, a good complement to this service) and the new SP is instantly connected to the eduroam infrastructure. Where the NRO admin confirms that a particular hotspot maps to a specific realm or Managed IdP instance, the SP can even get VLAN ID assignments for his own users (that part of the use case is possibly a bit weak as an SP who does not know about setting up a RADIUS server likely also doesn't know about VLANs to begin with). For the technicalities of the uplink itself, there should be support for multiple attachment anchors (=RADIUS servers behind the web interface) because geographical proximity to the hotspot is important for performance reasons. The remaining complexity for the SP which this service will not take away is: phyiscal installation of APs, controllers, and the configuration of those so that they are providing proper local eduroam. To ensure service quality on such "no clue" SPs, it could be made mandatory to install a probe at the site so eduroam Operations can monitor the hotspot quality. |
| Proposer | Stefan Winter |
| Resource requirements | VM for web interface, VMs for RADIUS attachment anchors, a clever idea how to handle registering hotspots with dynamic or unknown IPs |
| Comments | Rhys Smith, UKf: just to say that Jisc Liberate, our managed SAML IdP/eduroam IdP/eduroam SP/ABFAB IdP/ABFAB SP/web proxy service, will have the eduroam SP bit towards the start of 2018. Stefan's description is a slightly different use case, however, so I think it doesn't really overlap here. |
| +1's | Rhys Smith, UKf: sounds like a good way to get new visited eduroam sites on board. |
| 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 Can be integrated via existing diagnostics context: Existing work evaluation#eduroamdiagnostics so gets a +1 from prior endorsements too. (note from AH) Should x-ref with the network perf folk. Talk to Kurt Baumann(Note from AH). Georgi Tsochev, BREN Rhys Smith, UKf: Wot Nick said. I prefer any machine learning method rather than "just" Deep Learning, although the name is more appealing. (Hideaki Goto, NII) |
| Title | Scale eduroam infrastructure to the size of WIFI4EU |
| Description | There were a multitude of reasons why the GÉANT community couldn't run the infrastructure for WIFI4EU. Sufficient issues were exposed by managing this as a single centrailsed infrastructure (partially addressed by "get eduroam", "eduroam DEEP Learning", "eduroam SP-as-a-Service"). By identifying all the scaling blocks to existing eduroam services we'd be able to offer advice, guidance and technology push into govroam, WIFI4EU and eduroam services to support the existing infrastructure and development in new territories. |
| Proposer | Brook |
| Resource requirements | People |
| +1's | Georgi Tsochev, BREN Reimer Karlsen-Masur, DFN-PKI Great chance to accelerate the deployment of secure public Wi-Fi systems in the world and to inter-connect them. Related to my proposal of inter-roaming, but a separate work item dedicated to WiFi4EU is still preferred. (Hideaki Goto, NII) |
| Title | Develop inter-roaming architecture and "eduroam on NGH" |
| Description | Develop an inter-roaming architecture that connects various Roaming Consortia (RC) including eduroam, govroam, City Wi-Fi (secured), WiFi4EU, etc. to enable roaming, with or without Passpoint. Make the deployment of off-campus eduroam/govroam services much easier. For example, eduroam accounts can be enabled on City Wi-Fi world-wide. Contribute to the improvement of Hotspot 2.0 to make "eduroam on NGH" possible. (The current HS2.0 specifications and some implementations are known to have some issues hampering large RC creation.) Contribute to the revisions of the WRIX specifications to make them as much compatible as possible with eduroam's. WRIX-i (interconnect) and WRIX-L (location) are the targets. |
| Proposer | Hideaki Goto, NII (out of EU :) |
| Resource requirements | people, (more official and stronger) collaborative work with WBA, human network with WiFi4EU, WBA member fee if required |
| +1's | <for others to voice their support - add your name here> |
Future Certificate Services
...
certbot for all certificate management
...
Let's Encrypt and the certbot have made certificate management for 1 particular CA very easy and effective. With the addition of ACME v2 this will allow additional CAs to participate and allow the dev/test/production environments to automatically deal with certificates.
Work should also investigate eduPKI and Let'sRADSEC use of this mechanism for certificate maintenance.
TechEx 2016 ACAMP notes: https://docs.google.com/document/d/1o20NmuLjmNySp10QqfueO3of6jmoeTRfmgG4e_olZ_s/edit
...
Georgi Tsochev, BREN
Rhys Smith, UKf: Certbot is going to take over the world, so we should start doing stuff with it.
Reimer Karlsen-Masur, DFN-PKI
...
cryptech.is
...
CA CAB/Browser forum participation
...
Attribute Authorities
...
Discovery for Attribute Authorities (AAs)
...
Users can select their IdP via discovery, therefore the SP can potentially receive users from thousands of IdPs.
There is no such facility for AA-s however, meaning that SP-s need to hard-configure which AAs they query. Also, query all the configured AAs for all users all the time.
In GN4-1-JRA3-T1 it has been established that this is a serious bottleneck, as maximum 2-3 AAs can be queried without breaking the entire login session.
A better approach is needed. The SPs need to query AAs selectively, based on either user input or some alternative means, like some VO lookup service. Otherwise all SPs will just stick with the biggest AAs like eduTEAMS basic membership service or hexaa.eduid.hu and not query alternative entities, making single-tenant AAs very unattractive.
...
This is a hard one. Currently there is no support for any elements of this whatsoever
- Standardization
- SAML Stack development
- blood and sweat
...
Attribute Authority scoping information in Metadata
...
- Standardization
- SAML stack development
...
Attribute Authority Metadata policy development for eduGAIN
...
While for IdPs and SPs eduGAIN metadata requirements are well described, no such requirements exist for AAs. We have however already 5 of these entities in eduGAIN.
It would also be a good idea to consider/define what it would mean for an AA to claim CoCo, R&S and Sirtifi support
...
- Standardization
- Probably a no-brainer as much can likely be derived from IdP requirements (?)
...
Constantin Sclifos, RENAM
Nick Roy, InCommon
SURFnet
Rhys Smith, UKf: I think AAs will become more important as we move forward, and there is a gap here in policy that needs thinking about.
Wolfgang Pempe, DFN
eScience requirements driven activities
...
Placehoder to include (and potentially continue) some of AARC work
...
I would like to have a placeholder to include work that my be triggered by the revisited list of FIM4R requirements, as well as by AARC. Furthermore, I'd also like to include in this box liaisons with EOSC hub concerning their T&I architecture developments and adoption/support of FIM technologies. This item cannot and should not be more specific than this at this point in time.
...
Placeholder to include (and potentially continue) some of AARC work | |
|---|---|
| Description | I would like to have a placeholder to include work that my be triggered by the revisited list of FIM4R requirements, as well as by AARC. Furthermore, I'd also like to include in this box liaisons with EOSC hub concerning their T&I architecture developments and adoption/support of FIM technologies. This item cannot and should not be more specific than this at this point in time. |
| Proposer | Licia Florio |
| Resource requirements | Coordination work, resources |
| +1's | <for others to voice their support - add your name here> |
| Title | eduTEAMS enhancements |
|---|---|
| Description | eduTEAMS work is progressing; there are different options for deploying eduTEAMS. This work item looks at the requirements for eduTEAMS when used by eScience collaborations. There will be lessons learned after the pilot with the life science community. I propose we have a placeholder so work on this does not go off radar during the planning. |
| Proposer | Licia Florio |
| Resource requirements | Effort mostly |
| +1's | <for others to voice their support - add your name here> |
| Title | Discovery for Attribute Authorities (AAs) |
|---|---|
| Description | Users can select their IdP via discovery, therefore the SP can potentially receive users from thousands of IdPs. There is no such facility for AA-s however, meaning that SP-s need to hard-configure which AAs they query. Also, query all the configured AAs for all users all the time. In GN4-1-JRA3-T1 it has been established that this is a serious bottleneck, as maximum 2-3 AAs can be queried without breaking the entire login session. A better approach is needed. The SPs need to query AAs selectively, based on either user input or some alternative means, like some VO lookup service. Otherwise all SPs will just stick with the biggest AAs like eduTEAMS basic membership service or hexaa.eduid.hu and not query alternative entities, making single-tenant AAs very unattractive. |
| Proposer | Mihály Héder |
| Resource requirements | This is a hard one. Currently there is no support for any elements of this whatsoever
|
| +1's | Constantin Sclifos, RENAM |
| -1's | Wolfgang Pempe, DFN: Such a dynamic approach would raise issues concerning trust and privacy. An attribute authority must be in control of the list of SPs that are entitled to perform attribute queries and (possibly) recieve PII. |
StepUp
| 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 | eduTEAMS and guest IdPs (actually Identity Assurance) |
|---|---|
| Description | eduTEAMS and guest IdPs - use-cases: need to support social IDs and guest IdP, but it need additional LoA. Step up authN as a service is in the plan |
| Proposer | from data gathering exercise |
| Resource requirements | <money? effort? coordination? infrastructure?> |
| +1's | isn't this the work being done in IoLR +REFEDS? Some of it is - implementation in service contexts is not. It is expected any work in GEANT would do this, leaning on results from the above |
eduroam
| Title | eduroam SP-as-a-service |
|---|---|
| Description | With eduroam Managed IdP, there is a service which takes all RADIUS hassle off of Identity Providers. There is no equivalent for eduroam SPs. I.e. a future eduroam SP either needs to set up a local RADIUS server and connect it to the NRO, or (if the NRO supports it) connect the Wireless Controller directly to an NRO server - losing all advanced features such as VLAN assignment. For small hotspots, there is a possible additional complication if the hotspot has a dynamic IP address, which makes the interconnection via RADIUS' shared secrets infeasible. Right now, such potential hotspots are not serviceable by eduroam infrastructure. The goal of this activity is to create a self-service web portal where any prospect SP can register his hotspot (requiring sign-off by the NRO; comparable to eduroam Managed IdP) - regardless whether he has a static IP address, a dynamic one, or doesn't even know what an IP address is in the first place. The new hotspot's RADIUS connectivity is tested in real-time (e.g. using a credential from eduroam Managed IdP, a good complement to this service) and the new SP is instantly connected to the eduroam infrastructure. Where the NRO admin confirms that a particular hotspot maps to a specific realm or Managed IdP instance, the SP can even get VLAN ID assignments for his own users (that part of the use case is possibly a bit weak as an SP who does not know about setting up a RADIUS server likely also doesn't know about VLANs to begin with). For the technicalities of the uplink itself, there should be support for multiple attachment anchors (=RADIUS servers behind the web interface) because geographical proximity to the hotspot is important for performance reasons. The remaining complexity for the SP which this service will not take away is: phyiscal installation of APs, controllers, and the configuration of those so that they are providing proper local eduroam. To ensure service quality on such "no clue" SPs, it could be made mandatory to install a probe at the site so eduroam Operations can monitor the hotspot quality. |
| Proposer | Stefan Winter |
| Resource requirements | VM for web interface, VMs for RADIUS attachment anchors, a clever idea how to handle registering hotspots with dynamic or unknown IPs |
| Comments | Rhys Smith, UKf: just to say that Jisc Liberate, our managed SAML IdP/eduroam IdP/eduroam SP/ABFAB IdP/ABFAB SP/web proxy service, will have the eduroam SP bit towards the start of 2018. Stefan's description is a slightly different use case, however, so I think it doesn't really overlap here. |
| +1's | Rhys Smith, UKf: sounds like a good way to get new visited eduroam sites on board. |
| 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 Can be integrated via existing diagnostics context: Existing work evaluation#eduroamdiagnostics so gets a +1 from prior endorsements too. (note from AH) Should x-ref with the network perf folk. Talk to Kurt Baumann(Note from AH). Georgi Tsochev, BREN Rhys Smith, UKf: Wot Nick said. I prefer any machine learning method rather than "just" Deep Learning, although the name is more appealing. (Hideaki Goto, NII) |
| Title | Scale eduroam infrastructure to the size of WIFI4EU |
|---|---|
| Description | There were a multitude of reasons why the GÉANT community couldn't run the infrastructure for WIFI4EU. Sufficient issues were exposed by managing this as a single centrailsed infrastructure (partially addressed by "get eduroam", "eduroam DEEP Learning", "eduroam SP-as-a-Service"). By identifying all the scaling blocks to existing eduroam services we'd be able to offer advice, guidance and technology push into govroam, WIFI4EU and eduroam services to support the existing infrastructure and development in new territories. |
| Proposer | Brook |
| Resource requirements | People |
| +1's | Georgi Tsochev, BREN Reimer Karlsen-Masur, DFN-PKI Great chance to accelerate the deployment of secure public Wi-Fi systems in the world and to inter-connect them. Related to my proposal of inter-roaming, but a separate work item dedicated to WiFi4EU is still preferred. (Hideaki Goto, NII) |
| Title | eduroam/govroam on City Wi-Fi |
|---|---|
| Description | Develop an inter-roaming architecture that connects various Roaming Consortia (RC) including eduroam, govroam, City Wi-Fi (secured), WiFi4EU, etc. to enable roaming, with or without Passpoint. Make the deployment of off-campus eduroam/govroam services much easier. For example, eduroam accounts can be enabled on City Wi-Fi world-wide. Contribute to the improvement of Hotspot 2.0 to make "eduroam on NGH" possible. (The current HS2.0 specifications and some implementations are known to have some issues hampering large RC creation.) Contribute to the revisions of the WRIX specifications to make them as much compatible as possible with eduroam's. WRIX-i (interconnect) and WRIX-L (location) are the targets. |
| Proposer | Hideaki Goto, NII (out of EU :) |
| Resource requirements | people, (more official and stronger) collaborative work with WBA, human network with WiFi4EU, WBA member fee if required |
| +1's | <for others to voice their support - add your name here> |
Future Certificate Services
| Title | certbot for all certificate management |
|---|---|
| Description | Let's Encrypt and the certbot have made certificate management for 1 particular CA very easy and effective. With the addition of ACME v2 this will allow additional CAs to participate and allow the dev/test/production environments to automatically deal with certificates. Work should also investigate eduPKI and Let'sRADSEC use of this mechanism for certificate maintenance. TechEx 2016 ACAMP notes: https://docs.google.com/document/d/1o20NmuLjmNySp10QqfueO3of6jmoeTRfmgG4e_olZ_s/edit |
| Proposer | Brook (and a cast of thousands) |
| Resource requirements | People, Money, work to get standardisation of "realm validated certificates via RADIUS infrastructure" and maybe other paths. |
| +1's | Georgi Tsochev, BREN Rhys Smith, UKf: Certbot is going to take over the world, so we should start doing stuff with it. Reimer Karlsen-Masur, DFN-PKI |
| Title | cryptech.is |
|---|---|
| Description | |
| Proposer | |
| Resource requirements | |
| +1's |
| Title | CA CAB/Browser forum participation |
|---|---|
| Description | |
| Proposer | |
| Resource requirements | |
| +1's |
Attribute Authorities
| Title | Attribute Authority scoping information in Metadata |
|---|---|
| Description | It seems that AARC-JRA1.4A will propose "scoping of group membership information". However, there is no element in the SAML metadata that contains the scope of an AA, therefore, there is nothing to verify the scoped membership information against. The only way today is to learn about the scopes used by an AA entity via word-of-mouth and then apply those scopes in attribute value level filtering and access control rules, maintained manually in the SP config. Obviously this does not scale. |
| Proposer | Mihály Héder |
| Resource requirements |
|
| +1's |
eduTEAMS
...
eduTEAMS enhancements
...
| Title | eduTEAMS and guest IdPs |
|---|---|
| Description | eduTEAMS and guest IdPs - use-cases: need to support social IDs and guest IdP, but it need additional LoA. Step up authN as a service is in the plan |
| Proposer | from data gathering exercise |
| Resource requirements | <money? effort? coordination? infrastructure?> |
| +1's | isn't this the work being done in IoLR +REFEDS? |
Jupyter Notebook for Metadata Management + Decoration
| Title | Attribute Authority Metadata policy development for eduGAIN |
|---|---|
| Description | While for IdPs and SPs eduGAIN metadata requirements are well described, no such requirements exist for AAs. We have however already 5 of these entities in eduGAIN. It would also be a good idea to consider/define what it would mean for an AA to claim CoCo, R&S and Sirtifi support |
| Proposer | Niels van Dijk |
| Resource requirements |
|
| +1's | Constantin Sclifos, RENAM Nick Roy, InCommon SURFnet Rhys Smith, UKf: I think AAs will become more important as we move forward, and there is a gap here in policy that needs thinking about. Wolfgang Pempe, DFN |