With the Internet Identity Workshop not far away, Alec Muffett writes of his distaste for parts of the current state of the Identity space. Hallelujah. I’ve been wanting to write this for a long time… now seems like as good a time as any to add my thoughts.

My takeaway of the moment is his advocating utilizing an entities(user/vendor) transaction history system as the authoritative trust and risk assessment mechanism. This isn’t new thinking, banks do this all the time. The problem however with the current identity space, is that to do this requires reliably storing *any* entities transaction history - which requires silo-free persistence, redundancy and management on all sides of the transaction in order to verify those claims. We don’t even have that silo-free persistence or redundancy yet - nor do we have the tools to manage our data that’s online and always available. Until we do, all this Identity talk has been bunk to me. Why I see it vital to be addressing this problem first.

He talks about relationships, links; they all require persistence or self-healing(think AI) in order to operate reliably as a system. Break one and any number of reliant services break unless caching is implied on the part of the relationship contract, or a human is there to fix every failure. It would be like losing your birth certificate, and having to go through the motions to restore your identity history to a verifiable 100 points before you could verify who you are in order to open a bank account, or create new relationships in the real world.

Now there are those I see aimed at fixing related networking architecture problems that partly solve persistence and redundancy: Van Jacobson’s Content-centric networking comes to mind, heavily laden with it’s key management system which has complexity drawbacks. Most of the other attempts out there however are all HTTP and REST-like based. One problem I see here is that we have network architecture not designed for todays identity, and one that criminals exploit at their own discretion with so many points of failure in the network that policing is near impossible. So how do you secure those routers and wireless networks your valuable personal private data traverses? You can’t. How can you be sure the chipset inside network devices hasn’t been tampered with by organised crime or opposing governments? You can’t. Or your personal network device? You can’t unless you can verify your device hasn’t been tampered with to the best of the manufacturers ability by checking an objects signature of operation with them /over time/. On the network side, only by signing and securing the data or hiding it completely can you get some peace of mind. Peace of mind with the knowledge that over time, that security will need to increase computational power as attacks do. There are already ISPs injecting information into web pages as they traverse networks, their proxies being easy targets for anyone wanting to be malicious. How do you make sure the data you ask for is the data you get? You can cryptographically sign it, or as many sites do now; open a ’secure’ pipe; HTTP SSL. A secure pipe over a network that could have hardware that’s been tampered with? That doesn’t seem very smart to me. What if you sign *all* the data? Then the points of failure become the crypto, end points, users, devices and the key management systems. What’s important however is knowing you get what you ask for, from who you ask for it from - efficiently such that such a system can scale. Problem is cryptographically signing and hash collisions mean you might not get what you asked for, instead a virus that goes undetected… which means we still need malicious software detection - virus scanners, etc - to monitor for malicious intent, checking packet signatures and detecting anomalies that slip through indicating the need to increase security. However, should malicious content breach a system, the best way to prevent that from causing untold damages, is by limiting what objects can do in a system - at all levels of the system.

Doing this presents still to solve issues on the end-points and user side in order to limit the social engineering of those wanting to be malicious. This has to be done by a means of focusing on user experience, education, and the interface by limiting damage and providing a support network for users should it occur. URI or email namespace, and HTTP resource handling as the interface are the real stumbling blocks here when it comes to adoption via user experience. You only need look at the Twitter namespace to see what’s possible otherwise, people often making requests for help to people they learn to trust as field experts over time - despite it’s inability to handle threaded verifiable transactions; something that could easily be added. Mobile and cross-platform devices really /are/ the future of transactions. What’s important about Twitter is that it’s /opt-in/. Capturing malicious claims openly in a persistent way can mean reputation based upon a persons history can become a reliable risk assessment tool. Don’t let the bad people in by default to access everything about you. Layers or capabilities are the key. There are also means that can make transactions between untrusted parties safer. Escrow and transaction risk assessment with repudiation should transactions go wrong being one - so long as the escrow is a trusted party of both parties…

With regard to those three equal parties Alec mentions participating in a transaction (user/vendor/IdP) - I agree that the third is not needed once relationships are in operation. I break the three down to one ‘component’ performing different functions as in a peer-to-peer or end-to-end network - which is one of the original IP protocol design goals[Bring on IPv6! (and a scalable replacement)]. However, most of the time it’s easier for people to conceptualize two(user/vendor or client/server), with the third managing relationships(the connector) - not storing anything - and instead delegating capabilities. I say this because in any classical network, there are three basic elements: Components, connectors and the data that traverses connectors between components. My problem with many existing Identity efforts, is the term Identity Provider or the ‘middle man’ aka single connector; as they just add a silo of failure. In my mind these must be replaced with what I call Relationship Managers. While the network itself is the ‘provider’; that being the hosts you choose - or preferably the network chooses for you by locality - to replicate and distribute your data redundantly between. All accomplished via Relationship Managers that I consider analogous to the VRM Control Panel I’ve seen Doc Searls advocate. Those Managers themselves able to delegate to other Managers such that authenticating an identity from multiple points of contact is possible. Important for redundancy and the ‘object capabilities’ security model: As multiple, yet strictly authorized devices for authentication via those Managers, is then possible on a per device/capabilities basis. Revoke one device(or Manager), still use another. A layered failure approach. A process no different than getting a new credit card(or bank). These Relationship Managers will need to be able to delegate auditing like a ‘Hawk’ monitoring a person’s transactions in order to detect anomalies. Something that could be done in-house by users or outsourced; Identity Brokers doing that management - just like we do now with virus scanners. This important persistent transactional data can then be used to tailor services to a persons user experience ala VRM. Everything can be packaged with the user in or out of control then, home-grown or outsourced; user-driven.

Whatever. Until decentralized data persistence, redundancy, namespace, and relationship management tools are here, it’s all bunk. There’s also another major part of the process yet solved; authentication. The current authentication arena makes me cringe. While I consider CardSpace one of the best of the bunch, it fails to follow the transaction history verification regime to learn and detect anomalies in operation, a process I consider important and could be layered on top over time. Key producing - dynamic, personal, biometric authentication learning systems that throw away the biometric data. In other words AI and unique object detection. Captcha’s are failing, it’s becoming increasingly more important to be able to detect that a human is really a human and differentiate them from other humans… something I believe can be done with multiple time varying history challenges, systems that learn like we do, if narrowly and task-centric at first. Recording passphrase fingerprints is an example of a step in the right direction. Still, like any other security measure it’s a moving balancing act, so I see CardSpace-like tools as a useful beginning in a layered object capabilities approach.

Still, with all these areas yet addressed and many neglected by what I see from the outside looking in on the Identity World: I still think we have a long way to go to when it comes to the ‘online’ world moving towards a service that lives up to it’s name before Alec’s hankering will subside for another that follows.

Jon Udell discusses the idea that technical mastery requires social innovation. While I agree in general I don’t necessarily agree with his final statement that major innovation would require more social than technical. I just don’t believe you can separate the two cleanly yet. It’s still all about how you compose the data with the view(s) and technically I still see a lot of problems in information architecture today that needs solving.

Recent talk by Dave Winer and Tim Bray on what happens to your data and records when you die are the classic example. Data is spattered everywhere, yet there’s a technical solution to that, one that requires a social element as well. I say this as I’m attempting to create my own environment for historical data and innovation. So while the social hurdles are first and foremost in my mind - my user-facing API is defined by that - actually architecting what I consider important elements to achieve my goals, is trying technically. Sure if you have a lot of man hours of a big company it may well be simple to implement but conceptualizing how exactly to implement an entire environment with innovative paradigms, requires a lot of forethought. Usually by one BDFL slaving over that while guiding others to help implement that. eg. Tim Berners-Lee, Guido van Rossum. There’s an excellent talk Fred Brooks gave at OOSPLA07 that talks about innovation I’d highly recommend listening to.

Where Jon asks whether operations are beyond the capabilities of mainstream users I begin to envision a much simpler and more direct approach to how people interact with objects in a system. I always recall a mainstream user testing a web site I’d designed. The number one interaction she responded to - one that guided her into learning new capabilities - happen to be the direct object interactions. Popup’s on hovering menu’s, self-explanatory animated transitions on acting etc, all of these were at the point of object contact. It taught me how important it is to see and learn how to interact with each component and how those can effect others. More importantly how the system integrates and functions to get tasks done. Jon’s screencasts, the CoScripter example, they exemplify this.

I remember my first steps playing with the Self programming language desktop GUI. The ability to inspect objects was fantastic even though the overall user experience was awkward. I think we need more of this interaction if users are to learn new capabilities. Interfaces simply must be object accessible.

Applications today just aren’t built with this in mind and I think the problem is one of default functionality. By default 99% of systems don’t guide people as they use them. There is so little by way of best practices and the advantages they afford because more often than not it’s educated developers doing the implementation.

I think the only way to solve this is to give users the tools do the implementation and customization themselves by lowering the barrier to entry through an object accessible interface. Community driven applications modifiable at the object level comes to mind. Wikipedia is a good example at making information more accessible to the masses, Twine a level up. Why not do the same for application development? The Linden Labs guys also talked at OOPSLA07 that is worth listening to. A large number of scripts were developed by people with little previous programming skill because they could grasp basic constraints to the interface and architecture. If we can create an interface to do this and get tasks done while the hard technical aspects are hidden; great! But technically I don’t believe we’re there yet on a distributed level nor social. The two problems are just too similar.

It’s really one distributed problem over two different mediums.

I couldn’t leave without linking to an interactive application example The Neuron.