More about Federated Identity of the biggest problems facing any implementation of an identity federation is that all of the participants need to be using the same standards and protocols to achieve federation. Unfortunately, as time has progressed a number of different standards have emerged. This is not a big issue if you’re starting out from scratch and all of the applications that are being developed are being built in-house. As long as all of the participants within the federation can agree on a standard, integration issues are unlikely to arise. However, this imposes serious limitations on future scalability. It denies members the opportunity of integrating with applications developed around a separate standard. It also means that all entities, wishing to join the federation in the future, will have to conform to the same standard. With this in mind, you either want to choose a standard that is widely used, or you need a means to integrate across standards. So what are your options?

To start out, it is worth mentioning that as federated identity matures as a concept, many applications are capable of supporting the plethora of standards that have already emerged. Furthermore, there is already a convergence trend that is emerging where standards are slowly being redefined to be more ineroperable with each other. And this is largely down to the work of the OASIS group, with the SAML specifications; and Liberty Alliance, who have developed the ID-FF specifications along with ID-WSF. These separate standards have become increasingly intertwined with each other and the distinctions between them are slowly fading into history.. Focus Areas: BPEL | DITA | ebXML | IDtrust | OpenDocument | SAML | UBL | UDDI
OASIS sites: OASIS | Cover Pages | | AMQP | CGM Open | eGov | Emergency | IDtrust | LegalXML | Open CSA | OSLC | WS-I