...
| 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 |
| 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 |
| 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 |
You do not have to fill in every field, just give as much detail as you have right now if you know them.