InCommon Technical Advisory Committee Meeting - July 24, 2014

Attending: Steve Olshansky, Steve Carmody, Ian Young, Scott Cantor, Jim Jokl, Michael Gettes, Keith Hazelton, Jim Basney, Paul Caskey
With: Steve Zoppi, Tom Scavo, John Krienke, IJ Kim, Ann West

Action Items

AI: Keith et al. will rev the charter for the IdP of Last Resort WG (or whatever the title turns out to be) and send a note to mailing list.
AI: Steve will rev the charter for the Use Cases - New Entities WG (or whatever the title turns out to be) and send a note to mailing list.
AI: Ann will keep TAC in the loop with respect to the Steering group working on eduGAIN policy issues.
AI: InCommon staff will go back to the drawing board and discuss possible paths forward with respect to REFEDS R&S and eduGAIN.

eduGAIN and Steering

• Ann reports Steering ERG will convene a group to grapple with interfederation issues (eduGAIN, in particular).
• John has complete a gap analysis and submitted a number of seed documents to Steering, including a legal opinion regarding suggested content changes to Federation documents.
• The group will review the eduGAIN documents and study the gap analysis. Note: the last Interfederation WG reviewed the eduGAIN documents and submitted a written summary as a deliverable.
• The proposed changes will be subjected to a community review to make sure the changes are reasonable from a campus perspective.
• Ann is looking for a TAC member to represent TAC on this Steering group. It would be good if that person was previously on the Interfederation WG.
• The Center for Trustworthy Scientific Cyberinfrastructure (CTSC) has been invited to participate in this effort as a stakeholder.
• Q: Will the Steering group be a public-facing group, that is, will the agenda and minutes be published and will the mailing list be an open subscription mailing list? A: Yes.

UnitedID as an IdP of Last Resort WG

• Keith Hazelton (along with Jim Basney and Steve Olshansky) drafted a charter for this WG. The goal is to assess the feasibility of UnitedID as an IdPoLR in the InCommon Federation.
• The charter is very much a first draft so feedback and input is very much welcome at this point.
• A basic assumption is that ProtectNetwork no longer meets the needs of the Federation. [This begs the questions: Why?]
• The primary deliverable is to document the requirements for any IdPoLR and then to determine if UnitedID meets the requirements. Provide a detailed gap analysis if necessary.
• Describe the sustainability requirements of any IdPoLR (and UnitedID, in particular). Note that today UnitedID is funded purely on the basis of donations.
• Another deliverable is to explore the tradeoffs between a traditional IdPoLR (like ProtectNetwork or UnitedID) and a social-to-SAML gateway. If there are other approaches to IdPoLR, include them in the analysis as well.
• If UnitedID satisfies the general requirements for an IdPoLR, the WG will outline the tasks and technical considerations needed to move this forward.
• Q: Is this WG specifically focused on UnitedID or is it meant to address the IdPoLR question more generally?
• Q: Do we even have the right folks on board to answer questions about UnitedID?
• Consensus: The concept of IdPoLR is not new and it’s doubtful a WG will be able to bring anything new to bear on that issue over the span of three months. If that’s true, then the WG really is about UnitedID as an IdPoLR in the InCommon Federation.
• Recent news regarding ProtectNetwork prices increases is driving this interest in a supported IdPoLR.
• Q: What’s special about UnitedID compared to any other prospective IdPoLR?
  UnitedID vs a sustainable IdPoLR for InCommon participants are probably two separate (and orthogonal?) goals.
• Q: Why hasn’t UnitedID joined InCommon already? What are the barriers?
• A gateway can become a persistent presence in the Federation. The IdPs behind the gateway can come and go, but the gateway itself is run by and for InCommon.
• Suggestion: Take the word “UnitedID” out of the charter title and continue this great conversation in the WG itself. The fact that we’re having this in depth conversation indicates the need for a WG (but perhaps not the one that was originally intended).
• Observation: This WG is starting to overlap with the Alternative IdP WG.
• AI: Keith et al. will rev the charter for the IdP of Last Resort WG (or whatever the title turns out to be) and send a note to mailing list.

Use Cases - New Entities WG

• Steve reports that last time we discussed the possible formation of a “Metadata Annotation WG.” Feedback on the last call prompted Steve to refactor the charter and change the name of the WG to “Use Cases - New Entities.” The latter has a very different focus from the one that was discussed last time.
• We discussed the notion of 3rd parties being represented in metadata. We have that today in the form of Sponsored Partners who publish endpoints rooted in the domains of their customers.
• The primary concern seems to be: systems being operated by parties not subject to the terms of the Participation Agreement. Entities to be imported from eduGAIN are a prime example. Another example is a regional registering K-12 entities.
• Does this WG overlap with the efforts of the assurance program?
• Should the title of this WG be something like “Third-Party Relationships?” That seems to capture the interests of this WG.
• The topic of self-asserted tags in metadata came up again. Q: Can a participant annotate another participant’s metadata without the consent of the latter?
• AI: Steve will rev the charter for the Use Cases - New Entities WG (or whatever the title turns out to be) and send a note to mailing list.

REFEDS R&S Migration

• After much good conversation on the mailing list, the consensus seems to be that the REFEDS R&S Migration is best considered in the context of the larger set of interfederation issues.
• The most pressing issue revolves around the mini-aggregate containing three LIGO R&S SPs. Recall that those SPs have been intentionally annotated with the REFEDS R&S entity attribute value, so the question is what must be done before that mini-aggregate can be exported to eduGAIN?
• The work that’s being done to align the InCommon R&S spec with the REFEDS R&S spec should continue. Where the two specs do not align, identify the gaps and discuss with the community.
• One suggestion is to tweak the InCommon R&S spec in advance of the REFEDS R&S spec. The counter suggestion is to leave the InCommon R&S spec alone until we’re ready to discuss the similarities and differences (i.e., the gap analysis) with the community.
• Q: Who owns this effort?
• AI: Ann will keep TAC in the loop with respect to the Steering group working on eduGAIN policy issues.
• AI: InCommon staff will go back to the drawing board and discuss possible paths forward with respect to REFEDS R&S and eduGAIN.