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.
