Painting the Future: Panopticons and Choice

After scrounging around for a while in the literature of digital identity, I still only have a fuzzy picture what the future of digital identity would and should look like. Here's my attempt at painting a more focused picture of the future:

Enterprises - Panopticons. Panopticons will be reality for enterprises. You'll be able to ask "What did Joe do the last sixty days?" and be able to get a reasonable answer as opposed to the blank stares from corporate officers today. Enterprises are legally accountable for the actions of their employees, so it's important and reasonable that they know what their employees are up do. Because employees are also private citizens, the debate will be around how much privacy an employee can expect while using an enterprise's resources, while working for the enterprise. Employees should not expect privacy with the identities issued to them by an enterprise because the technical systems will not support anonymous identities. (I'd better note here that my assumption is that private citizens who want privacy as employees can still get it using their personal identities.)

Identity Providers (IdP's) - Every Server. Most of the present services (Amazon.com, Skype, Gmail, etc.) and future ones will be their own identity providers for their users. As the experience of Microsoft Passport has shown us, there is no incentive for an organization to depend on some other entity to be the identity provider for their own customers. (See also Pick your superpower by Ben Hyde.) And as far as end-users can tell, regardless of the sophistication of the implementation, to do otherwise would be construed as breaking Kim's Law of Fewest Parties.

Global Identity Providers (GIP's) - the Few. Money talks. The only global identity providers I can think of are the credit card companies (Visa, MasterCard, American Express). Governments come close, but a business in Paris might not accept an identity issued by the state of Texas. These GIP's will be the means by which the vast majority of IdP's notarize the identities the IdP's manage in order to ensure that the identities they have are unanonymous.

Private Citizens - Choice. Private citizens will have a choice of anonymous identities or unanonymous identities with different trade-offs. There might be proxy services that allow consumers to anonymously shop online. By contrast, consumers could also choose to allow organizations to track their online behavior for financial or other considerations. A private citizen could choose to have an almost zero online footprint or could be fully visible in all their activities; the bulk of us will be somewhere in between, with some aspects of our digital life visible to the other entities we deal with, and other aspects private. The future will bring us choice. (Yes, I'm an optimist.)

Question. If you accept the future I've painted (which is admittedly pretty silo'ed), what do you think that means for the adoption of federated identity systems? (Peter Davis also has something to say about this in Where are the Customers?)

Resources
Jamie Lewis started the ball rolling for me with Ends and Means: Identity in Two Worlds. Tim Grayson responded with Information Dogma, which prompted my note in http://blog.onghome.com/2005/02/information-dogma.htm. Alex Cameron helped with Beyond the Panopticon: Architectures of Power in DRM. And, of course, Kim Cameron with his seven Laws of Identity (which I'd rather label "Principles of Identity Systems Design", but alas, we might have past the tipping point for labeling Kim's laws/principles) laid out the rules for building universal identity systems. Stefan Brands and Johannes Ernst helped me clarify my thoughts on how Strong Identities Can Be Anonymous.

Sanity Around RFID Passports

It's not a smart idea to paint electronic bullseyes on all US citizens travelling abroad via RFID passports. Most people can figure that out. I'm glad to see the US State Department is starting to get it (see: Feds Rethinking RFID Passport). Although, RFIDKills.com doesn't think we've seen the last of this idea yet.

Resources:
o Andre Durand, Death by RFID Passport (http://www.andredurand.com/2005/04/04.html)
o Dave Kearns, State Department's RFID passport proposal gets complex (http://www.networkworld.com/newsletters/dir/2005/0502id1.html)
o Jamie Lewis, Feds Rethinking RFID Passport (http://www.burtongroupblogs.com/jamielewis/2005/04/feds_rethinking.html).
o RFIDKills.com, RFID Passports: Not Dead Yet (http://www.rfidkills.com/)
o Bruce Schneier, RFID Passports (http://www.schneier.com/blog/archives/2004/10/rfid_passports.html)
o Kim Zetter, Feds Rethinking RFID Passport (http://www.wired.com/news/privacy/0,1848,67333,00.html)

An Initial Digital Identity Taxonomy

Thanks to Jaco Aizenman and Luke Razzell for feedback. I thought I'd go one step further and get my initial digital identity taxonomy (more accurately, glossary) laid out as a page on this website:

http://blog.onghome.com/glossary.htm

I decided to use the term interaction instead of transaction to avoid confusion with database transactions.

Any feedback would be appreciated.

Update (April 24, 2005):
Thanks to Jaco Aizenman and Jack Krupansky for their comments. I decided that Jack was right and to call this collection of definitions a glossary, instead of a taxonomy.

Update (April 27, 2005):
o Slimlined glossary by simplifying definitions, and taking out what's not necessary (e.g. entifier).
o Luke Razzell has updated the entries on digital identity on Wikipedia. I'll join in if I can find a few spare cycles.
o Jack Krupansky linked back to the glossary at http://www.basetechnology.com/nature_of_identity_links.htm.
o Kaliya Hamlin also linked back at http://identitywoman.net/archives/2005/04/digital_identit_2.htm.

Update (May 4, 2005):
o ChangHee Lee linked back (in Korean) at http://guldook.blogspot.com/2005/04/digital-identity-glossary.html; but just to clarify, I'm not associated with PingID... I don't know Korean either.

Update (August 9, 2005):
The Berkman Center has some work on digital identity lexicon (http://cis-berkman.editme.com/Lexicon).

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.

The Enemy of the Better

Last month, Bruce Schneier highlighted what he expressed as the futility of deploying second factor authentication (2FA). I believe he missed the main point, that so long as the user is approving transactions via a compromisable platform, transactions cannot be guaranteed secured.

The problem has got almost nothing to do with 2FA. Pardon my analogizing, but Schneier was yelling "the barn's on fire!" when the smoke is coming from the house.

One (philosophical) issue I have with Schneier's article is that he doesn't suggest a way out of the problem. I believe that if you cry wolf, you should try to have a plan for mitigating the attack of the wolves. But you do have to identify the root problem before an appropriate solution can be proposed.

Another (more practical) issue I have with Schneier's approach is that he is making the best the enemy of the better. Given today's technologies, is having a 2FA better than not having it? Yes! Especially if the second factor involves physicalization. The bad guys might catch up by exploiting the vulnerabilities of client platforms, but we can address that by detecting and closing up these vulnerabilities. Without 2FA, how easy is it for someone to "bug" your computer to extract your password? Once they have your password, they have your identity-they don't have to wait for you to access the server again (as when they do if you have 2FA) to commit fraud. With plain passwords, no physical theft is necessary to commit identity theft.

If I were to suggest a plan to increase the strength of digital identities (identities that are harder to steal), I'd include the following (somewhat obvious) steps:

1. Move to physical factor authentication (preferably with phyisicalized secrets, as opposed to shared secrets)
2. Use inspection technology to watch for breaches (anti-virus/spyware/phishing software)
3. Make sure your client platform has the latest security patches

In the mean time, the industry should:

4. Figure out how to breach-proof our client platforms-specifically every client platform vendor has to do this (Microsoft, Apple, Nokia, Samsung, Blackberry, PalmSource, etc.)
5. Develop a Secure Transaction Token (STT). This is going to be difficult because it involves defining standards for the industry... and creating a new standard is next to impossible (see The Symmetry Principle).

Automating the inspection of compromisable clients for breaches and deploying physical factor authentication for network applications are together better then just using plain passwords. Getting to systems that are technically near breach-proof is possible with STTs, but the widespread adoption of these systems is unlikely.

I would not make the best the enemy of the better by ignoring what is better (and possible) than the status quo of plain passwords just because we can't get to the theoretical best right now.

Update (April 14, 2005):
Bruce Schneier follows up with More on Two-Factor Authentication (http://www.schneier.com/blog/archives/2005/04/more_on_twofact.html).