...
| Title | Extension of supported values for eduPersonAffiliation |
|---|---|
| Description | The eduPerson spec currently only allows a limited number of values for the eduPersonAffiliation attribute. A number of our IdPs would like to use more fine-grained values, for example to distinguish researchers from teaching staff, pre-registered students from regular affiliates, emeriti from regular alumni, etc. The eduPerson editors specifically note that "any additional values should come out of discussions with the stakeholder communities". In this activity we would coordinate these discussions, make an inventory of which values are currently in use in the different federations, and determine if we can come to an agreement to extend the set of allowed values. |
| Proposer | Bas Zoetekouw (SURFnet) |
| Resource requirements | coordination and looooots of unicorns (preferably of rainbow-dancing kind) |
| +1's | Jan Oppolzer (CESNET), Lalla Mantovani (IDEM), Jean-François Guezou (RENATER) |
| Title | REFEDS Attribute Registry |
|---|---|
| Description | The REFEDS Attribute Registry is a registry of abstract "above-the-wire" user attributes. An abstract attribute is used to unambiguously specify attribute requirements in deployment profiles or in SAML metadata. For example, the precise attribute requirements of the Research & Scholarship Category are:
Note that the concept is similar to the notion of "scope" in OpenID Connect. |
| Proposer | Tom Scavo (InCommon) |
| Resource requirements | |
| Comments | Nick Roy: I'd note that there probably also needs to be an IANA-level OpenID Connect scopes registry. |
| +1's | Nick Roy (InCommon), Nate Klingenstein (InCommon) |
...
| Title | Interfederation security |
|---|---|
| Description | In many cases a national federation is considered as a trusted third party, who is responsible for registering and vetting entities. However, in an interfederation (like eduGAIN) there is no direct trust between the entities and the registrar. Beyond all the benefits and opportunities of such a worldwide collaboration, a couple of security questions and challenges may arise, for example:
|
| Proposer | Kristof Bajnok (NIIF) |
| Resource requirements | Lots of talking and writing... should it be a subgroup in REFEDs? |
| +1's | Tom Scavo (InCommon), Scott Koranda (LIGO), Nick Roy (InCommon), Niels van Dijk (on behalf of SURFnet), Jean-François Guezou (RENATER) |
| Title | Distributed scope verification |
|---|---|
| Description | A couple of eduPerson attributes (such as ePPN and ePSA) use scopes in attribute values to scope information to specific administrative domains. Moreover, in certain applications, scopes play a key role for authorization decisions and access control. Based on the proprietary shibmd:Scope metadata extension, Shibboleth and SimpleSAMLphp SPs are able to verify whether an entity is entitled to use a scope in attribute values or not. However, if a registrar fails to scrutinize the domain of the scope element, attackers managing to register a rogue IdP/AA entity might impersonate identities at SP software, which is one of the Worst Things. To mitigate this, it is possible to write a standard for using DNS TXT records to declare which entityIDs are entitled to a domain name in scope. Based on DNS, an SP can verify scope information more securely and without relying on the trust of the registrars. It is very much similar to the Sender Policy Framework with email. |
| Proposer | Kristof Bajnok (NIIF) |
| Resource requirements | Write RFC. Write proof-of-concept SP addons. |
| +1's | Tom Scavo (InCommon), Nick Roy (InCommon), Nate Klingenstein (InCommon) |
...