(Working document of this work plan in Google Doc)

2022 Work Plan Items

SIRTFI Exercise WG

Summary

Participating in planning and executing the SIRTFI exercise. 

Actions / Expected Outcome

• Sending out notifications to Security contacts; examine results / failures (~May?)
• Summarize lessons learned from first exercise(s)

♦ ♦ ♦ ♦ ♦

Future of Federation Policy Making to improve trust and interoperability

Summary

Review lessons learned from BE to date; investigate emerging trends/needs; propose how BE should evolve next, both in content and in format. Specifically consider lessons learned: ways to increase assurance and interoperability as ‘opt in’ or aspirational specification. 

Potentially describe scenarios, profiles, standards, or recipes for enhancing IdP and/or SP to meet needs of, say, an R1 or a community college, presumably including implementation of MFA signaling or attribute bundling for R1, not CC.

Actions / Expected Outcome

• Take a step back to look at BE program and assess; what alternatives to “everyone is required to…” might also increase interoperability and assurance?
• Report on results of BE2 - how many entities failed to meet BE2, how long did various adoption points take, why did some entities fail?
• Develop vision/goals for assurance and interoperability BE and other possible models?

Notes

• We want to scope this to deliverable outcomes, preferably around how policies and policy making can improve trust and interoperability in current federation model
• This may include policies that don't apply to all members, but do apply to members of a certain sort or those who engage in some activities.  (eg, you don't have to do MFA, but if you do, you must support proper signaling)
• Future federation model is longer range, less constrained by InC and out of scope for this work; should be pursued separately and widely
• Set concrete timebox for work group duration (less than 1 year) - deliver outcome in time to ready to present at 2022 CAMP
• Eg: if you are communicating something defined in eduPerson, you must use eduPerson attributes.  (Eg, scoped username will be in ePPN.)
• WG desperately needs participation from SPs and Research proxy services

♦ ♦ ♦ ♦ ♦

Review REFEDS Entity Categories 

Review new/updated REFEDS entity categories (anonymous, pseudonymous, personalized (onymous) + R&S 2.0); and the report on MFA profile. Recommend course of action for InCommon (eg recommend, adopt, require, reject, etc)

(How does all this relate to current R&S? How do we navigate change?)

Actions / Expected Outcome

• Inventory of Entity Categories and their state to understand what we want to look at or how to participate (eg, we would not want to take up a review of something about to be superseded, but may want to decide to participate in the consultation.)
• Analyze and Describe value of the new EC’s to InC participants
• Eg, helping IdPs understand that they should support understanding that some SPs don't want PII about users, or SPs that they can operate securely without.
• Describe scenarios for use that increase interoperability, and provide specific “how to implement” documentation.
• Provide recommendations on adoption entity categories within InC 
• e.g., could we convince all IDPs to adopt/support at least the anonymous EC?
• Guidance for InCommon Federation Operator
• Guidance for the community on how to use or when to use?
• Scope to Profiles / specs already published or will certainly publish before Summer.
• Personalized - https://refeds.org/category/personalized
• Anonymous - https://refeds.org/category/anonymous
• Pseudonymous

Considerations:

• Attribute bundles without explicit assertion of an EC? How might that scale?

♦ ♦ ♦ ♦ ♦

Settle how we’ll handle TLS security

InCommon’s process for doing SSL Labs tests on all entities has a number of constraints and caveats. That and other factors have led CTAB to be ambiguous about how we think about the BE2 end-point security requirement. Let’s nail this down.

Given we are relying on SSL Labs scoring, and we have a preference for a minimally acceptable grade, what do we need to improve/change to make sure we can sustain the tracking and dispute resolution responsibly?

Actions / Expected Outcome

• Process guidance on how we will react to changes in grading and what is CTAB’s role?
• Ongoing process for keeping up to date and keeping entities up to date and managing disputes.
• BE FAQ updated
• How does this requirement maintain trust between federation participants?  (Map TLS security or lack-thereof to federation trust)

Considerations

• Is CTAB ready for the potential volume of work generated by this?
• We do not want to re-litigate the scoring decisions or the decision to use SSL Labs.
• We do not want to get in to making our own standard.

Deliverables

• Draft proposal: https://docs.google.com/document/d/1Q_pOmMJisomQOav19u1hLXAhG3O0GdcehL7rPlyNc7o/edit#heading=h.nx4tlyz4lnnw 

♦ ♦ ♦ ♦ ♦

Decide how to monitor on-going compliance with BE to help participants maintain adherence

Prioritizing work and recommendations for InCommon to create an infrastructure or process to monitor ongoing compliance, working with InCommon Staff to roll it out to the Federation.  Baseline is not something that happens on a cycle, it's an ongoing process.

Actions / Expected Outcome

• What feasible / scalable techniques for measuring or gauging participants’ compliance;
  Are SPs expecting some enforcement or measure of compliance with BE and Security?
• And what frequencies?  How to communicate these in a non-confusing way (eg, not a series of emails every day, etc)
• What will the process be to evaluate and establish new techniques?
• Recommendations to TAC/Steering to evaluate.
• Understand realistic capabilities for monitoring and extent to which those would facilitate increased trust and assurance.
• Frame and context for communications about compliance items to InC participants.

Considerations

• CTAB cannot spec work for I2/InC staff, need to work with TAC and Steering
• Need to consider the items other than TLS, eg:
• Logo URLs pointing to inappropriate formats (.pdf,...)
• Contact email addresses

♦ ♦ ♦ ♦ ♦

Items CTAB to track in 2022

These items are community and industry work-in-progress. CTAB does not lead these efforts. However, because they are of significant value to CTAB, CTAB makes a conscious effort to stay current with these activities:

• REFEDS Assurance WG  - Development of REFEDS Assurance Framework 2.0
• MFA sub-group of REFEDS Assurance WG - Development of next REFEDS MFA Profile revision

Deferred Items

Additional items were considered, but not included in the 2022 CTAB Work Plan. A list of these deferred items is here: Deferred Items from 2022 CTAB Work Plan