...
| 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 |
| +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 |
...
| 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 |
| +1's | Scott Koranda for LIGO + 1 |
| -1's | SURFnet: Sounds like trying to solve a non technical problem (trust) using technology |
| 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 | eduGAIN Federated Service Catalog |
|---|---|
| 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. Niels van Dijk, 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? |
| Title | Storing History and Evolution of Metadata in a Distributed Ledger |
|---|---|
| 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 | 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 SimpleSAMLphpand 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. | +1's | Nick Roy, InCommon Constantin Sclifos, RENAM |
| 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 | 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's | SURFnet: Many worries: role of aduGAIN of aggregator that is now going to modify metadata (SURFnet) |
| 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 |
...
| 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) |
| 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/ |
...