Saturday, April 16, 2005, 12:48 PM

Identity Ontology Taxonomy

After reading thought-provoking posts by Kim Cameron and Luke Razzell on the ontology of identity, I was motivated to think about the process for systems design. One of the first and most important things to do correctly when designing systems is what I've referred to as object decomposition (the process of creating a conceptual schema) — which involves laying out (i) the taxonomy of objects and their component objects, (ii) the list of operations that can be performed on the objects (methods, verbs), and (iii) the relationships between all objects (e.g. contains, is-a, has-a).

As it is the basis of the architecture for the solution, the more accurately the object decomposition reflects the real world and the perceptions of users, the better and more adaptable the resulting system. What I've been calling object decomposition is similar to what Luke Razzell calls ontology. Object decomposition reflects the process of getting to a set of ontologies; it has to precede systems architecture and modular design.

Early in the design process, I like to checkpoint the basic concepts which seem to be relevant. (It never ceases to amaze me how a small definitional error can escalate to major design headaches.) A few of the definitions are derived from others, a few are obvious, and a few I've taken the liberty to nail down (somewhat).

An entity is a real-world object (person, legal entity, device) which needs to have at least one unique identity. A legal entity is an entity that can be a party to legal contracts.

An identity is a set of claims made by one entity about itself or another entity (to paraphrase Cameron). Identities are owned by their entities.

(Please note, in this article, I try to switch between using entity and identity carefully and delibrately.)

Anonymity is an attribute of an identity within a transaction (aka interaction) which tells you if the identity is anonymous or not (unanonymous). An anonymous identity is an identity that is not bound (linked) to an entity. An unanonymous identity is an identity that is bound to an entity.

A strong identity is an identity which, when participating in multiple transactions (aka interactions), results in high confidence that it is the same entity involved in all the transactions — the stronger the identity, the higher confidence. (See Strong Identities Can Be Anonymous.)

Strength is an attribute of an identity within a transaction (aka interaction) which gives a technical basis upon which to believe that the specified entity is represented by the identity.
NOTE #1: An identity can have varying levels of strength in different transactions. For example, with your enterprise userid (identity), you can log into your desktop (transaction) with only a password (identifier); but coming in from a public kiosk into your corporate web email, you might need an OTP token in addition to your password. That's why it makes sense to talk about the strength of an identity only in the context of a transaction.
A server is a networked entity with at least one unanonymous identity that represents a legal entity.
NOTE #2: Important assertion: servers cannot be anonymous.
A client is a networked entity with at least one identity (anonymous or not). A legal entity has to access to other networked entities only via clients. Also, a client is not a legal entity, but the identity of the client is sometimes used to represent a legal entity (which is usually a bad idea).

An identifier is a set of data that comprises the claims for an identity. The identifier is the data, the identity is the set of claims.

For two participating entities in a transaction, identifier directionality indicates the anonymity of the identities of each of the entities in the transaction. Identifiers (in two-way transactions) are omnidirectional (both parties are unanonymous), unidirectional (one party is anonymous, the other is not), or nondirectional (both parties are anonymous; needs a broker).

A transaction (aka interaction) is an event involving two or more identities. For easier management, I believe that a transaction should be defined as an object in the digital world. Each participating identity in a transaction is either anonymous or unanonymous to the transaction. (For the database folks: I'm using transaction in a more generic, colloquial sense, as opposed to something with ACID properties.)
NOTE #3: In reasoning about anonymity and strength of identities, it became clear to me that these attributes only make sense in the context of transactions.

NOTE #4: Although it seems that identifiers serve to identify entities to each other, a different way to look at the picture is that the transaction is the well-known object to all participating identities, and it is through the transaction that the participating entities know about the other participating identities. I.e. the purpose of identifiers is to serve as links to identities in transactions. This observation augments the case for Scott Lemon's first and second axioms of identity.

NOTE #5: Thus, Cameron's directed identities are actually flattened versions of transaction identity graphs. Directional identifiers (a la Cameron) are simplifications of the following transcation identity graphs (except I don't know if he has talked about nondirectional identifiers):
Transaction (T) with
Unanonymous Identities
Omnidirectional Identifier

X <--- T ---> Y

X <-------> Y
E.g. an Amazon.com purchase.

Transaction (T) with
Mixed Identities
Unidirectional Identifier
(X is anonymous)

X |--- T ---> Y

X |-------> Y
E.g. free email like ZipLip.com; X is a user, Y is the mail server.

Transaction (T) with
Anonymous Identities
Nondirectional Identifier

X |--- T ---| Y
|
v
broker

X |-------| Y
E.g. Match.Com; X and Y are two users; Match.Com is the broker.
Authentication is the process of validating that it is indeed the owning entity that is using the owned identity in a transaction. Note that just because you know that the owner is also the user of the identity, doesn't imply that the identity is unanonymously bound to the entity. Authenticated identities can be anonymous identities. The stronger the authentication, the higher the confidence that the user of the identity is its owner (an entity).

A broker is an entity represented by an unanonymous identity that serves to facilitate two or more anonymous identities in a transaction. A broker group is a set of identities (anonymous or otherwise) which together act as a broker.

A relationship is a function which results in a measurement (true/false, yes/no, integer, etc.) when applied to two or more identities (not entities).
Note #6: I'm including relationship because I suspect identity networks need flexible, user/application-definable relationships. However, at this point, I'm not sure if an identity system requires more than a few pre-defined relationships (like member-of) — it probably does, but it is not clear to me how.
Trust is an evaluation, by an entity, of the reliablity of an identity when the identity is involved in transactions. (See Trust is an Emotion.) The level of trust is typically based, in part, on the technical strength of the identity, but also includes the evaluating entity's subjective evaluation (e.g. feelings) of the reliability of the entity the identity represent. Trust is at least partially transitive (as in the case of notaries) and is perhaps one of the measures of Razzell's ontological distance.

Homework
I'm running out of steam, but there are still a number of terms/concepts that I still have to pursue (perhaps in a future posting). These include:
disclosure ownership ... who owns the disclosed information in a transaction, legally and technically. (See Information Dogma.)
interaction ... to avoid confusion with the database world, should we use the term interaction instead of transaction?
group ... issues: membership, creation, ownership; is a community a group?.
identity disclosure ... is the information about an entity that is revealed in a transaction.
multi-party transactions ... where there are more than two parties in a transaction (e.g. close of escrow for property purchases involving a bank, the buyer, and the seller)... what are the issues?
notary ... entity relied upon others for more reliable (trustworthy) transactions.
Kim, Luke: Let me know if I've mangled your original intentions for the terms you were using in your discussions. I've put in nowhere near the rigor into the definitions required, but I hope this article does add to the much needed clarity in the digital identity conversation.

Resources:
Kim Cameron, From simple identity assertions to... identity ontology (http://www.identityblog.com/2005/04/10.html#a185)
Roger Clarke, Identification and Authentication Fundamentals (http://www.anu.edu.au/people/Roger.Clarke/DV/IdAuthFundas.html)
Luke Razzell, Ontological distance within the identity net (http://www.i-together.net/weaverluke/2005/04/ontological-distance-within-identity.html)
Luke Razzell, Wikipedia entry for Digital identity (http://www.i-together.net/weaverluke/2005/03/wikipedia-entry-for-digital-identity.html)
Sam Wells, Some Observations on the Context in Which We Live and Think (http://laissez-fairerepublic.com/Onto1.html)
Wikipedia, Digital Identity (http://en.wikipedia.org/wiki/Digital_identity)

Update (April 22, 2005):
Luke Razzell responds in P.T. Ong's taxonomy of digital identity (http://www.i-together.net/weaverluke/2005/04/pt-ongs-taxonomy-of-digital-identity.html)

Update (April 23, 2005):
I've decided to use interaction instead of transaction to avoid confusion with the database world. See Digital Identity Taxonomy. The taxonomy/glossary is in http://blog.onghome.com/glossary.htm.

Update (April 30, 2005):
David Heath pointed me to his article Secure identity in the Big Bad World.
Modified: April 30, 2005.

4 Comment(s):

Blogger Jaco said...

Hi Ong, Weaverluke suggested me to comment this post. I have contributed with the Digital Identity Wikipedia definition:
http://en.wikipedia.org/w/index.php?title=Special:Contributions&target=200.122.159.45

>>I made my comments using your original text and adding >> where my comment starts.

Please feel free to contactme any time by email, chat or phone (no blog yet....).
;-)
----------------------------------------------------------------------------------------------
An entity is a real-world object (person, legal entity, device) which
needs to have at least one unique identity.
>>Yes.
>>Also please note that an item may also >>have a Virtual Entity.

A legal entity is an entity that can be a party to legal contracts.
>>Yes.
>>Please note that in this case we are >>"moving" to the legal world, so
>>devices and items are not choices, but >>persons and juridical/legal
>>entities are.

An identity is a set of claims made by one entity about itself or
another entity (to paraphrase Cameron). Identities are owned by their
entities.
>>I understand the idea and agree with >>it, but may be the word "Content"
>>or "Ïnformation" fits better. Please >>note that a Virtual Entity is
>>composed of Presence, Information and >>Projection.

(Please note, in this article, I try to switch between using entity
and identity carefully and delibrately.)
>>Good!. I believe it will help using more >>the term Entity, instead of
>>using Identity for all cases.

Anonymity is an attribute of an identity within a transaction which
tells you if the identity is anonymous or not (unanonymous). An
anonymous identity is an identity that is not bound (linked) to an
entity. An unanonymous identity is an identity that is bound to an
entity.
>> Yes.
>> Please try expresing the same idea with >>diferent wording to see if it is >>cleaner......
>>How does this look to you?:
>>Anonymity is an attribute of an Entity >>within a transaction which
>>tells you if the Entity is anonymous or >>not (unanonymous). An
>>anonymous Virtual Entity is an Entity >>that is not bound to an Entity.
>>An unanonymous Virtual Entity is a >>Virtual Entity that it is bound to
>>an Entity.

>>A strong Virtual Entity is an identity >>which, when participating in
>>multiple transactions, results in high >>confidence that it is the same
>>Entity involved in all the transactions >>—the stronger the Virtual
>>Entity, the higher confidence. (See >>Strong Virtual Entities Can Be
>>Anonymous.)

>>Strength is an attribute of a Virtual >>Entity within a transaction
>>which gives a technical basis upon >>which to believe that the specified
>>Entity is represented by the Virtual >>Entity.
>>NOTE #1: A Virtual Entity can have >>varying levels of strength in
>>different transactions. For example, >>with your enterprise userid
>>(authentication), you can log into your >>desktop (transaction) with
>>only a password (identifier); but coming >>in from a public kiosk into
>>your corporate web email, you might need >>an OTP token in addition to
>>your password. That's why it makes sense >>to talk about the strength of
>>a Virtual Entity only in the context of >>a transaction.
>>A server is a networked Entity with at >>least one unanonymous Virtual
>>Entity that represents a legal Entity.
>>NOTE #2: Important assertion: servers >>cannot be anonymous.
>>Information/Content, is a subcomponent >>of a Virtual Entity and is a
>>set of data that comprises the claims >>for a Virtual Entity

7:48 AM  
Blogger P.T. Ong said...

This post has been removed by a blog administrator.

8:40 AM  
Blogger R Bencheikh said...

good article,
R. Bencheikh
http://biometrix.blogspot.com

4:39 AM  
Blogger DavidHeath said...

I wrote about almost exactly the same issues (without the benefit of taxonomy) almost exactly a year ago.

You might like to look at:

Secure identity in the Big Bad World
http://www.smh.com.au/articles/2004/04/13/1081621954002.html

Cheers....

David Heath

5:08 AM  

Post a Comment

<< Home