John Krienke provided an overview of InCommon. His slides are posted here. These slides include the rationale for a federation and for joining a federation.
The growth in distributed computing, outsourced applications and cloud computing have created the need for robust identity and access management systems to provide the necessary authentication and authorization. But universities can also face an increased risk of identity theft, users may be left with an unmanageable number of credentials, and growing complexity for implementation.
With a federation, each user has one ID and password and, through single sign-on, have access to a wide variety of resources. Resource providers don't need to manage user accounts and data stores. Since the campus does the authentication using its own identity management system, campus policies ensure that regulations like FERPA and HIIPA are followed.
The slides also include a demonstration of how federated access works and provide insight into the role of a federation:
1. agreed upon attribute vocabulary and definitions
2. criteria for IdM practices, privacy stewardship, and interoperability standards
3. trusted registration authority for all universities and partners
4. trusted exchange of participant information
One topic that came up at the session was whether a person with identities at multiple organizations (a university, a research agency, etc.) can aggregate their attributes from all of those identities. Shibboleth 2.0 has that capability, but its usefulness depends mainly on whether the relying party supports those functions.
Another question concerned the POP - Participant Operating Practices. Each participants posts its POP in on a public web page and all site administrators have access to all POPs. They can then make a determination if they want to business, on a case-by-case basis, with other participants.
There was also a discussion about higher levels of assurance, such as that sought by the NIH and NSF. They want to know that, when a person presents an ID, that the identity provider has done its identity proofing according to certain standards (such as those outlined in NIST 800-63). InCommon profiles bronze and silver match the NIST LoA1 and LoA2 requirements.
Two upcoming webinars were announced:
Monday, Oct. 19 - this webinar will focus on the upcoming changes in the organization of InCommon and its fee structure
Thursday, Oct 22 - this webinar will discuss the federation's acceptance of self-signed certs, SAML 2.0 support, any Shib upgrade issues, and other technical items.