...
| 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 |
eduGAIN "Disruptive"
| 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 | 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 | update SAML tracer |
|---|---|
| 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 Chrome and/or Safari compatible version? 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 |
| 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 | 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 auf of the list of SPs that are entitled to perform attribute queries and (possibly) recieve PII. |
...