Click on the title of this entry to be taken to Google Video for this presentation. First off a stern warning, the topic is a difficult one to discuss and the presenters do not do a very good job at it.
Firstly Bob and Ken do not adequately describe who they are or where they are from. The Internet 2 association consists of the majority of the university and other organizations, like Google, dedicated to "Providing both leading edge network capabilities and unique partnership opportunities that together facilitate the development, deployment and use of revolutionary Internet Technologies." Bob and Ken work in the "Internet 2 mid-ware initiative". Their presentation is about identity and its importance in collaboration and determining the validity of the party you are dealing with. Extending this to the type of collaborative interactions that will eventually be held in this application, and currently being specified in the People, Ideas & Objects Security Module, how are you assured that what is represented online is factual? There needs to be a method in which people can verify their identity and carry that with them through the day to day interactions discussed here in this application. The Federated Identity is described as follows.
- Enterprises exchanging assertions about users.
- Often identity based but can provide scale and preserve privacy through the use of attributes.
- Real time exchanges of standardized attribute / value pairs.
- Basis for trusting the exchanged assertions via common policies, legal agreements, contracts, laws, etc.
- Federations offer a flexible and largely scalable privacy preserving identity management infrastructure.
This style of interaction is currently being done in manual systems. Based primarily on past history, the user will call the welder up that finished the last job of his and not much more is done. And there is not much more that would happen in this virtual environment that I am talking about here. What is different is that a level of automation that eliminates much of the time wasting processing that is done in the manual style of systems. If the Federated Identity has enough terms and conditions that are necessary for the firm to hire that welder, they should be able to complete the majority of the contract prior to the issuance of the purchase order, which of course would also be the next step in this automated process.
These types of systems are being developed now not only for Internet2 but also for participating firms such as Google in their Google Apps for Education. Since we use Google Apps for People, Ideas & Objects, this type of Federated Identity is being built in the Security Module Specification that I am working on. The interactions are also an element of People, Ideas & Objects Compliance & Governance Module specification noted here. With the effective pooling of the participating producers human resources, requiring the Military Command and Control Style of organizations, these identity based interactions will be able to take on a dynamic matching of skills and function. One other area in which the Federated Identity satisfies is on the need to know basis. Even though all participants are from different companies their is no unnecessary leakage of information that would not have been pre-authorized to any other participant, individual or JOC.
The authors noted an Apache open source software "Shib 2.0" is capable of these types of Federated Identity and Shib 2.0 has just moved into beta. Much of the Federated Identity's ability to do these is contained within the "Technical aspects of Federations".
- Federating Protocol
- Enterprise signing keys
- Meta-data Management
- IdP discovery service
- Enterprise Identity management practices.
To view some of the areas in which Federated Identity is currently operating see InCommon and the Internet 2 wiki.
Technorati Tags: Genesys, Security, Collaboration, Google