To propose a new idea, copy and paste the table below. Ideas don't need to be fully formed but the more scope we can get the easier it will be to assess whether idea should be taken forward.
Anything in the Trust and Identity space is of interest, from improvements to current services to brand new ideas and technologies.
If your idea already exists in the suggestions, you can just add a +1 for endorsement.
Template
| Title | <title of your proposal here> |
|---|---|
| Description | <description text here> |
| Proposer | <your name here> |
| Resource requirements | <money? effort? coordination? infrastructure?> |
| +1's | <for others to voice their support - add your name here> |
Proposals
| 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 |
| 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 |
| 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.) |
| 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 |
| 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 |
| 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. |
| 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. |
| 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. |
| 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 |
You do not have to fill in every field, just give as much detail as you have right now if you know them.