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.
Federated Identity
- 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.
As a user of this system it will occasionally be necessary to find a welder in the area that you have production. How do you engage and ensure that the welder has the correct certification for operating in H2S environments. Conceivably the ticket that was issued to the welder for H2S operations would be available from the granting agency. The welder's "Federated Identity" would have the certificate issuer represented in the welder's Identity and the certified issuer would have the right to revoke it if for some reason the welder no longer qualified. This certification is assured at the point of initial contact with the welder. If the Federated Identity were for an individual, a company or a Joint Operating Committee (JOC) one could easily assure that the conduct of online interactions were assured to be valid. The inability to authenticate would preclude the user, company or JOC from conducting any further online transactions.
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.
Accreditation and certification are needed, and also difficult to achieve. The most difficult aspect is what is referred to as "Many to many user centric identity". The presenters were wise to point out the two methods, "multilateral" and "bilateral" means of achieving accreditation and certification. By using multilateral accreditation you achieve the Many to Many user centric identity without having to accredit every transaction, query or specification as bi-lateral, or one to one, certification requires. The presenters noting "Commonly manage which identities and which attributes can use the capabilities of the collaboration tools." And "Can offer delegation, privacy management, maybe even diagnostics."
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