Comments for the InCommon Future group
- InCommon Forum (April 27, 2009)
- Town Hall (May 4, 2009)
The 2009 InCommon Forum consisted of a review of the first draft of the InCommon Future group, which is charged with developing a three-year strategic plan for the federation. There was considerable feedback and the session was offered online via a phone bridge and Adobe Connect to InCommon participants.
There was also a Town Hall on the same topic, done via the phone and online, on May 4.
Below is a summary of the comments and feedback to different areas of the draft.
This document is also available for download (in Word format)
----------
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.
We need to ensure that the parent organization for InCommon can provide the resources that are necessary to ensure success in this time of rapid growth.
Institutions have come to rely on InCommon. If external events, or other factors, cause this not to take off, is there a fall-back scenario to serve current members?
What if the federal government mandates Open ID?
Can InCommon survive outside of Internet2?
If their fees increase substantially, will vendors stay in the federation?
What are the specific risk factors identified for InCommon? What are you worried about that we had better get figured out? Two areas include not taking too long to get Silver underway and having the right governance in place. Moving too slowly on these are risks to the federation.
The role that InCommon plays as a trust broker becomes more critical as we talk about higher levels of assurance. The trust broker role could become a liability. When something is hacked or broken, there may be a greater risk to InCommon. This needs to be well thought out and adequately funded.
One risk would be that InCommon doesn't take planned and necessary risks to move forward. There is a risk in not being a little bit brave and a little bit risky.
There is a risk in failing to identify the federation's scope in light of what is necessary for competitiveness.
What is the risk of not moving into new areas? Will InCommon's current core services and competencies be endangered if we don't move into new areas? The greatest risk may be a failure to set up a governance structure that will secure what we have and allow for reasonable risks and expansion.
A possible definition of failure would be for other federations to proliferate, due to InCommon getting too small a percentage of potential membership.
----------
Planning/Vision
The vision should not be just the vision for InCommon, but the vision for federated identity as a whole.
How much effort was spent on predicting a reasonable market size? Is there a large enough potential customer base to support the greater cost?
Should there be a strategy to tie in other campus communities (like the library) and use their leverage to entice more SPs and vendors into InCommon
The document is missing a clear statement of the vision for the future.
Have a plan to attract core members beyond U.S. higher education institutions and encourage federal agencies like NIH and NSF.
Reach out to appropriate related organizations, such as public radio and television, and other "dot orgs."
Is EDUCAUSE a more natural home for InCommon?
The book "Crossing the Chasm" discusses a technology adoption lifecycle, dividing adopters into five different segments (innovators, early adopters, early majority, late majority and laggards). InCommon needs to determine its sweet spot, probably focusing on early adopters and early majority. These groups tend to be motivated by optimism. Higher education is not uniform, so think about the types of people to engage.
The way academe uses technology is changing rapidly. We will continue to have new opportunities as it relates to software over the network. InCommon could focus on core services, but also look at arising opportunities.
It is very important to continue to provide, and improve on, a robust federation. If we are talking about cloud services and other services, a robust identity environment will be needed and that could be the focus for InCommon. I would caution against expanding beyond the core mission of identity. It seems like there are players that provide the other services well. Areas in which there are related commercial activities may provide an opportunity for partnerships with InCommon.
This is a time of opportunity and a time to think big. But that needs to be done in the context of focusing on the core mission. We need to plan on having a service that can scale and having an appropriate and responsive governance structure.
Let's not try to be everything to everybody. We need to have a broad, long-term vision, but make sure what we do is achievable. We need to make sure that InCommon has the necessary resources.
Business Plan
Encourage InCommon members to include language requiring federation into appropriate purchasing contracts.
Pursue and take advantage of opportunities like the recent Google library settlement, in which federation is being mandated as part of the settlement.
The business case should be built on competence. The governance structure and sources of adequate resources must be very clear, and we need to be clear about the decision-making process. We also need to be clear about where the resources will come from.
We need to have Silver in place very soon (this was mentioned 2-3 times).
We need a clear marketing and communication plan in place very soon (this was mentioned several times).
Actively encourage Internet2 members to join InCommon.
----------
Services/Consulting
Set up an IdP of last resort.
Have InCommon provide legal document guidance on HIIPA, FERPA, etc., as a service to potential members.
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).
Offer support and services, perhaps modeled after Unicon, for Shibboleth, setting up and managing an IdM system, etc.
Which services make the most sense for furthering InCommon's purpose and growth? I would say Shibboleth training and support. While not a service, participating in (and taking a leadership role in) standards bodies will help position InCommon as the U.S. authority on identity management and federating.
I think training would be a big win. I run into this with some vendors that we would like to see in the federation. They want to play but they don't know how and they can't find a company to help them do it. This is especially true for smaller companies.
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.
What is the rationale for tiered pricing (is it your size? The number of SPs you work with?).
There is a sense that we are trying to define additional services, then raise fees to cover them. This may lead to contraction and rejection. You need to spend money to make money. It would be better to provide the services ahead of collecting additional fees.
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.