Please use this page to record ideas that you would like to include in the 2018 REFEDS workplan. 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. We look forward to all your ideas!
Want to know what was proposed in 2017 Have a look here.
Template
| Title | <title of your proposal here> |
|---|---|
| Description | <description text here> |
| Proposer | <your name here> |
| Resource requirements | <money? effort? coordination? unicorns?> |
| +1's | <for others to voice their support - add your name here> |
Ideas
| Title | One last attempt at harmonizing identifier use |
|---|---|
| Description | The existing identifier complexity is maddening. Possibly push for adoption of the Subject-ID spec everywhere an identifier is needed, to reduce complexity for all involved going forward. Replaces eduPersonTargetedID, SAML 2.0 persistent NameID, eduPersonUniqueID and (partially) eduPersonPrincipalName. Might help align with private/public identifiers in OIDC.
Content-wise this could say something: For SPs, signal/use subject-id if you require a shared/public identifier, if not available also accept ePUID (if not available also accept ePPN?). Signal/Use pairwise-id if you don't require correlation between multiple SPs, if not available also accept persistent NameIDs (in the Assertion's Subject), if not available also accept eduPersonTargetedId. For IDPs, have them all available, but release in the given precedence if multiple ones are signalled by the SP. I.e., provide strong guidance on what to use when (achieve consistency, lessen complexity mid-term), but help with interop today (and possibly improve privacy and data protection compliance) by giving precendece lists for alternative attributes. |
| Proposer | peter@aco.net |
| Resource requirements | Lots of shepherding, discussions with R&S and CoCo deployers, eduGAIN Steering, etc. |
| +1's | |
| General Comments | NH: REFEDS Attribute Registry was never a real "thing" but a proposal as part of the 2016 workplan that did not get enough support to move forward. Generally I would action this area to the Entity Category WG unless there is a desire to do something separate. SURFnet: 1) Spec in itself addresses a need 2) Harmonisation as such is not the goal, so what are the real differentiating benefits for eduGAIN? 3) If we want this implemented is < 5 years, we have to make some hard choices in respect to deprecating current identifiers. |
| Title | OIDCre federation policies |
|---|---|
| Description | OIDCre federations are moving into pilot phases and discussions on how to run hybrid SAML/OIDC federations are happening now. Rather than having to go back and try and normalize the policies for OIDCre federations, let's take a look at what we think the policy space should look like and create the necessary templates. |
| Proposer | TIIME 2018, roland@sunet.se |
| Resource requirements | ? |
| +1's | |
| General Comments | NH: would suggest policy writing might sit better under eduGAIN task in GN4, although policy work has happened here before. SURFnet: suggest gap analysis with current SAML federation policies: how much difference is there? |
| Title | Federation 2.0 |
|---|---|
| Description | With OIDC federation and MDQ/per-entity upcoming, it's time to look deeply into how to operate R&E Federations in a hybrid SAML/OIDC manner. What are the Sources of Authority and what actors/orgs should assume which roles and perform which tasks to support this global trust infrastructure. Federations have been in existence now for 15-ish years. Let's step back and take a look at whether the current model is the right model for going forward. How should R&E federations evolve? Highly related to the OIDCre Federation Policies topic. (Discovery 2.0 from 2017 Work Items is also a piece of this - MS) |
| Proposer | Tom Barton |
| Resource requirements | ? |
| +1's |
| Title | Evolution of SIRTFI |
|---|---|
| Description | The working group likely needs to focus on adoption of the existing SIRTFI. This work proposes to discuss how to evolve SIRTFI to include more MUSTS and otherwise react to an ever-changing security landscape. |
| Proposer | TIIME 2018 |
| Resource requirements | ? |
| +1's | |
| General Comments | NH: radical idea - make Sirtfi a MUST for eduGAIN based on GDPR requirements? SURFnet: Good idea, but we suspect SIRTFI will need some form of profiles, to allow for differentiating for different usecases. |
| Title | Post-mortem for entity categories |
|---|---|
| Description | Entity categories haven't quite solved the attribute release problem as we had hoped. This group would look at what went well, particularly with R&S, what went wrong, and consider what should happen next in this space. |
| Proposer | TIIME 2018 |
| Resource requirements | ? |
| +1's | |
| General comment | SURFnet: We strongly support this activity, but suggest a clear distinction between REFEDS and eduGAIN. |
| Title | Authorization and federations |
|---|---|
| Description | Standardizing authorization information, including outreach and education on protocols like SCIM. Should this be part of a federation's responsibilities, and if so, how? |
| Proposer | TIIME 2018 |
| Resource requirements | ? |
| +1's |
| Title | REEP |
|---|---|
| Description | REEP is still proving quite useful to some organizations. This should be a quick set of work to make sure the service has what it needs to continue to run for the foreseeable future. |
| Proposer | TIIME 2018 |
| Resource requirements | ? |
| +1's | scott.koranda@ligo.org |
| Title | VO friendly eduGAIN |
|---|---|
| Description | REFEDS may have a role in providing broader community input into eduGAIN policies and services. eduGAIN needs more education and explanation of what's possible within federations that are a part of eduGAIN - simply saying "they are a member" does not mean that all federations integrate with eduGAIN in the same manner. There may be some integration between this and the service catalog work, as that kind of information on what's possible may involve more detailed metadata information in the eduGAIN feed. |
| Proposer | TIIME 2018 |
| Resource requirements | ? |
| +1's | |
| General Comments | NH: This is a known and desired part of the eduGAIN workplan. Issue is manpower bottleneck. Is there anyone in GN4 that could take the lead on this? SURFnet: What would be the concrete role of REFEDS for this activity? SK @SURFnet: Develop documentation that explains that a country being colored in blue on the eduGAIN map does not mean that an SP can expect all users at all educational institutions in that country to suddenly have federated access to the SP. In that same documentation provide a comprehensive explanation of what it really means for an SP to try and leverage eduGAIN. In short, manage expectations of SP operators. |
| Title | The .int federation for non-legal entities |
|---|---|
| Description | The upcoming FIM4R paper talks about a boundary-less international federation suitable for research and scholarship organizations that are not legal entities. This group would talk about how to make that happen. |
| Proposer | TIIME 2018 |
| Resource requirements | ? |
| +1's | |
| General Comments | PS: I think that's trying to solve the problem by proliferating/creating another: EU IDPs won't be able to legally release attributes to non-legal entities, IMO (GDPR hint: Both Controller and processor are legal entities. Joint controllership means shared legal duties. etc. My guess is the EU won't accept accountabiltiy/responsibility for recieved data vanishing completely, doubly so for SPs outside EU/EEA.) Work on fixing the "lack of legal entity" problem more literally would then take care of federating and possible/additional/future attribute release obstacles (once people really start looking at federation and GDPR). |
| Title | GDPR Guidance |
|---|---|
| Description | We'll at least need to update the Guidance on justification for attribute release for RandS for GDPR. That may turn out to be more than simple wordsmithing, e.g. the issue of leg-int and (repeated) transfers outside EEA, information duties, etc.pp. Coordinating how federations deal with GDPR may also be a worthy effort. (So far my attempts at bridging over to TF-DPR failed miserably, I couldn't even get a reponse from that Task Force's secertary nor their chair wrt the simple question which of their mailing lists I should send federation+GDPR questions to.) |
| Proposer | peter@aco.net |
| Resource requirements | ? |
| +1's | SURFnet |
| General Comments | I've updated the R&S advice at:Guidance on justification for attribute release for RandS to cover GDPR as much as we can at this stage. Proposal to add - defining a clear process to be used by all federations when applying R&S to SPs. SURFnet: we suggest specific guidance for common scenario's like "IdP in EU, SP in USA", "VO with IdPs in EU and USA", "IdP in USA, SP in EU". |
| Title | Is there life on PEER / REEP? |
|---|---|
| Description | Just as we were about to let PEER / REEP go gentle in to that good night, new use cases emerged! Can we update the software and / or service to meet the new requirements or should we support those needs in a different way? See: Evaluation of REEP. |
| Proposer | From lots of people |
| Resource requirements | Contract to update the PEER software. Proper resilient resourcing for REEP service if hosted at REFEDS. Possibly elsewhere? Policy update for REEP. |
| +1's | scott.koranda@sphericalcowgroup.com SURFnet |
| General Comment | Please find a friendly entity to run this service. (GEANT ?) |
| Title | Service Catalogue |
|---|---|
| Description | Do whatever Heather recommends out of the Service Catalogue work carry over from 2017. |
| Proposer | Nicole Harris |
| Resource requirements | <money? effort? coordination? unicorns?> |
| +1's | <for others to voice their support - add your name here> |
| Title | R&S next steps |
|---|---|
| Description | R&S 2.0 R&S benefits doc (should be done real soon now - this is just a reminder) R&S certification conversation R&S GDPR advice. |
| Proposer | <your name here> |
| Resource requirements | <money? effort? coordination? unicorns?> |
| +1's | scott.koranda@ligo.org |
| General Comment | SURFnet: do post-mortem first, in order to take concrete steps for this activity. |