DIDW: Identity Management vs. Managing by Identity


Phil Becker is using an interesting distinction to emphasize a point I've made several times before: identity management is about opportunity, not just security. He calls this "managing by identity" rather than "identity management." He says managing by identity

  • uses identity to organize, manage and secure computing processes
  • allows business process and computing process to align more naturally
  • releases the real promise and capability of network computing: networking business processes

Networking business processes across business boundaries has now become possible. Soon it will be necessary for survival.

Phil moves onto the topic of trust. Networks require trust to release their power. Human networks learn to trust over time. You can't buy, build, or create trust. Trust is granted by others based on behavior. Transparency is the surest path to trust. Secrecy impairs trust. If this is interesting to you, be sure to review Professor Kent Seamon's research.

The web browser taught people the concept of discovery and networking at the document level in realtime. Web services are the next step at the application level. These new network activities have shown us the need for management by identity.

Federated identity is about linking silos of identity into networks of identity in a way that scales. The only way to make this happen, according to Phil, is to keep the management local while allowing the identity to be used globally. I think this is a great definition of federation because it is general enough to allow multiple solutions.

Because its impossible to pre-define all the ways people will want to integrate data and applications, we need to be able to integrate on demand. This is a good view of what's different about Web services. Businesses integrate on demand all the time: they form teams of people to solve special problems on a regular basis. The tools don't support this kind of "integrate on demand" business process. Only a robust identity infrastructure can support this.

Portals are a starting to address this problem. Portals have always been about aggregation. Portals should be organized based on the user's needs and the policies of the applications and data. Think of what an employee portal is meant to do. Aggregate the data that a user needs in a personalized way. This is an interesting view of what portals do.


Please leave comments using the Hypothes.is sidebar.

Last modified: Thu Oct 10 12:47:20 2019.