of Hubris and Humility

It is said that hubris is not the act of thinking too highly of oneself, but rather not thinking highly enough of others.

It is the latter, not the former that reveals the inner working of our heart, the orientation of our conduct, and our true attitude towards ourselves. One who has high regard for others need not deprecate ones own abilities, gifts, talents, or choices. Indeed, a healthy and accurate view of oneself, of both ones strengths and weaknesses reveals itself in the strength to value, even honor the gifts and abilities of others. The failure to do so is not only a failure to recognize the value represented by the achievement of others, but it also reveals a depth of insecurity that underscores a truly self-centered attitude and the behaviour by which it is marked.

Jesus walked in humility, and that humility was not bred in insecurity, but rather in the absolute knowledge that though "He existed in the form of God, He did not regard equality with God a thing to be grasped, but emptied Himself, taking the form of a bond-servant, and being made in the likeness of men." The man who drove the currency exchange out of the temple with a hastily assembled whip was no wimp. Neither was the man who washed his own disciples feet. It was precisely because He was secure in the Identity given him by His Father that he could do so, and teach those who would follow Him the way by which they might share both his attitude and His service.


ref: Phillipians 2:6-7, Isaiah 60:1-2a


Tilting at Windmills 1: Identity Management v Access Control Management

I said I'd say why I use the term access control rather than the term identity management. I'm tilting at windmills, I know - but I don't think we manage Identities - though its a cool marketing idea. In fact we manage symbols we bind to notions of real persons like "Alice" or "Bob", and that we bind to non-real but useful notions such as "root," or "Administrator." We manage identifiers, which may be defined as the attributes of entities, real and non-real, having representations in some system. A login identifier or username is no more an identity than is my driver's license. The latter is in fact a certificate that contains identifying attributes about me; it is neither me nor my identity.

Access control management is the name that has historically (until about 2001) encompassed the management of subjects or users - their names and symbolic references; objects, resources, or targets - entities on which subjects may act; actions which describe what actions a subject may execute upon an object; and conditions or context unrelated to attributes of subjects or objects, which will inform an access control decision. Separating user administration from access management and calling it Identity Managment, has had debatable success from a number of perspectives.

Renaming something may enable us to look at it from different perspectives, and learn new things about it. The whole introduction of life cycle management into user administration has been a demonstrable benefit of identity management. But this wasn't a consequence of renaming it, it was a consequence of trying to address user administration in enterprise scale. I think the confusion caused by the divorce between access control management and user administration, I'm sorry - Identity Management - may have provided short term marketing benefits, but in the long run it has damaged the application of well founded principles.

While marketing departments and techno-strategists will vociferously defend their newly named product or try to explain why identity management is not user administration, or for that matter why SOA isn't client/server, or an attribute service isn't a virtual or meta-directory - call me a fundamentalist (no fun, and slightly mental) - but I ain't buyin' it.



Identity Mashups and Gravy . . .

Identity Mashup refers to the problem of properly rendering distributed information controlled by separate entities. Identity only refers to the type of information, and is important as a distinction only insofar as it relates to the access control model (user-centric policy control) and not to the information (user attributes).

For those inclined towards reductionism, the entire Identity Mashup/User-Centric Identity/Privacy/Cardspace/Higgins/SXIP constellation simply concerns access control and its management. That suggests to me at least that we can employ a fundamental understanding of access control theory to the problem. (Why access control and not Identity Management in following blog)

Traditional access control is implemented with a centralized security policy model such that access control policy is centrally administered across the resources protected. User-centric access control turns this model on its head - giving the users or account holders the ability to set access control policy on attributes associated with themselves.

User-Centric access control is related to the privacy problem. Its about a non-system owner (a user) controlling access control policy on data elements specifically delegated to it by the system owner (service). But in the end its all about the enforcement of a policy that says who can get to what when. It not important that the what are attributes about a particular person to the essential technical problem.

There are at least two differences between traditional access control systems and those that are user-centric. The first concerns who controls the governing policy - not the mechanism by which access control is effected. The second is akin to the digital rights management (DRM) problem - how to control access and use of remote information.

Cardspace, Higgins, and OpenID seek to address the first concern, providing the user with mechanisms to specify the information (user attributes) to which the user is willing to grant access. The second is problematic if the system on which the information to be accessed is not directly within the user's control, and its not by definition. The problem is exponentially more complicated if the information is distributed across multiple systems, which likely it is.

The system of which the Mashup is a part, is concerned with accessing potentially distributed sources of user data, and doing so in a manner that user-specified or otherwise distributed policy can be reliably enforced. This is true whether the implementation is an Eclipse Project Higgins Identifier Agent, Micrsoft(R) CardSpace, Higgins' Identifier Attribute Service (IdAS), Facebook, MySpace, or LinkedIn. Its also true whether the content of the mashup is rendered on the browser via Ajax or on LinkedIn as an aggregation of my connections' profiles.

Bob Blakley in his recent Burton blog reiterates his long held position that privacy (user-centric policy management) problems are at their core legal, social, and economic problems. I contend legal, social, or economic solutions are the default when the technical problem is intractable, its solution illusive or incomplete. Even if the enforcement challenge of Identity Mashups can be solved - the DRM aspects of user-centric policy management suggest that technical solutions for Identity 2.0 may suffer a similar fate as those for DRM. Certainly legal recourse is the soup du jour for those whose technologies are insufficient to the access control challenge. Can you spell RIAA?