Yes, we did, look in the list of “Sponsored Partners” here: http://www.incommon.org/participants/
What is InCommon you may ask? Well, you can read their website www.incommon.org on it, but basically “The mission of InCommon is to create and support a common trust framework for U.S. education and research.”
And that brings us back to the Federation at Scale topic that I posted about earlier: InCommon is one of the earliest, most well-known and largest examples of a multi-party federation. They bring together Service Providers and Identity Providers as members in to their federation and provide an organizational and technical infrastructure to arrange trust between the members.
The technical infrastructure is based on the exchange of SAML 2.0 metadata. Each participants sends it SAML 2.0 metadata to InCommon (well, participants really need to manage it and update it frequently) and InCommon publishes the list of all assembled metadata of all participants on a well-known URL. Each participant may consume that list on a regular basis and may “automagically” configure and update federated SSO connections to its peers that it wishes to connect to, based on the information in the SAML 2.0 metadata.
The most important benefits of such a system are
- members of a multi-party federation sign up to member policies so participants can rely on a minimum set of privacy, security and behavioral standards that their peers will conform to
- by standardizing on the attributes that will be used between federation peers and their meaning, the protocols that will be used and the profiles, connections to new federation peers can possibly be configured automatically without manual intervention (and yes, you know you can trust the new peers because they signed the same policy)
- the often overlooked or ignored bootstrapping problem of how to securely exchange metadata with your federation partners (no, e-mail can not do that for you…) is solved by a trusted 3-rd party
- updates in a partner’s metadata, but especially updates of signing keys are automatically propagated to all of your federation partners; and that is really important if you want to avoid suddenly breaking connections because of uni-lateral key rollovers (and is one that interests me the most from a technology perspective)
As you will have noticed by now, a multi-party federation eco-system such as InCommon is a way to scale up federated SSO from a peer-to-peer process to a community or group process.
So why did we join InCommon? We think that InCommon provides parts of the infrastructure that is required to scale up federated SSO to a true worldwide scale. It is interesting to be more closely involved with the InCommon community, to learn from them and to co-develop ideas on how to take it one step further.
Looking forward to that!