Child pages
  • 2018 Work Plan Preparation
Skip to end of metadata
Go to start of metadata

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

TitleOne 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.

  • Consider creating R&S 2.0 as a result, replacing ePPN or ePPN+ePTID as standard identifier(s).
  • CoCo v2 also has a section on attributes (use of "least privacy-invasive" attribute when alternatives exist) and I think that section could use more concrete and more complete guidance (which in turn would make Art.29WP/Art.68WP happier).
  • We could also make this into a Best Practices piece for eduGAIN, to replace the deprecated/old Attribute Profile. Has the least prescriptive power but the widest audience.
  • What ever happened to REFEDS Attribute Registry? Since Subject-ID uses different signalling (yet again: RequestedAttribute, NameIDFormat and now EntityAttribute) is the meta-attribute approach relevant (again)?

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 requirementsLots of shepherding, discussions with R&S and CoCo deployers, eduGAIN Steering, etc.
+1's

Nick Roy, InCommon

Judith Bush, OCLC

Thomas Lenggenhager, SWITCH

SURFnet (also see comment)

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.

TitleOIDCre federation policies
DescriptionOIDCre 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?


TitleFederation 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


TitleEvolution of SIRTFI
DescriptionThe 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.


TitlePost-mortem for entity categories
DescriptionEntity 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 commentSURFnet: We strongly support this activity, but suggest a clear distinction between REFEDS and eduGAIN.


TitleAuthorization and federations
DescriptionStandardizing authorization information, including outreach and education on protocols like SCIM. Should this be part of a federation's responsibilities, and if so, how?
ProposerTIIME 2018
Resource requirements?
+1's


TitleREEP
DescriptionREEP 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'sscott.koranda@ligo.org


TitleVO friendly eduGAIN
DescriptionREFEDS 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.
ProposerTIIME 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.

TitleThe .int federation for non-legal entities
DescriptionThe 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).

TitleGDPR Guidance
DescriptionWe'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.)
Proposerpeter@aco.net
Resource requirements?
+1'sSURFnet
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".

TitleIs there life on PEER / REEP?
DescriptionJust 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.
ProposerFrom lots of people
Resource requirementsContract 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 CommentPlease find a friendly entity to run this service. (GEANT ?)
TitleService Catalogue
DescriptionDo whatever Heather recommends out of the Service Catalogue work carry over from 2017. 
ProposerNicole Harris
Resource requirements<money? effort? coordination? unicorns?>
+1's
TitleR&S next steps
DescriptionR&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'sscott.koranda@ligo.org
General CommentSURFnet: do post-mortem first, in order to take concrete steps for this activity.
  • No labels