Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

InCommon 101 BoF

April 23, 2008

Attending 

Steve Smith, University of Alaska
David Wasley, InCommon Technical Advisory Committee
David Walker, University of California Office of the President
Mike LaHaye, Internet2
IJ Kim, Internet2
Jim Wolf, SUNY-Binghamton
Mark Scheible, N.C. State University
Ardoth Hassler, Georgetown
David Todd, University of Vermont
Brendan Bellina, University of Southern California
Brian Gilmore, UK Federation
Mike Grady, University of Illinois, Champaign-Urbana
Carla Hunt, North Carolina Research and Education Network
James Deaton, OneNet
John Krienke, Internet2
Eric Marshall, Rutgers University
Phil Devan, Penn State
Sujay Daniel, New Jersey Edge
Asbed Bedrossian, University of Southern California
Dean Woodbeck, Internet2 (scribe)

John Krienke provided a review of InCommon and the use of Shibboleth. He provided a graphic of the typical user flow, the single sign-on capabilities of Shibboleth, and the elimination of service providers handling user accounts and personal data stores. The home organization (Identity Provider) controls the privacy and release of user information.

The role of the federation is to:

  • Provide a policy base for understanding how members run their systems
  • Agree on language and terms
  • Verify each organization
  • Provide digital certificates for trust in communication
  • Trusted "notary" for all universities and partners
  • Provide registry ("metadata") that each participant downloads - a scalable way to relay trusted information

The InCommon Federation now has 80 participants, including 21 that have joined since October 2007, a 26 percent increase. In addition, there is considerable interest from consortiums.

InCommon is proceeding toward adding a high level of security and trust, called InCommon Silver. A number of federal entities either now require this higher level or will soon. Silver should launch sometime this summer.

There were questions concerning the operation of UCTrust, a federation of University of California campuses, as an example of a federation built on top of InCommon. This allows UC institutions to assert attributes specific to UCTrust, as well as the attributes used through InCommon.

Texas uses a different method, having built an independent state federation. The Texas federation and InCommon are in discussion about developing an interfederation agreement.

There was a question about how InCommon and Shibboleth interact with other identity management systems, such as Sunguard and PeopleSoft. Shibboleth is independent from ID management systems; it sits in front of such systems.

One university mentioned its agreement with a large vendor. Some students had established IDs with that vendor but, because of the university's agreement, the vendor would still look for an ID with that university and authenticate the user. How would such a scenario be different using InCommon? The main difference is that the university would not have to negotiate policies and procedures with each individual vendor. The federation establishes policies and develops agreements with each of it participants, creating standards and certain levels of trust.

John Krienke announced the Federation Soup meeting taking place June 2-4 in Seattle. The meeting is intended for those interested in setting up national/state/regional federations and how those might interact with one-another and with InCommon. Information about Federation Soup is available at http://middleware.internet2.edu/fedsoup/

InCommon supports the InCommon-Participants email list, discussing collaboration and implementation issues. To join the list (InCommon participants only), send a message to sympa@incommonfederation.org with the following in the body of the message: sub incommon-participants FirstName LastName.