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.
----------
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.
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 services -- Per Ken, 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.