Minutes from Quilt / InCommon Pilot Tech Call
2:00 PM Eastern Time Friday March 8, 2013
Notes taken by Steve Thorpe, thorpe@mcnc.org

Reminder on Group Logistics:
Email list is inc-quilt-pilottech@incommon.org
Box folder is https://www.box.com/files/0/f/680471824/InC-Quilt_Pilot_Tech
Standing meeting is Fridays at 2:00 PM Eastern
Dial-in numbers for our standing meeting are: +1-734-615-7474 (English I2, Please use if you do not pay for Long Distance), +1-866-411-0013 (English I2, toll free US/Canada Only) Access code: 0110688#
Attendees:
Bernie A'cs, NCSA
Paul Caskey, University of Texas System
Chris Giordano, MOREnet
Keith Hazelton, University of Wisconsin-Madison
Steve Olshansky, Internet2
Tom Scavo, InCommon/Internet2
Mark Scheible, MCNC (chair)
Steve Thorpe, MCNC


Action Items:
[AI] MarkS: Put PowerPoint slides into Box folder after the call.
[AI] MarkS: Will start a questions document in the Box folder, with the questions captured here. And people can add to it (along with administrative questions)
[AI] SteveT: Publish these minutes around to the various lists / box folder.
[AI] TomS: Will try to find a previous diagram and set of steps for how the Proxy IdP works.
Discussion:
1.  Agenda Bash

2.  Updates from Pilot Definition and Admin WGs (Anyone) (also from published notes in Box)
There's been some concern about inter-group awareness. Feel free to check the other group minutes to learn more about what others are doing.
Technical and Admin WG's were going to inform the Pilot group about the requirements definitions before sending out a CFP. However it seems many of the regionals already have pilots in mind, so probably makes more sense to start with those in mind – how would those pilots fit the models we're talking about? So that's what we're moving to now – more of a directed pilot. We have somewhere around 10-12 potential pilots with interest from one or more regionals.
This group needs to come up with a set of questions to ask the proposers, around the technical needs / requirements for their project. Those would be assembled by the pilot definition group, along with feedback from the admin group, to prepare for the initial / starter pilots. Deliverable from this call is to at least start a list of questions.
The main point is we want to talk with the regionals / gather their interests, to help inform negotiated pilots rather than a traditional CFP type of thing.
To keep groups informed of each other's activities, we'll have each group send minutes to all three groups. Also everyone is welcome to attend any of the three groups' calls.

3.  Chicken and Egg dilemma (Pilots or Requirements?)
What is it we need to provide the regionals that are interested in this? Problem is, without having something out there for the regionals to grab onto, it might be more difficult. In some cases the regionals have a problem but aren't sure how technically to do it. That is the chicken and egg thing. Something needs to be out there for potential pilot proposers to look at, to help define the pilot. So along those lines….

4.  Review of latest version of Regional Federation Models document (Box)
MarkS created this PDF slide deck: https://internet2.box.com/s/g2vqkmv5mu5b5nokynme (Note Mark will add the PowerPoint to the box folder after the call)
Key idea in this slide deck is the three federation scenarios:

  1. Delegated administrative support. Normal, Mesh model with regional helping smaller orgs with running an IdP. Any member here is a standard InCommon member.


  1. Sub-Federation. Here you have an extract of entities in a separate Metadata file, although still built from InCommon. InCommon would provide "Sub-Fed MD Aggregates". Some of these entities are in the regular InC metadata, some not.


  1. Inter-Federation. There are existing state systems with their own federation. Perhaps some of those are also in InCommon, but their own federation is a standalone one. To configure this involves either the use of MD exports and/or the use of a Proxy IdP. In which case the Proxy IdP would be in the InCommon metadata.


There's a spreadsheet included with the slide deck that describes these options.
Bernie: In 2) Sub-Federation model, this is really the first model where we discuss the proxies which seem critical for K12. Is the Sub-Federation itself seen also as an Identity Aggregator, so there could be many IdPs inside of it.
Paul: I believe individual Identities are not being aggregated, but rather IdPs. Hence Identity Aggregator is probably not the best term.
SteveO: We need to watch our wording as we socialize these descriptions.
Question: Who would use which model?
Mark: I think we want to have some flexibility here, so not all would need to stand up a proxy IdP.
Bernie: This sub-federation model with using proxies is very likely the direction we'll be going here as well.
Keith: IT could be a low-hanging fruit to do the proxy method, from InCommon's perspective it should be pretty easy to accommodate.
Bernie: In this particular model what would be the liabilities for MD exchange between the sub-federations and InCommon?
Tom Scavo: As I understand it, the proxy IdP would be the only entity InC would have to worry about. It would be the proxy IdP that would need to negotiate relationships with other SPs in InCommon. So it would be simply the same model. Would just be adding in another entity to InCommon.
Bernie: There are some large districts that might not fit into that model, but the bulk of constituents probably would.
Paul: With that model, (channeling John K. here) you'd have to make sure the proxy gets the same vetting that InCommon normally does.
Mark: On the Inter-Federation model, there are some existing federations that might want to pilot inter-federation, with a regional's assistance. If it's a state system they may wish to do their own Inter-Federation pilot. E.g. UNC Federation is in that situation.
Keith: So on the Inter-Federation with the Proxy-IdP, how is that different from the Sub-Federation with the Proxy-IdP?
Mark: Not sure, but I know REFEDs is doing something like that. So I put It in there.
Chris: I can say a little about MOREnet's motivation for the Inter-Federation model. We've gone through this path during the last year of setting up our own federation. We wanted all of our members to access EPSCO, and we wanted to wean ourselves of IP address restrictions. We know that EPSCO supported Shibboleth logins. So knowing they are in InCommon, the hurdle for us was the fees for K12. So given that we're willing to absorb the cost of running an IdP on their behalf, it seems the Proxy IdP's value (whether or not InCommon membership is needed) – cost is a big factor. Proxy model means cost might be affordable. Actually a proxy IdP may simply be enough for us – stand up a single IdP for our member K-12's.
MOREnet is not committed to anything at this point, but I wanted to share the motivation for how we got to where we are today.
Paul: I would hope coming out of this, out of the Administration group … if you're going to run an IdP proxy, here is the policy you need to follow. Once you get beyond that, you've passed all the InCommon joining fees / overhead.
Mark: I think John K. / InCommon is aware of that. They want to work with us to figure out a workable solution. Of course the other side of that – you get the reduced cost – but how to define what the membership status of those Federation entities are?
Tom: If K-12s are issuing the credentials, it may play into the InCommon policies somehow.
Mark: With a vendor's SP, there is still some sort of agreement being written up. The technical part is easy, the rest of it is the policy piece / contract pieces. A lot of the concerns can be covered in that agreement.
SteveO: If we can offload some of the InCommon responsibilities to the regional, that would make a strong justification for reducing cost right out of the gate – if we could shift some of that burden. We also don't want to overburden InCommon.
Mark: I don't think we need to be overly concerned to stick to only technical here, but if we think of administrative questions to pass along to the administrative / policy group, that is also fine.
Bernie: Would it be helpful to outline one of our OWN cases, and share it out with the group?
Mark: That's been discussed but more as a later step. I do think it is valid but perhaps as a second part of the process.
Keith: There is some work getting underway in InCommon about MD filtering / aggregating / etc. If you are interested in that topic, just let me or Tom Scavo know and we'll involve you.
Ideas for technical questions to help define a pilot proposal:
These are the questions that might be asked up front, to help better define the project.

  1. What are you offering? What technical resources can the regional/state system provide? What kind of skin in the game do they have? E.g. servers or whatever else.
  2. What are your needs? What technical resources do they lack, that they'd require from InCommon or an InCommon affiliate?
  3. Community contribution / Strategic Importance: To what extent can the pilot your proposing be leveraged by other regionals?
  4. Alignment. How well does you proposal map onto the models we're suggesting?


Mark: Would like to get together a written up version of how the Proxy IdP would work. Something where you show a user with the browser and how they'd work through it. Is there somebody who could just list the steps for how the Proxy IdP would work? And I'd be happy to make a diagram that follows the steps. Will take this offline, but if anyone thinks of a contact who could provide the bullets – please contact Mark Scheible. Paul is happy to review and help.

5.  Next Steps
MarkS: Put PowerPoint slides into Box folder after the call.
MarkS: Will start a questions document in the Box folder, with the questions captured here. And people can add to it (along with administrative questions)
SteveT: Publish the minutes around to the various lists / box folder.
TomS: Will try to find a previous diagram and set of steps for how the Proxy IdP works.

6.  Action Item Review
Next Meeting: March 15th, 2:00 PM EDT

  • No labels