Presence enabled identity

Giving back digital identity ownership to end users has been one of the most in-vogue identity meme of the year. But why is digital identity not any more in its owner possession in the first place? Mostly because there is no way for an application to trace the real you back and check your privileges when needed. The result is the high number of digital identity fragments disseminated all over the internet that every power user has left behind in its wandering.

An obvious first answer to this fragmentation is the re-concentration of digital identity fragments in a limited number of places. The usual advantages are put forward, mainly the convenience of near single-sign-on. On the web, several alternatives have been implemented by various types of identity brokers, which are able to provide relevant assertion about a party identity and/or privileges. But most proposed assertion systems require the end-user to trust the identity broker. And frankly speaking, I am not convinced many end users go to the length of making sure when choosing an identity broker that:

• Strong credentials are enforced and required by the broker,
• Credentials are securely stored in the identity broker's database.
• Physical and perimeter security at the broker's point of presence is enforced.

The next obvious answer would be to re-concentrate the complete digital identity in the immediate vicinity of the end-user. After all, many tend to agree that physical ownership gives a better feeling of security…

An interesting proposal has been made in a recent series of posts, where are described the components of a reinvented internet. I have several concerns about the entire internet re-invention, but Jason is also bringing up some clever and simple ideas. In his approach, each and every user will own a domain name on which a private identity broker will be located. The proposal is interesting because an application can use the private identity broker directly as it would a web identity broker. Today's applications will also be able to resolve that private broker address just using DNS.

Although it gives a better sense of ownership to the end-user, this approach does not entirely provide a solution to the original question when the user is going mobile or when an external application requests a dynamic authorization. These use cases are no edge cases in my opinion.

Carrying a laptop everywhere may not provide the ultimate freedom. A PDA might give a better feeling, but still. Using a password from a distant terminal will work, but is not better that today's solutions. And being remote definitively decreases the ability to provide interactive authorizations. I believe real identity ownership would ultimately involve some kind of portable device, using biometrics to assess one's identity when in use. This device would in turn advertise its presence on the network. It would then be "seen" by the private server. In turn, the server would be able to interact securely with the device and retrieve whatever privileges required by calling applications.

This is the nearest I would go toward bringing together identity and presence. And why not just call it "presence enabled identity".

Technorati Tags: Identity, Presence, Trust, Digital identity, Antecipate

The Descartes identity

In a recent exchange of views, one of the participants to the discussion was "interested in hearing [my] definition of an online identity". This is certainly one of the toughest questions I have been facing. From the start, asking for "my" definition is already recognizing "online identity" as a controversial subject. I certainly have no pretence to defining what "online identity" is. But I can try to express what I know about my own identity. The only real identity I know of is what I have in my own head. We have been gifted with a conscience but unfortunately with poor means of communication. As a direct result, it makes it rather difficult to share my identity with anyone but me. This is probably the same for every human being. At every moment, I am only able to use our crude means of communications (speech, visual contact, body language…) and in turn I am only able to convey a crude expression of my identity. But this is of exceptional quality when compared to what it becomes when filtered by the Internet communication tools. The lower quality of any communication technology compared to human expressiveness makes the resulting identity perception rather approximate…

I do not have an online or an offline identity. I just have an identity…

I am hearing here and there that whatever we do on the Internet is leaving a trail and, by extension, that for example a mail address or a blog are ultimately representing one's "online identity". I certainly disagree with what I consider a reductive simplification. I never thought of this blog or any communication address I use as representative of an "online identity". My blog is a way of expressing very specific opinions on a limited number of technical topics that in other times I would have expressed using a different medium. I am concurently voicing different opinions on different subjects in many different places such as cafes, art galleries, restaurants, exhibition, streets, during business meetings or in my home. I do not have an online and an offline identity. I just have my identity.

Like many other human beings, I have been given some attributes to "assert" my identity to other beings or systems that would require it. … But beyond the 4 digits of my ATM pin code, I am not using these attributes very often.  In particular, I believe "online identity" is mainly an euphemism for address handles. I consider an email address as an address handle that can be used to communicate with me. No more, no less than a post office box. Actually, at the post office, I will have to produce an attribute to "assert" my identity if I want my mail, but my P.O.Box is in no way representing my identity…

To conclude, I find today's rhetorical debate about identity which is raging in the blogosphere rather limited when confronted to Descartes' "I think therefore I am". I only have a certainty in this domain: the day I will stop thinking I would have lost my identity.  This is all contained in five simple words. But Descartes had a valid excuse: he was a genius.

Technorati Tags: Identity, Addressing, Trust, Digital reputation, Digital identity, Antecipate

"Battelling" for privacy

Even if he denies it, John Battelle is discussing growing privacy concerns in this seemingly inocous post. But under the appearance lies an undisputable fact: privacy protection, be it written in laws or not, is at risk because of search.

Search provides a framework for thinking not only about mail (what is it about Gmail that makes it really unique? It's searchable…), but for our entire clickstream, which is fast becoming an asset.

What makes something private, beyond property, is the possibility to decide how that thing is exposed. As soon as there is exposure, privacy is breached. The first time you take your brand new car out of the garage, you make it public, and you loose part of your privacy. A letter is private when protected by the ephemeral barrier of the envelope, as it was yesterday by the seal maintaining the parchment roll. But what would we say about privacy, when the mailbox becomes searchable? Surely that is does not exist anymore.

What differentiate today's practices about personal data is the daily recording of growing quantity of "identifiable" information on centralized servers. The reasons are multiple. Simply put greed to access and monetize this information is a strong driver behind this trend. No doubt, recording of private information has existed for immemorial times. True, until recently it has been rather difficult to link together the different islands where that information was residing. Looking at what difficulties lies in reconstructing one's genealogy gives a good example of how "identified" information could be difficult to trace. But in the context of the web, these obstacles are vanishing. By looking at how people willingly release more "identified" private information everyday, this will become easier and easier.

One in ten internet users have registered at a social network, for example, and one in five have visited one. The reason for this shift is simple: innovative companies have figured out how to deliver great services (and make money) by divining clickstream patterns, be it a underlying divination, like PageRank, or a more direct one, such as AdWords or Amazon's recommendation system.

Needless to say, I believe this a result of abdicating any critical analysis of the associated risks. Adhering to a "social network" boost one's image by widening its exposure, and therefore by automatically decreasing one's privacy. Obviously, there is no "social networking" without releasing of a slice of personal "identified" information. Where would be the salt of life without gossip… And what is today's first mean of gaining exposure? Simply making sure this information appears on the top lines of search results… This is the first breach of privacy.

Behavioural experts will explain why the need for "exhibitionism" is common amongst humans, which makes me believe we are only at the beginning of the "social networking" adoption curve. The same experts will describe that the next step is to use distinctive signs and symbols. This is where the "innovative companies" come in to deliver "great services". Looking at it, how different is it to wear a tee-shirt with some well know brand, or to have it appear on your own "private" page. You don't get a dime out of it, the "social network" host does. This is the second breach of privacy. Obviously the "personalized" targeted add on your "private" page has been using your "identified" information…

More importantly, this seemingly disparate information, residing in the various service providers servers, can now be reconciled. Search can make these many data islands look like a wide open territory. The next frontier…
The privacy laws "fathers" have probably been blinded by technology experts in their laudable attempts at protecting this part of our identity. They where certainly told without a common database "key" personal information could not be correlated. Nowadays, with the growing power and refinement of the search engines, a common database "key" is not needed anymore, you only need a reference to an identity handle somewhere in a web page. The associated data does not need to be structured anymore. Search is slowly but surely circumventing all established privacy laws, with their outdated reference to unique keys.

Regaining control of our identity information and privacy starts by requiring that each of those "innovative companies" provides a "delete my information" button on the account management page of their services… It also requires that data held in their store be completely anonymized by using opaque indirect references. At least, if the data itself is not wiped out when I require it, it would only become part of the greater statistical whole. This is better than being "exposed" in public...

Technorati Tags: Identity, Digital privacy, Digital reputation, Digital identity, Antecipate

Weaving an identity society

…Society must evolve to become an integrated yet privacy-enabled medium for people's diverse expressions of identity…

When I commented on Luke Razzell’s blog I wasn’t really expecting more than voicing an opinion on the growing Microsoft influence in the identity and privacy space. Luke hinted at the paper he had been co-authoring with John Madelin of BT to address some of the biased “laws” set by Kim Cameron and “set out a a more comprehensive vision of an Identity Web”.

Since then Luke’s announcement has become a reality, and taken the form of an open discussion wiki. The Web is becoming a more human-friendly and semantically-rich space, where people will be able to negotiate control of online information sharing. An “Identity Age” is dawning. The Identity Society wiki is aimed at discussing the nature of the associated challenges in depth:

• Lead with thesis,
• Avoid polemics,
• Be accessible to a broad range of stakeholders,
• Drill down from broad philosophical context to specific user requirements and business cases

For those wondering, this is what kept me away from blogging the past week…

Technorati Tags: Identity, Digital identity, Trust, Antecipate

Trust Pot Pourri

…shortcomings may be corrected without great difficulties using ingenuity and pragmatism…

Beyond the announcement, the proposal put together by Peter to strengthen “trust” in XMPP leaves me perplex. Under the surface, the document looks like a hastily assembled “pot pourri” of ideas that have been laying around XMPP for some time. The document certainly provides a good inventory of the XMPP technologies available today the area of security. But I believe many of the described shortcomings may be corrected without great difficulties, by just using a good dose of ingenuity and pragmatism.

• On the server side, I believe the major task would be convincing and educating many more Certificate Authorities to include the XMPP specifics into their server certificates. It is somewhat frustrating when you discuss with CAs and find out they do not conceive a server certificate outside a web server certificate, and a client certificate beyond a browser of mail client certificate.
• Support for SASL External and TLS already exist in many open source servers, beside the commercial ones. Again, I do not think we have a technical issue to implement secure links between federated XMPP server, but rather a matter of organization and agreement to use these SASL/TLS instead of dialbacks. The weight of legacy maybe?
• It maybe interesting to use a phased approach to reach the ultimate secure federation. In a first phase, SASL/TLS could be applied with web server certificates. Then later, when real XMPP certificates become widely available, they will be substituted. But, I believe supporting web certificates and the associated SASL checking is a must, as certain commercial CA may delay on purpose providing real XMPP certificates. We must also account for corporations or agencies that would use open source XMPP servers with certificates from these CAs.
• As discussed earlier, the number of end-to-end encryption implementations in XMPP is negligeable. I have described how the current "encrypted sessions" method, which is an XMPP implementation of the Off-the-Record messaging , goes beyond what is necessary to ensure a very good end-to-end encryption. In particular, I find the section related to “offline secure session” superfluous. It also introduce higher risks of key being compromised than a version dedicated to “online secure sessions” only. The JEP-0116 specification is an excellent starting point, but would greatly benefit from being simplified. After all, hasn’t XMPP always wanted to be associated with simplicity?
• I am convinced every XMPP server can become a repository for public keys. XMPP already allows a number of “personal” data to be published through Personal Eventing Protocol and other means. I do not really see what major difficulty there would be in extending these existing mechanisms for public keys publishing on the users’ home XMPP server. In my opinion, this would be an easy first step in creating the infrastructure required when stanzas signatures will be introduced.

I am more sceptical when the document describes “greater reliability of client-to-server and server-to-server connections” as a component of increasing an XMPP network’s trust. Reliability is important, but unless we do word plays, this is a matter of risk assessment, not a matter of trust. I am not convinced XMPP suffers in that area when compared to other public IM protocols. XMPP is certainly not suffering in the comparison to SIP/SIMPLE. In this protocol, un-delivered messages trigger an error. But the protocol does not provide a way to recover after an error. This is left to the implementation… Applications of XMPP beyond IM may certainly require and benefit from high reliability, but the examples given in the document fail to convince me this could greatly increase my trust in the XMPP network.

Similarly, I understand that administrators would benefit from a better monitoring of distributed XMPP servers. But, presenting this as an important factor to increase the trust of an XMPP network is probably exaggerated. In real life, when an application provides reliable services, end users will be attracted to use it. As soon as the service starts to degrade, they will move away. They will not need statistics about uptime, they know who is providing best services by word of mouth. Statistics are for administrators and marketers… Statistics on uptime do not re-enforce trust, they provide justifications. From a technology stand point, creating a binding of SNMP inside XMPP could present an interesting challenge. But I do not believe XMPP will quickly displace other network monitoring technologies. That said, if the “monitoring” only consist in performing authenticated login scripts against a list of servers, using a simple scenario for Tsung will provide a quick and easy answer… As the results can also be easily archived, we would only need a graphical interface to present the statistics.

…a trust reputation system will require more than a $5000 budget…

I have left the “reputation system” for the end. Obviously providing a “reputation system” is very fashionable these days… Believe me, that will require a little more than a $5000 budget. But it is late, and I’ll come back to this very interesting subject later.

Technorati Tags: XMPP, Jabber, Security, Trust, Antecipate

Protecting identities with XOR

When the average user speaks of security, encryption often comes first in the conversation. While encryption is an important component of security, it only deals with a subset of the challenges inherent to communications security. This is missing the bigger picture. Cryptology covers primarily the confidentiality of transmitted data, while the identities of the communicating parties remain unprotected. On the Internet, this shortcoming has been addressed by a technology called “onion routing” (OR). OR as a technology has been around to provide anonymous communication for some time. TOR, its second generation, is adding perfect forward secrecy, congestion control, directory servers, integrity checking, configurable exit policies to the original design, while avoiding infringing patented patterns used in the original design.

Onion Routing is a distributed overlay network designed to anonymize TCP-based applications like web browsing, secure shell, and instant messaging. Clients choose a path through the network and build a circuit, in which each node (or “onion router” or “OR”) in the path knows its predecessor and successor, but no other nodes in the circuit. Traffic flows down the circuit in fixed-size cells, which are unwrapped by a symmetric key at each node (like the layers of an onion) and relayed downstream.

I have been toying with the idea of applying the principles of OR to XMPP at the protocol level to provide end to end anonymity of conversations. I am presenting the overview of how XOR (XMPP Onion Routing) could be implemented on top of XMPP. TOR enhance the original OR design of layered cryptographic payloads by introducing “telescoping circuits”. This type of circuit allows an initiator to negotiate a short-lived session key with each successive node along a path, and use this key to encrypt the onion layers. Diffie-Hellman is used for key exchange. The "telescoping circuit" model brings two important benefits on top of forward secrecy. First, it allows multiplexing multiple conversations over a single circuit, letting the initiator to set up a single long lived path across the Onion Routing network, which can be use to access multiple destinations. Second, it allows “leaky pipe” routing. Any node along the path is a candidate exit point, making traffic analysis particularly difficult. Individual Onion Routers can be configured as exit nodes, and the type of traffic they will allow to exit specified.

The Tor network is an overlay network; each onion router (OR) runs as a normal user-level process without any special privileges. Each onion router maintains a TLS connection to every other onion router. Each user runs local software called an onion proxy (OP) to fetch directories, establish circuits across the network, and handle connections from user applications. These onion proxies accept TCP streams and multiplex them across the circuits. The onion router on the other side of the circuit connects to the requested destinations and relays data.

Applying this model to XMPP is easy. The XOR network is an overlay network, implemented using XMPP S2S connectivity. Each XOR router will use a TLS connection to reach every other XOR router participating in the overlay network. XOR will require an extension to the protocol to allow a XOR client to discover XOR support, and browse the overlay network nodes directory. XOR clients and nodes should use JEP-0116 encrypted sessions as the base mechanism to establish the “telescoping circuit” layers along the chosen path. XOR nodes will accept XMPP stanzas streams and multiplex them across the circuits. The XOR node at the other end of the circuit connects to the requested destination and relays the stanzas.

Instead of taking a direct route from source to destination, data packets on the Tor network take a random pathway through several servers that cover your tracks so no observer at any single point can tell where the data came from or where it's going. To create a private network pathway with Tor, the user's software or client incrementally builds a circuit of encrypted connections through servers on the network. The circuit is extended one hop at a time, and each server along the way knows only which server gave it data and which server it is giving data to. No individual server ever knows the complete path that a data packet has taken. The client negotiates a separate set of encryption keys for each hop along the circuit to ensure that each hop can't trace these connections as they pass through.

In the now traditional Shakespearian way, When Juliet wants to have a secure and anonymous conversation with Romeo, she will chose a random path between the capulet.net and the montague.com server from the retrieved XOR directory information. She will then negotiate an ephemeral session key with each XOR node along the path, including Romeo's client. She will then build all the onion layers to encapsulate her message and deliver it to her own XOR server. Each XOR node on the path will peel off its own layer, decrypting it with the ephemeral key negotiated with Juliet, and route the remaining layers to the next node. Upon receiving Juliet's stanza, Romeo will be able to build its own “telescoping circuit” to respond to Juliet. This circuit will use a randomly chosen path to Juliet's client, which will be different from path taken by Juliet's stanza to reach him.

As stated at the beginning, this is an overview of how the OR model can be applied to provide anonymous conversations on top of XMPP. I believe this technique added to the encrypted sessions negotiation will provide additional protection of the identities involved in a particular conversation.

Technorati Tags: XMPP, Jabber, Addressing, Identity, Security, Trust, Onion routing, Telescoping circuit, Antecipate

Decreasing the prejudice

I have been venturing into the wide identity space for a very simple reason. Although I do not pretend being an expert in this field, I believe using a communication address as an identity GUID is detrimental to the identity system relying on this identifier, and to the communication system that is using this address for routing. Communication systems are more my cup of tea. While researching the subject, I came across the latest fashionable sub spaces on the subject of identity, namely “digital reputation”. In a previous post, I explained what makes me suspicious about this concept in the very wide sense. This definition of reputation in the context of blog comments may reconcile me with some of the possible applications of digital reputation. Actually I find the authors idea of “reputation system” interesting.

reputation is a 1 to 1 relation between the reputed party (the blog commenter) and a reputation-relying service (the blog)

This is a much narrower definition than the more generic, all contexts inclusive, definitions I have been exposed so far. I have no difficulties extending this functional definition to any “reputation system”.

reputation is a computed value, the computation is performed by a reputation-asserting authority (the reputation manager service) from a collection of transactional data (acceptances and rejections of previous comments to other blog posts) and identity data originated by past interactions of the reputed party with reputation-relying services (other blogs).

I find this second functional definition a little trickier. Obviously, as a critical human being, I understand the underlying expectations buried in such definition. I also understand its limitations:

• the reputation system relies on “identity data”. In effect, the reputation system will be entirely dependent on the unicity of this “identity data” in order to compute the “reputation value” and keep a record of the “past interactions”
• to comply with privacy protection, the reputation system would certainly have to work on opaque tokens, instead of more explicit tokens such as mail addresses. This is the only way to ensure a minimum level of “identity independence” in the calculation process.
• the entire system will be bound to the pre-requisite that the spammer would play by the rules of good behavior. More specifically, it implies the spammer will behave in such a way the “reputation system” will always recognize it as the owner of a previous “identity data”. The game may becomes slightly more difficult if the spammer keep changing identity data.
• the “identity data” correlation problem becomes rather complex once the “reputation system” would require access to “interactions” outside the boundaries of a single blog. This aggregation can be eased up by setting up the “reputation system” as an external party. In this case, the token must only be thought off as a reputation token, and not an identity token.

Approaching the problem from that angle would make me feel more comfortable. I believe the blog “reputation system” could be built upon presentation of this reputation token, as long as this token does not provide direct mapping to the owner’s identity. After all, the blog is only interested by a repetitivity and scaling quality index on the posted comments. Using an identifier, and not an identity, to reconcile and group together the collection of transactional data used to compute that index is a perfectly valid approach. But it has the invaluable advantage of protecting the privacy of the comments’ author.

I disagree on several counts with Dick Hardt when he tries to mush up identity and reputation. But what could I expect from a blog trying to describe a “next generation identity”? Identity is our essence. Outsiders will use multiple attributes to incompletely describe how they perceive our identity in their own ontology. Our identity may possess certain innate attributes that are more permanent than others, but we do not usually disclose them easily. As a matter of fact, in most cases, identity attributes are imposed on us. Defining identity broadly (identity == reputation, identity == transactions, etc.) infers that we lose the ability to do anything useful with it. In particular, privacy concerns gets much broader. So, when someone tries to over simplify, and come up with the blunt statement that reputation is identity, he earns a bad value in my “reputation system”.

With respect to comments on a blog. We envision the commenter needing to build up a reputation over time, and it would be associated with a particular persona. Since it takes a sequence of good behavior to build a positive reputation, there is a cost to that reputation, that good netizens will want to preserve if having a good reputation provides additional value.

Once again, another “good intent”. I understand the requirement, but I would only agree on a resulting system based on contextual reputation, and not identity. His position is pre-supposing that a contextual reputation can be extended to any ontology and/or context. Because every context and ontology pair define differently what a “good behavior” contains, they will definitively lead to several different contextual reputations. Each of these reputations may be useful in their own context. Quickly reducing all these contextual reputations into a single manichean net-wide reputation is a little far fetched…

Technorati Tags: Identity, Trust, Digital reputation, Digital identity, Antecipate

Adresses as identity sub-attributes

In a communication space, an address is an identifier assigned to networks, nodes and other entities so that each entity can be separately designated to receive and reply to messages. An address is expressed in a given namespace, which defines a context in which an address makes sense. An address is unique in its own addressing namespace, but is not a globally unique identifier. For example, the address romeo@montague.net represents both the mail address and the JID of a user. This identifier is unique in the mail addressing namespace, as well as in the XMPP addressing space, but cannot be used as a global identifier. An address can be converted into an URI by adding a scheme, extending its unicity as an identifier. The conversion to URI enhance the address globality, but in contrast, removes its ability to route message. In a communication space, URI are static resource identifiers, whereas addresses posses dynamic routing capabilities.

Three of the most fundamental requirements of addressing are the ability to:

• Provide an abstraction layer capable of representing any actor or entity in a given communication space,
• Enable this representation to persist for periods of time during which it can be used to reach the resource it represents, and
• Enable this abstraction layer to be federated across any number of communication spaces.

To meet these requirements, we will follows the architectural principle of semantic abstraction in the communication space: separate non-persistent semantic identifiers (addresses) from persistent abstract unique identifiers(UIDs). In most digital naming systems, a name is resolved directly to the physical location of a resource: a file on a disk, a host machine on a network, a record in a database. In a communication space an address is normally resolved to an identifier, which in turn resolves to the network location of the entity or a node within it.

• UIDs are persistent values intended primarily for machine use. UIDs are permanent identifiers that can be either local or global in scope, but which never change once they are assigned to an entity. An UID is a URN, i.e., it may expire, but it may never be assigned to another entity. Likewise, if the entity is deleted from the system, the UID used to identify it is removed and never reused.
• Address handles are non-persistent addressing values intended primarily for message routing use. Address handles typically represent semantic relationships that can change as real-world entity names and relationships change, so they do not have the same persistence requirements as UIDs. Address handles naming is implemented as an attribute abstraction layer on top of UIDs. An address can be directly used in a communication space to route messages, but an address handle also resolves to an UID from which other address handles can be derived for other addressing namespaces.

In a multi protocol communication system, this definition helps define many address handles as attribute of UIDs, and thus provide an efficient address mapping service to the federation gateways. At any time, one of these gateways may query the mapping service to obtain address handles for the target communication space they bridge to. In this context, the UIDs need not be globally unique, as they are only meaningful in the particular communication space providing the mapping service. These UIDs may be created in an ad-hoc way, or may be derived from some identity management system. From a communication space stand point, there only role is to be a unique reference to an attribute registry of address handles. No other semantic is attached to UIDs for communication purposes, although they may possess semantics when derived from an "identity system". But these semantics have no meaning for the communication space, and are not needed to perform the routing of messages. In the end, UIDs may be attributes of an identity reference created for a specific “identity system”. In that case, address handles may at most be sub-attribute of this limited identity representation for the communication space.

Technorati Tags: XMPP, Jabber, Addressing, Identity, Digital identity, Trust, Antecipate

GUID, identity and addresses

I have enjoyed reading the paper on petname systems. It helped me understand why I had feeling of unease for some DNS based systems. I also liked the part on buddy lists based systems. I believe one of the inherent shortcomings of many buddy list systems comes with their mixing addressing and naming.

I find the petname system concept promising, and I am interested in its usability within an XMPP implementation. From an architecture view point, truly scalable distributed communication systems, and more specifically real-time messaging, usually implements an overlay network of some sort over the Internet. This overlay network leverages an homogeneous addressing space and uses the associated protocol routing logic to ensure message delivery. In this category we would find SIP or XMPP based systems, but also email systems. Buddy list based applications have been built on top of these communication systems. One major drawback of all theses implementations is the use of the system provided id as a nickname, this unique id being a routing address. For SIP the id is your URI, but this URI holds a routing semantic. For XMPP, the id is your JID, but the JID also holds a routing semantic. Same exactly applies for email. As a matter of fact, I have always felt using email address in certificates an oddity...

I am strongly convinced naming and addressing must be kept separate in any distributed communication systems. As a matter of fact, this issue is not found in the HTPP world, where URLs and identity are separate during a given authenticated transaction. URLs may be used as identifiers, such as these trustless URL redirects in recent user centric identity developments. They must not have to. In an HTTP based system, the relationship between URL and identity does not survive the transaction. On the contrary, for email, the address is the identifier, and the relationship becomes very long lasting... Temptation is great to use an email address as an identity, but this is wrong. This address is just another attribute of an individual identity. We all have several email addresses, and several IM handles, but our identity lies in our own essence. And our identity will definitively survive our changing email address.

If there was a single ubiquitous communication system with a universal addressing space, I would not be bothering. But I am sustaining the idea that global identifier schemes don’t scale. So does this post. I believe it has laid out sensible arguments in its demonstration, and its conclusions can be extended to other contexts, including communication. If we take this bad scalability of GUID schemes as a real world’s fact, I can conclude that the real world will ultimately be relying on a complex mesh of separate GUID schemes. If the relationship between naming and addressing remains so tight in each namespace, then building a multi protocol communication system becomes more complex and difficult. And then we have to interface different addressing spaces. This is the role of communication systems. What is a bounded communication worth?

In conclusion, I believe scalable and inter-operable communication systems must completely decouple their identity management from their addressing scheme. The identity management must be pluggable. The addressing scheme must only be used for routing, and no authorization or identity semantic should be attached to the address itself. This proper separation of concerns provides for a scalable approach to building multi-protocol communication systems. From this point, it is possible to design a system where address mapping becomes the simple result of a dictionary lookup.

Technorati Tags: XMPP, SIP, Jabber, Addressing, Security, Identity, Digital identity, Trust, Antecipate

Digital prejudices

As I was researching to get a better understanding of current thoughts about digital identity, I came across a post on digital reputations. I had thought of looking into digital reputation earlier after having seen the words cropping in the XMPP blogosphere lately. The first time I came across the wording, I had the distinct impression digital reputation was somewhat subjective. Reading this definition just confirmed my impression: to put it bluntly digital reputation is an everlasting prejudice.

By prejudice, I mean digital reputation contains a partiality that prevents objective consideration of an issue or situation, and digital reputation encourages coming to a judgment on a subject before learning where the preponderance of the evidence actually lies. On both accounts I find it difficult to accept. 

Reputations are both deep and complex at the same time, in one instance serving to amplify reality ("…she was larger than life.") and in another instance oversimplify it, ("…he’s amazing."). Reputations are not limited to people, but can and do apply to groups, organizations, companies, countries, governments and even objects.

I really agree with the opening statement. Reputation has a way to amplify reality, and to oversimplify it, which in my opinion makes it appropriate for “cave men” but not for responsible beings. I thus have some difficulties agreeing with many of the author statements that follow in the document. From my reading his post, I understand that a reputation based system offers a way for an individual to replace a responsible decision making by a gossip based decision making. I don't know if you are like me, but I do not feel comfortable with the idea of letting anybody influence the way I make a decision. A decision may and usually engage my responsibility, and as such must not be left to other to decide. I am also very weary of others "outsourcing" their decision making in this way because it is easier. Especially when it comes to my reputation...

Every single statement in the document reinforce the inaccurate nature of a reputation based system. For example

While a reputation can be thought of as distinct, separate and external to us all, they are inextricably linked to us, and don’t exist outside of the context of their owner for which they refer.

It is true that reputation is distinct for each of us, and is certainly external to us. So where does this statement inaccuracy lies? In the fact that reputation does not exist per say. It is a perception by a third party. Reputation is the resulting impression that has been conveyed to the recipient person through a chain of inaccurate communication messages between persons. Oral or written communication all conveys a degree of uncertainty. Experience and history show how inaccurate the transmission through a given set of individuals of any form of message can be. When these messages reach their destination in a context of partial knowledge and passive acceptance surprising, they may create surprising collateral results. Bad spirits were inhabiting the trees at night not long ago. Different behaviors were definitively the indubitable proof of witchcraft very recently. Different beliefs or convictions are still considered heresy today. Nations go to war on reputation!

We certainly need to "take digital reputation seriously", as the author declares. Applying binary and long-lasting memory to reputations will in no way change their "vague and subjective" nature. If reputation is by nature inaccurate, why would a machine, which is by nature so inferior to the human brain, be better at establishing what an individual is worth? The machine will certainly decrease the level of inaccuracy incurred during message transmission, but it will in no way be able to convey neither analyse the inherent complexity of the associated context. An I agree with the author statement that "our reputation is contextual and it is quite possible for me to have a positive reputation in one area of my life with individual A and a negative reputation in another area of my life with individual B". When coupling this with the long lasting nature of digital memory, a number of questions are surfacing. Very simple questions starting with but not limited to: what rules need be applied be to weighting the recorded facts in building a reputation? In which way can a positive fact balance a negative fact? What authority will mediate for inaccuracies? (add to the list at will)

Digital reputations are a way of denying the subject of the reputation the simple right to change and evolve. Everyone must be accountable for his/her actions, no doubt. But we have to be very careful not sticking simplistic "reputation" labels on individuals that would be used out of context. We have to be careful not to rely on delegated "reputation" impression when making a decision process. Because this is what prejudice is all about.

Speaking of reputation, I found it rather interesting to see the effect of long lasting memories in a more recent post of the same author. What struck me in the post is that it took so long to this otherwise reputated author to realize what he could be subjected to when going through French customs. What he is missing though, is that French customs are today equipped with powerful automatic brain scanners and that mirroring laptops hard-drives is not necessary anymore. Funny how people leverage fear factor to drive their business ;)

Technorati Tags: Identity, Trust, Digital reputation, Digital identity, Antecipate