Mike has clearly been doing some heavy thinking and his recent post on his Law of Relational Risk is evidence of that. Mike’s last idea in the piece caught my attention, the notion of Relational Continuity Sockets Layer. The idea is that:

It would allow multiple participants to interact on a channel that is secure for the duration of the relationship or at least one risk cycle (this means longer-lived sessions than SSL) and allows for relation IDs (similar to session IDs).

During his talk to day, Jim mentioned that as he began to write his book, his surveyed the existing identity literature and theory and found them extremely lacking. Fair enough. There really isn’t a lot out there on credentialing and identification. This triggered a thought/memory/realization. I’ve never quite understood why I like working in the identity space. The people are interesting, sure. The concepts are approachable and visceral… after all, identity management is about me: my stuff, what am I allowed to do, who is allowed to know what about me, etc. At the bottom of it, the problems of identity are fascinating to me. And in the instant I pondered Jim’s point that there was little identity literature, I realized that he might not have been looking in the right place. He probably didn’t expect that one of the greatest bodies of writing on identity lives in Scottish Literature. Years ago, I spent my junior year abroad at the University of Edinburgh. Scottish lit was part of my course work. Ian Campbell, Cairns Craig, and Alieen Christianson were my guides through everything from Redgaunlet to Mary Queen of Scots Got Her Head Chopped Off. Scottish writers have a strong tradition of approaching identity and duality issues. Three that books I read and highly recommend: • The Private Memoirs and Confessions of a Justified Sinner by James Hogg • Strange Case of Dr. Jekyll and Mr. Hyde by Robert Louis Stevenson • Lanark: A Life in Four Books by Alasdair Gray Each one is packed with identity fun. Identity fraud, identity theft (the real, metaphysical kind… wait, can something be real and metaphysical?), self-asserted credentials, and more. Ok, I grant you that none of those titles cover strong multi-factor identification, federation, URL-based identity and the like, but they do make for a great read. And if it ever gets cold around here again, I’ll definitely be picking one of them back up for some fireside reading.

While Washington, DC may not have a lot of companies working on identity technologies, it certainly has a lot of bright people working on identity policies. This afternoon I got to hear one them, Jim Harper, speak about his research into identity and identification and his subsequent book, Identity Crisis: How Identification Is Overused and Misunderstood. If you haven’t read it yet, do so. It is an approachable survey of identity management and identification issues facing the U.S., set in the context of the REAL ID Act. (The short blurb I gave my mother-in-law about the book was enough to get it into her reading stack.) This wasn’t the first time I had the opportunity to hear Jim; Phil roped him into giving a keynote at Digital ID World last year. There were two items I took away from his talk. First, Jim has an excellent analogy on how we protect physical assets versus how we “protect” electronic financial data. How many keys do you have in your pocket or purse? I’d wager it’s probably more than three. I’m also confident that you have a bunch more keys at home in the drawer somewhere. Each key matches up to an important physical asset: an apartment, a bike, a car, a safe, etc. In fact, you may even use multiple different keys to secure the same physical asset. Although convenient, I don’t think anyone would use the same key for every asset they own; just the idea of it seems somehow unsettling. Jim makes the point, if people don’t use a single key for securing their physical assets, how come we have (or are coming dangerously close to) using a single key, social security number, for “securing” all of our financial data? Second, the point that credentialing, or authorizing, is just as important as identifying. At a point-of-sale terminal, merchants are primarily interested in can you pay, not who you are. Knowing that you are allowed to travel, but hiding who is doing the traveling. This smacks of both Dick’s Identity 2.0 talk and Bob’s talk on the Identity Oracle from last year’s Catalyst. The question was raised what are the real opportunities that people have to opt-out of large scale identification. In reality, it is hard to opt-out of being identified and continue to fully function in society. There is a glimmer of hope in stronger identification systems allowing citizens more choice as what is needed to identify them. This sits somewhere between Kim’s Law of Minimal Disclosure and the Identity Governance Framework. All in all, it was great to hear Jim speak and heartening to find parallels between identity policy and identity technology. I am concerned that too many bright identity minds are wrapped up in “enterprise” projects and have lost a bit of the wider societal view of the implications and impact of their work

Continuing on Andre’s thoughts that there are more identities coming from the Internet than from internal networks… The challenge for the enterprise is managing this vastly larger population without overrunning the systems and services currently in place. The problem is one of identity capacitance; how many identities can the company manage and how many identity services can it offer? A company, can manage its 10,000 employees and their identity-related needs, and it can do this within budget and operational constraints. The systems that it employs to do so gives the company an identity capacitance of X. Using federation tools, the company can raise its identity capacitance to 100X. But the total numbers of identities out there is far far greater than that. To address this, the company has to increase its identity capacitance, but it can’t and still stay within budget and operational constraints. Enter Identity Service Providers. With theoretically infinite identity capacitance, the provider can let the company sanely managed the oceans of identities out their while providing all the qualities of services that customers expect. Questions I don’t have answers to: Is an identity service provider different than an identity provider? Do they compete with each other? Are they opposite sides of the same coin?

Andre over at Ping Identity has clearly been doing some heavy thinking. First, he connects internet-scale security and the continuing death of the firewall. Then, he raises the point that there are more identities outside the enterprise than within. The implication is that those external (Internet-based) identities are of real value to the enterprise; they are partners and customers. These external identities need to be “secured and tracked.” Two questions come to mind. First, do both populations require the same kind of identity management and services? At issue here is context. The context of a customer or partner is different from an employee. Yes, they may need similar identity services, but the manner in which they consume those services is context driven. This may lead to different sets of identity services, which must be centrally orchestrated and audited. Second, is the application tier really the best place to tackle these problems? I think the two different populations require different approaches. Companies needs to tackle inside identities from the network layer up. Why? Because people on the inside have greater access to the soft fleshy underbelly of the business. Even the most well intended employee can inadvertently cause damage once he’s on the enterprise network. Meanwhile, outside identities should be dealt with at the application tier as that is their access path to corporate systems.

This week, I spoke at the International Information Integrity Institute’s Forum in Dallas. The I4 is an interesting bunch. This member’s only event brings infosec practitioners from around the world to swap war stories and hear about new trends. I was blown away by the attendees and the raw frank nature that they discussed their issues. “Sox sucks.” That was the gist of what one attendee said to me. She outlined the myriad of hoops she has had to go through dealing with SOX. Behind her frustrations was an implied question shared by many attendees - “When will we be done?” When it comes to regulatory pressure, sadly, there is an inverse relationship between how tightly written the regulation is and how long it will take to be compliant. The tighter the reg, the less time it will take, and vice versa. PCI is fairly tight, whereas SOX (and its interpretations) are pretty loose when it comes to IT. When it comes to major IdM projects, they often get presented to the enterprise like a decree from the Kremlin: “Good news, Comrades! We have a five year plan for achieving compliance through user provisioning. We shall be victorious.” The reality is that it really may take five years, but there’s no way you’ll sell upper management going that route. Successful projects use guerrilla tactics; find a small target, plan thoroughly, achieve the goal, move on to the next one. You can make the big five year plan work by stringing small victories together to achieve the end goal. Unfortunately, in this litigious world, getting to “done-ness” is getting and harder. The good news is - every small victory and all the steps we take along the way make the business better.

Phil has released his fourth Identity Fallacy - Identity is Monolithic. After reading it, I could almost hear the choir of meta and virtual directory companies rise up in praise. This what they have been really been talking about all these years, but often times lacked the distance from the problem to express it out so clearly. To continue his train of thought, if I may, although identity is not monolithic, our perception is our identity is monolithic. There is one me. I may have many contexts in which I work, live, play, and shop, but at the bottom of it, that is still me. This mindset is getting people out there in trouble. You keep track of your various bits out there. You do not have all that data on your computer or phone, but you have a bunch of it. Applications like Keychain on the Mac help aid your memory by providing pointers to other bits of you. You keep track of things that aren’t immediately recognizable as you, such as your characters in MMORPGs and your alter ego on MySpace where profess to be a lot more interesting than you really are. (See Mark’s musings on that one.) Essentially, you act as a powerful virtual directory for things that you perceive as owning. You own your account on your home computer. You own your wallet with your driver’s license in it. These are all pieces of your “monolithic” facade of identity. By definition, your identity cannot be monolithic as it is comprised of all these little bits that you are tracking. But, we still like to think of the notion of the singular me. (What could be interesting to research is if people with a polytheistic set of beliefs hold the same notion of singular self as those with a monotheistic set.) In fact, the belief that you own the various components of your overall identity edifice is what gets people in trouble. You think you own your account on the corporate email system, and thus you track it in your virtual directory. If you haven’t realized by now, you do not own that identity. VPN account. No. RACF id. Absolutely not. Though you don’t own these things, you still track them as if they were really part of you. Seems fair - you do use them frequently. You typically use them in a work environment and people, to varying degrees, associate work and self. Keep in mind those are not things that you own, merely things you use. It gets worse. Much worse. There is a whole category of things out there that you don’t, and often times cannot, track: data about you. Credit records. Insurance information. This is all the good stuff that gets copied and reused; the activities that fall under the header of identity theft. (I wince when I hear people talk about having your identity stolen. The metaphysical implications are staggering.) There is so much out there that you and I don’t track; it is truly astonishing. No one would confuse my identity for a record in a police database saying that my car was parked on Main St at 10:05 AM last Tuesday, but these days, the two are more and more equivalent. Revel in the fact that you are such a good virtual directory. Okay, you may not blow the doors of a benchmark, but you hang with the best of them. Just keep reminding yourself that a) you may not own as much of “you” as you think and b) your identity isn’t monolithic. I’m off to Catalyst; see you there.

Yesterday it was announced that Service Provisioning Markup Language (SPML) version 2.0 was ratified by OASIS. This warms my heart for two reasons. First, it is great to see the work of so many people come to fruition. Gary, Jeff, and Gavenraj really drove things forward and put in an amazing amount of effort. (On a personal note, since this was the first standard I worked on, I get a kick out of seeing my name as a contributor.) Second, SPMLv2 brings user provisioning into line with access management, in terms of having standards to work with. This was a topic Phil and I discussed in our webinar. Now the provisioning market has a rich, usable standard to help drive implementations and integrations. SPMLv2 gives application vendors a way of making their applications easily provisioned. It gives provisioning vendors a way of quickly integrating and connecting to applications. Everyone wins. Are we there yet? Has the identity management arrived at its final destination? Nope, but we are getting closer. In order to realize its full potential, large application vendors have to adopt SPML. SAP and Citrix have done so. Oracle and Microsoft cannot, I hope, be far behind. By having SPML-based hooks in major applications a lot of the grunt work of connecting provisioning engines to target systems is removed. It decreases the time to value in user provisioning implementations. It allows project teams to focus on policy and process and not how to connect provisioning engines to systems. Assuming that large application vendors build SPML gateways in their applications, are we there yet? Still, the answer is no. There are a ton of older applications out there. Though I can see SPML gateways for RACF and ACF2, its harder to imagine development teams building SPML hooks for their bespoke applications. If database vendors built SPML parsers into their engines, then homegrown applications could be in better shape… but I don’t see that happening any time soon. In other news, Virsa was gobbled up by SAP. I don’t think this comes as a big shock to anyone in the industry. I wonder if it doesn’t mark the beginning of SAP’s entrance into the identity management market. First, major SPML support. Now, Virsa. What’s next for our friends at SAP… a provisioning system? They have got to be feeling pressure from OraclePeopleSoftJDEdwardsOblixThor. Tags: identity, IdM, identitymanagement, spml

Once our service provider worked out all the kinks, Phil Becker at Digital ID World and I finally got to record our chat about identity management as a project versus as a lifestyle. There were three major points I took from Phil. Managing the Project Phil and I both had agreed that managing your identity project, regardless of technology, is critical. This requires an understanding on all parts: vendor, implementer, and customer. Biting off less than you can chew is the way to go. Further, regardless of technology: access management, password management, user provisioning, etc., you can find quick wins that show real value. I know this sounds like basic project management, and it is, but it is vitally important in identity management. Policy Phil and I spent time talking about linking business and identity policy systems and integrating policy engines. Correlating business policy and procedure down to identity management systems is a tough job. Often, it is done by a few individuals who tackle it in their spare time. Tighter integration is needed. However, this requires system to system communication and policy interpretation and this is quite difficult. Furthermore, there has been little work in the vendor community to express policies in a neutral language let alone the transport and transformation of said policy. Standards As federation matures, I think we will see more intra-company federations (obviously) and more inter-company federations. Lines of business will wrestle back some freedoms lost in centralization. This will lead to richer policy and provisioning integrations that require richer languages. SPML version 2 is a much needed addition to the tools we have to work with, but its adoption is slow. XRI/XDI is another set of promising work. Final Thought By having frank and open discussion between vendors, customers, and implementers, we can chart the course of identity management. As customers deployments have matured, they have pulled vendors along with them. By working through real-world use cases we, as vendors, can truly tackle customer needs. Recommended Reading If you haven’t read any David Foster Wallace, check him out. If science fiction is not your speed, take a look at the book that inspired the title of this blog: A Supposedly Fun Thing I’ll Never Do Again. Here’s the link to the slides in pdf form… of course, you don’t get my and Phil’s witty banter. Here’s the recording of Phil and I talking… witty banter included. (Be forewarned our provider only supports IE.) Tags: identity, IdM, identitymanagement

As always Bob has an interesting post out there. Taking up the issue of authentication, he issues this challenge:

“I believe that this community should commit itself to achieving the goal, before this decade is out, of providing every computer user with a strong authentication device and the infrastructure required for its universal acceptance.”

The post started my mental wheels turning. I 100% agree with Bob that current state of affairs for user authentication is unacceptable. He provides some great guiding points on what a better authentication system should look like. He says: