...
| 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 SimpleSAMLphp |
| +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 | 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 | 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 |
| 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 | 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 |
...