IdP as a Service Working Group

[Todd Blakemore <>]

I'm double booked with an all campus meeting which I need to attend, If I'm able to duck out of this other meeting early I'll do my best to join. From brief glance through the document and what you have in this email I believe it captures the pieces that are important. 

Best of luck with your recovery. 

- Todd Blakemore
Associate Director for Solutions Architecture

Information Technology (IT)
 
Ithaca College
953 Danby Road | Ithaca, NY  14850
607.274.3414

http://www.ithaca.edu/it/

---

From: <> on behalf of Mary McKee <>
Sent: Saturday, July 18, 2020 5:26 PM
To: <>
Subject: IdPaaS working group call Monday 1pm ET

 

This message originated from outside the Ithaca College email system.

Hi all,

I'm writing with some personal and logistical news:

My chemotherapy is winding down and I am going to be taking some leave starting in October to recover from surgery.  Talking with E.J. and Albert about where we are with the working group, I believe we can easily wrap up our deliverables before then.  We were not able to find a better time for everyone to meet, so we'll be sticking with Mondays with E.J. filling in this week while I'm at treatment.

The proposed agenda for this week is to get feedback on a summary of what we've heard from the group, which will be the basis for the final report.  Since I won't be able to make Monday's meeting, I thought I would share what I see as those major conclusions:

• IdPaaS products should not be graded by "level" (basic, plus) but rather by model (federation adapter, full SSO, etc) as outlined in the draft report.
  
  
• InCommon should consider developing a program to define what a "federation-ready" IdPaaS provider looks like within each of these models:
  
  

• Helping vendors meet this distinction and better connect with potential customers and the community in a broader sense,
  
  
• Helping institutions identify which model of IdPaaS product best meets their goals, connecting them to federation-ready providers in that space, and providing guidance on features to consider when selecting a product based on lessons learned from the community (and this working group).
  
  

InCommon should limit its assessment of providers to what constitutes federation readiness ("must meet" criteria) and offer guidance to institutions about features to consider as differentiators between federation-ready solutions.  To keep the scope reasonable and appropriate, "should meet" criteria should be framed as future "must meet" standards from a federation standpoint, allowing institutions to make their own value judgments about the relative value of features outside the realm of federation.

Please come to Monday's meetings with thoughts on where we may need to tweak the above, and any other high-level thoughts about the format of the final report draft (what are we missing?  what should we have discussed, but haven't?).  If we don't need to make any major course adjustments, we'll plan to spend our remaining meeting time going through the documents section by section until we feel ready to present to InCommon.

Thank you all for being a part of this group.  We appreciate you!
Mary