Child pages
  • InCommon 101 (2009)
Skip to end of metadata
Go to start of metadata

InCommon 101 - 2009 Spring Member Meeting

April 28, 2009

Agenda build
• Overview of InC
• HSPD-12 cards and federation
• Interfederating (K12? State federations?)
• Challenges facing participants
• What are the membership benefits?
• Applications to take advantage of
• State systems in the federation


The April 2009 InCommon Update was distributed and John Krienke overviewed the available case studies. He reviewed the charge and process of the Future group and gave a brief history of InCommon.

John also provided an overview of InCommon, the increase in use of distributed applications, the basics of leveraging an institution's identity management system, and how a federation helps to manage this. He also reviewed the principles of federation, the role of a third-party trust provider, the attribute exchange process, and how the parties negotiate which attributes to be exchanged.

As the trust provider, InCommon manages the metadata, keeping xml files of all registered IdPs and SPs. The federation determines that the organization actually owns the URLs provided in the metadata and digitally signs a key verifying all of the information. At its technical core, InC provides signed metadata, updated every day, and posts it for participants to use.

The Swiss federation has developed and deployed uApprove, an application that allows individuals to review and approve/disapprove the release of attributes.


Discussions continue on interfederating with European and other national federations. There are differences in practices and requirements among the various federations, making interfederating more difficult than it might sound. In addition, the European Union has a privacy requirement that requires a certain identifier, but no U.S. universities have that identifier. InCommon is taking some measures with the metadata to make interfederation possible. Over next two or three months, the federation will make it possible to self-sign certs so an institution can be in multiple federations.


The deployment of Microsoft Geneva (targeted for the end of 2009) will allow Microsoft shops to more easily integrate with a federation.


There are now 141 InCommon participants and the list continues to grow. Higher education institutions can sponsor SPs into the federation. One of the beauties of federating is that you can start small and then scale - collaborating with just one or two partners to begin.

There was a comment that one downside of the list of SPs is not knowing what type of services they provide - it isn't readily available based on the name of the SP.


John reviewed the cost, which includes a one-time fee and an annual prorated fee.

Convincing vendors to federate

There was a discussion about methods for encouraging more vendors to join the federation. One method that has proven successful in the past is forming a group with a shared interest in a specific vendor or service, then approaching that service provider. That is how Apple iTunes U became a federated service.

Risk Management

There was a discussion about risk management and what types of risks there are in federating an identity. 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.

  • No labels