...
| 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 Tom Barton: +1, and let's try to ensure that each contact is tested by only one testing activity, ie, perhaps the Geant activity should be formulated as a complement to other activities that are/will tests contacts in their federations/areas. Scott Koranda for LIGO +1 |
| 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.) Niels van Dijk, SURFnet: An independent registry outside of eduGAIN may carry a different trust level, and hence could be a resolution to challenges around mixing data with different trust levels. I therefor do not think this is the same thing as "Allow eduGAIN OT to enrich MDS metadata" below 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 |
| 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 | 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 should 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 |
| 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 |
...