...
Below is a summary of the comments and feedback to different areas of the draft.
----------
InC Forum: ~60 present; ~18 online
InC Track Session: ~40 present; 10 online
InC Town Hall Conference Call: ~28 all online
Emails to Comments Address: 1
Total: 157
----------
Risks/Potential Risks
Can we scale and solve our problems quickly enough and remain relevant, particularly if the federal government comes on in a large way?
Is there a specific document on threat assessments to success? The risks listed in the
Future report are global in nature and not specific. Are there specific things you are worried about (like Google, Microsoft)? Are there heavyweights that are, or need to be involved?
Document the risks more explicitly. Does an institution with federated identities create a more attractive target for hackers? While there has not been any evidence of such activity thus far, it would be interesting to see any think pieces or white papers on the topic.
The risks are not associated with the technology, but with minimizing use cases. If the discussion is confined to authentication, and not about the value in providing rich data, the risk factors go up. We should be oriented around the rich data and not around authentication.
...
Add layered services on top of InCommon. Bundle other services on top of InCommon.
----------
Training and Support
Identify needs for consulting services and consider offering those services, or coordinating with institutions that might offer such services (for example, help in setting up an identity management system).
...
If InCommon does not provide training, it could serve as a broker for finding such services. For example, what is that "network of commercial providers" that help in deploying Shibboleth IdPs and SPs?
----------
Identity Management
...
Provide consulting and/or production service for identity management systems. For campuses without the resources to invest in identity architectures, this could reduce the time necessary for federating. This could also serve as a bridge service until a campus has its own identity management program in place.
...
----------
Attributes
Provide a portfolio of attributes for relying parties, helping them see what they might need, what is appropriate, and what other IdPs and SPs are looking for.
----------
Cloud Computing
...
Many institutions are looking at the cloud for outsourced services (like mail and document sharing inside and outside of the institution). Is this a growth opportunity for InCommon? Rather than thinking about institutions and organizations, look at the services our members and potential members need and consider how to respond to those needs.
...
----------
Kuali
When Kuali starts to take off, will there be a need for interconnections?
----------
Higher education networking platform
...
Is there a need for a large social networking type of platform specific to higher education or a subset of higher ed (separate networks, for example, for IT people, library people, faculty, etc.)? Could InCommon play a role?
----------
SSL Certificates
InCommon could offer SSL certs at a fixed price and at considerable discount over what institutions now pay. This is not leading edge technology, but is associated with the structure of enterprise identity proofing. This may be a good opportunity, if InCommon can demonstrate organizational and economic efficiency in this area.
On the other hand . . . there was a comment that InCommon should be narrowly focused on metadata management, IdP features, IdP training and the like.
...
"Becoming a CA is a gigantic pain and, competitively, you'll lose over time."
----------
Second-Factor authentication
...
service
There is request from NSF to see if InCommon may be interested in offering a second-factor authentication service for higher ed. This would change InCommon's scope and may mean introducing additional profiles (like a "science faculty" profile, for example).
----------
Pricing
Central IT departments end up paying many fees, including InCommon, for all types of common goods. There should be some way to push these costs out to the edges. Grant and other funding applications could include funding to support such services that meet the needs of NIH and NSF.
...
In terms of fees, unless you can demonstrate you are saving some money someplace, it will be extraordinarily difficult to implement a higher fee structure. I would recommend honing in on a value statement that demonstrates how this use of technology can achieve demonstrable economic benefits.
----------
Comment from Email List
A personal principal of mine is to minimize risk by maximizing beneficial alignment and minimizing internal audaciousness, i.e. scope creep. A good alignment is the InC silver being exactly NIST loa 2. I do not understand the comments about the fed perspective in the webcast. Supposedly, InC silver was designed exactly to that alignment. Too bad Wasley wasn't apparently online with us to shed some light.
It is difficult to say what the best organizational model is other than opining that an increase in value added / adjacent services tends to increase potential liabilities. Organize accordingly.
One alignment (among many) that I would opine to be beneficial would be the SaaS community. If we would like to avail ourselves of their services, we should attempt to decrease the capex required for their participation. I'm thinking an Sp "kit" that would allow them to fast path the shibboleth integration. I realize that the more technical amongst us already believe it to be easy, but I have a data point with a major software/hardware/services company that is amongst the largest in the world, that would indicate, from their perspective, it is hard to integrate shibboleth into a product. A "kit" (more than currently there) or other perhaps even better idea, whether for corporate members and/or HE members would be quite useful. General public license t's and c's would inhibit any liability issues.
----------
InCommon Future Public Wiki
Thank you for sharing your proposed plans for the Future of InCommon and the presentations/discussion at the recent Internet2 member meeting. Below are some comments and questions that are derived from your presentation slides:
-Who is your primary audience ("the members") for InCommon? I noticed the use of the following terms, seemingly interchangeably, in the slide presentation:
R&E - used 11 times
the community (undefined) - used 4 times
higher education - used 3 times
university - used twice
higher education R&E community - 3 times, including title of slides 30 and 31
It would be my recommendation that you focus on institutions of higher education - prioritizing your member recruitments (e.g., starting with Internet2 staff, moving to the "organizational leaders", etc.) The research organizations (as distinct from a university), k-12, and others would be a secondary member audience.
As further evidence of how my recommendation coincides with at least one of your statements, in slide 8 you state: InCommon should position itself as THE provider for higher education
-the discussion about "risks" (slide 2) in the open forum leads me to conclude that this section might better be labeled "threats" or "external threats". Upon first read I thought it was referring to campus risks because of our attempts to get institutions to focus on risk assessments for improving information privacy and security. However, I see that the list identifies the kinds of ideas that would typically surface from an organizational SWOT analysis (strengths, weaknesses, opportunities, and THREATS).
-slide 2: "Substitutes for Internet Identity" - may want to replace "substitutes with "alternatives"; also, item #1 and discussion on slide 3 should also recognize the "government" (federal and state) as a potential driver for identity (i.e., Commercial developments and government policies)
-slide 5: although the 5th bullet recognizes the resource challenges, I think the current "economic downturn" (translated into significant budget challenges and prioritization of resources) needs to be called out as a threat to the future of InCommon
-slide 11: 5th bullet - collapse "registrars, financial aid officers" into a category called "student services"; add "alumni and advancement"
-slide 12: should there be a second bullet on "U.S. Inter-Federation" (e.g., with federal agencies, industry, etc.)?
-slide 18: "outreach" is a better term as used here than "evangelism" (which appears previously in document); perhaps "consortia" (2nd bullet) and "k-12 etal" (3rd bullet) would be better characterized as pilot projects.
-slide 19: Instead of "Leadership", an alternative title for this slide might be "Collaborations and Partnerships". Participation and recognition may be just as important as "leading" in this complex and rapidly changing space. May want to include ANSI as example of important standards body.
-slide 32: the organization of members by "service level" using the labels on this slide does not work for me. It will require considerable definition and explanation for people to understand the difference (e.g., "best practice" vs. "pragmatic"). Presumably these categories will also translate into different levels of fees. Therefore, I might suggest that you go ahead and introduce here a tier structure - e.g., Tier 1, Tier 2, Tier 3 - or some similar set of descriptive names that suggest service/fee levels (Full, Associate, Participating, etc.).
-slide 56: could any of these staff positions be shared with other organizations? E.g., 50% InCommon and 50% other (like a higher ed institution, Internet2, EDUCAUSE, etc.)
-slide 60 and 61: I think there is overlap in "business development" and "outreach". I would put the business development function as part of the outreach director's role and keep the business role to one of a business and finance manager.
----------
Comment from the wiki
slide 5 - Competition from some domestic identity providers is limited irt internationals in higher ed
slide 7 - Another significant challenge is creating an awareness of what federation is, its potential benefits and it relationship with IdM practices which are considered arbitrarily rigid by the average member of the community. Can InCommon assist by providing a basic set of awareness materials which could be used by members to communicate with their constituents?
slide 17 - Working with Microsoft to implement eduPerson, Shib w/AD or ensure that ADFS is compatible with Shib or both?
slide 18 - Developing the commercial capability is key. We are often pressured into alternative approaches when the vendor is not ready or willing to deploy Shibboleth. Writing language into a contract doesn't even seem to lead to the desired result without significant effort (Digital Measures, SciQuest). Training program for Microsoft VARs seems to be along the right track, for example (slide 20)
slide 20 - Quantify and publish potential cost savings and/or cost savings realized through cloud computing approaches or the sharing of core IT competencies among consortia members, as these arrangements leverage federated identity. In other words, promoting the value proposition could be a useful strategy, particularly in the current economic climate.
slide 29 - The concept of having InCommon run IdPs for R&E institutions seems fruitful. Perhaps there would be a model where you would have Universities which are regional providers authorized/approved to operate as such by InCommon. We have tossed this idea around with our medical college where the IT staff recognize the importance of running a Shibboleth IdP but can never free the resources to come up to speed and implement one.