There was some interesting discussions during today's Ping Identity Advisory Board meeting. I've made some notes about things that caught my attention.

Identity needs to follow transaction as it cross security domain. Consequently, Ping's goal is to reduce friction in every transaction while maintaining security. There are some pain points that enterprises and consumers feel that provide an opportunity for Ping and other companies in this space:

• Too many identities, identity not portable.
• Transactions are increasingly inter-company (the extended enterprise) driven by web services, on-demand computing, outsourced business processes.

Salesforce.com is an example of an extended-enterprise operation that manages business processes for clients in an outsourced fashion. Right now, Salesforce.com maintains their own user directory and does not federate. To understand the problem this creates, imagine that you just had to lay off a group of salepeople. HR cuts their access to corporate systems, but they can still go into Salesforce.com and download all of your company's proprietary sales data. Provisioning in this environment might be frustrating, but non-federated deprovisioning can be costly.

Vendors of identity products try to set up hub-and-spoke style systems to lock-in users. They want their product at the hub and spokes feeding into that revenue stream. Networks eventually eat hub-and-spoke systems because of cost. This is what played out in the financial services market decades ago. Large regional banks were essentially hubs in a regional hub-and-spoke financial system. When large financial networks ('ala Visa and Mastercard) came into being, they quickly put regional financial systems out of business based on cost. There was no reason to have the regional systems in-between the merchant and the network. All it did was add cost, without adding value. So too identity federation?

SourceID 2.0's architecture is based on a workflow engine to support multiple protocols by mapping each message into a workplan that routes it through various modules in the engine according to what has to happen. This architecture provides a flexible architecture for supporting SAML, Liberty, and WS-Federation. This reminds me of some of the Web Services Intermediaries architectures that are used for processing SOAP messages.