Version 0.1
by Jack Krupansky - Base Technology
This proposal is in the public domain. It may be copied and modified -- provided that Jack Krupansky and Base Technology are credited and a link back to this original proposal is provided AND these same use and distribution terms are carried along.
Interactions, whether in the real-world or in cyberspace, are based on the concept of identity. If you send a request to a remote computer, there has to be some mechanism for identifying the path back to you. In some cases your real-world identity is needed for some interactions, but in many cases a very abbreviated "user id" is sufficient identity to complete an interaction. People are concerned with privacy, so they do not want their full identity used on every interaction. There is also the problem of so-called "identity theft". The goal is to enable more robust interactions in cyberspace, that both respect privacy and minimize the chances of unauthentic access. Legitimate law enforcement access is considered a requirement. Ultimately, we're trying to achieve a higher level of security, without sacrificing privacy or usability.
Identity is associated with an entity. Some of the common entities are:
Primarily we're concerned with personal identity, but organizational identity and object identity are also high on the list (e.g., X wants to buy product P from company C paying using Z and shipping to D via F.)
In philosophy, the essence of your existence is known as dasein. We each have our own dasein. Dasein is your essential identity, but stripped of all the worldly characteristics that we normally associate with who we are. It's essentially your placeholder or the skeleton of your identity on which all the details of your identity can be hung.
Technically, dasein (German for "being there") relates strictly to self-conscious human beings, but for our purposes we can draw a parallel to any entity that needs to be referenced. We'll let the philosophers have their dasein concept as is, and introduce our own conception of an entity's "being there", especially since there are also all sorts of aspects of philosophical worldview associated with traditional dasein that we have no intentions of adopting.
We have no concept of an electronic equivalent to Dasein since all known forms of electronic identity feature at least one identifying characteristic, even if only a user id. Still, Dasein is a useful concept since it allows us to abstract away all the details and drill down to the conceptual essence of an entity's existence. I feel that this is an excellent foundation upon which to build computational identity mechanisms. Maybe it's excellent simply because there are no details to squabble over.
In computational environments we're actually not concerned with an entity's actual real-world existence, but it's proxy existence in cyberspace. Sure, we need mechanisms for bridging the void between the real-world and cyber-space, whether it be via biometric devices or physical tokens, but once in cyberspace, the entity exists strictly in the form of its identifiers, it's name and it's "id". That said, we're very interested in assuring that there really is a rock-solid correspondence between identity and the real-world entity.
Although many entities have a real-world existence, there are also entities that exist only in cyberspace. Sure, those entities may be represented as physical bits on physical media, but those physical bits are only a temporal manifestation of the computational entity. Nonetheless, once we have referenced the identity of a real-world entity in cyberspace, there is literally no difference between a real-world entity and a purely computational entity.
This of course is the central question for identity in computational interactions: Who are you and how can I assure that you are who you say you are? This is the problem of authentication.
It is generally recognized that a given entity needs only a small fraction of another entity's details to engage in an interaction. I refer to this as "segmenting" the details of an entity. Each entity will have any number of segmented packages of its entity details, arranged for specific purposes.
This is a very useful concept, but doesn't really get at the core issues regarding identity in computational interactions.
Although some people prefer anonymity or otherwise shielding their true identity, many people seem fairly comfortable using their real names for computational interactions, and certainly for commercial transactions. This is fine, and there is significant value for having a relatively high degree of correspondence between computational identity and real-world identity.
The essential problem is that an entity can announce it's real name, but from the perspective of identity, it's a meaningless gesture without authentication.
I'm using the term "real name" to refer to either an entity's legal or official name, or its common name.
Most access-control mechanisms in use today involve very primitive "identity identifiers". The classic "user name" or "user id", coupled with a password, is still extremely common. It's easy to implement, easy to use, and works most of the time. The problem is that it isn't a very robust mechanism where iron-clad authentication is needed. Most user names and ids are either publicly known or easily guessed, and passwords are rarely very robust, if for no other reason than the fact that most people feel the need to write them down or otherwise record them.
Rather than use a single identifier for all interactions, it makes sense to have custom identifiers that are assigned to specific classes of interaction, possibly even for interacting with a specific entity. Conceptually, it would be better to have a distinct identifier for each interaction pairing of entities, so that a breech of security on one interaction doesn't automatically cascade to other interactions.
It also makes sense to use discrete identifiers for each transaction. Again, a breech of security on one transaction should not automatically endanger all other transactions between entities.
An entity may authorize another entity to act as its agent. This complicates authentication a little, but with a multi-level authentication scheme, all you really care about is whether an entity is authorized to act as X rather than whether they actually are X. In fact, computational entities in general are agents for real-world entities, whether it be a user or an organization, or product, or service.
There is also the concept of autonomous software agents that can initiate interactions on their own, but on behalf of an authorizing entity. Such agents need to have their own identity, but also possess the "agency" of their controlling entity.
This is only a preliminary, rough sketch of the concept. The goal is to crystallize the conceptualization of identity.
There's a lot more to it than that, but that's the basic idea. What do you think?
Updated: January 30, 2006 09:00:41 PM -0500
Copyright © 2005 John W. Krupansky d/b/a Base Technology