Catalyst Epiphany #1

I have an ugly confession to make.  I watched the rise of compliance as a business driver for Identity Management, and was pleased but not particularly interested in what it was that suddenly opened the budgetary gates for the projects I was part of.

When I thought of compliance, I would briefly consider how I was helping executives sign little pieces of paper that kept them out of hot water with the auditors, and then I would go back to thinking about organizational efficiency, process for the sake of bringing order to chaos.  It’s easy to say that compliance is important, without ever understanding why it is so.

This is before I saw Nick Leeson speak at this year’s Catalyst conference.

You can’t listen to Nick’s story without your jaw dropping.  Nick was the trader who caused the collapse of the Barings Merchant Bank in 1995.  He was able to do what he did, because he could control every single piece of information that might have led to his discovery.  His superiors didn’t understand the business, and therefore could only take Nick’s word for everything.  Same went for his auditors.   The resulting business failure was unimaginable.

Sitting in the room, listening with disbelief and amazement to this story, everything clicked for me.  Everything I do and recommend in the Enterprise Identity world is applicable to this one story.

There are two things that happen in a provisioning project that make a compliance difference I had never considered before:

  1. We create observability in systems beyond the control of the asset owner.
  2. We create referential integrity for systems such that account activity does not occur in a vacuum.

The goal is not necessarily to catch bad guys here.  The goal is to ensure that nobody can take an action and also hide that action.  When every account has to resolve to a real person in the Enterprise, and any account created that doesn’t do so shows up on an audit report without the system owner having any say in the matter – well that makes a difference.  When the reports and summaries that are generated happen out of the control of those who might wish to change the data within – it makes a difference.

And when the executive sponsorship of an Identity Management program are truly behind a project such as provisioning, and ensure that the project stays on target and that at the end,  the compliance targets match & reflect the BUSINESS (a feat that no IdM consultant can know for sure they have accomplished) — it makes a difference.

I’m not sure that I’ve expressed this well — but I can tell you that I will do my job differently from now on.  From now on, when I talk about compliance, I will not be thinking of making the lives of the CxO’s easier and/or more worry-free.  I will be thinking about how I can make sure that if there is a cause to worry, it will cross the desk of the person who can recognize it and act on it.  It is a small difference, but a critical one.

The wrong way to go about it

As a result of a bit too much time spent watching American TV in hotel rooms this month, I decided to check out the URL of an interesting product. The BenderBall is a little tiny thing that I’m convinced would be perfect for trying to keep in shape at the cabin.

At this point — I have generally decided I want the product. I’ve remembered the URL. I’ve visited the site on the web. I’ve clicked the “Update Cart” button. I’m not a big “shopper” so to get me to this point is a rare occurrence. Suddenly I’m presented with the payment page, and I see the one thing that GUARANTEES I will not buy the product:

So Very Wrong

To force me to subscribe to the “special offer” list in order to get a Shipping Confirmation is unacceptable, and I will not pay $$ to a company who attempts to coerce me into doing so.

Yes, this company has a product I want, but the barrier to pulling out that credit card is already high, and now they have blown my trust of their business practices. I’m already suspicious of infomercial sites to begin with.

I would however, buy this product through either a bricks & mortar establishment, or through a trusted provider such as Amazon. Why? Because I can do so without putting as much of my data into the sleazy vendor’s hands.

I guess my abs will just have to stay flabby.  :)

Real Life Personal Privacy Policy

I’m sitting in the Data Sharing Summit after a conversation about what can go wrong with data portability, all full of wonderment and questions — I figure I’ll blog my heart out while I can still embrace my current simplistic view of this area :)

I feel a huge sense of dissatisfaction when I listen to application developers talking about privacy. They talk about how a given person can create a view of themselves that can be consumed by an application – but the vocabulary they use reminds me of assembly programming. Of course, the folks who write the specs and the folks who implement those specs must understand this level of granularity – but can’t there be something more palatable put in front of the users?

Every person who interacts with another makes a personal risk assessment about the action they are about to take. At the very beginning, all you can really do is look at the very superficial things that people advertise about themselves, and interpret those things within the context of the current community. In real life, this means that initiating a conversation on heavy metal with a person wearing a Metallica t-shirt is probably not risky within most contexts. In the same way, you might choose to confidently drop a literary reference in a conversation with a person who has a copy of ‘The Master & Margarita’ in his hand.

This is theoretically analogous with online entities like interest groups within social networks, it gives fellow users a chance to make initial guesses on the type of person they are dealing with. But I have to ask — why is it that we have nice warm fuzzy interfaces for users to express their preferences, affiliations, personal views and all sorts of context such that other people can synthesize a gestalt of a person and make a risk assessment, but the application can do no such thing?

What about allowing a user to choose a set of simple, private parameters that represent a very coarse-grained view of how that user might wish to be treated by the application? If I tell Linkedin that I want to be treated like a quiet, conservative, privacy-concerned person who keeps to themselves, I think that LinkedIn can guess how I would feel about my data being exported. If I wanted LinkedIn to treat me slightly less stereotypically in some circumstances, I should be able to dive into the assembly language and tweak things – but I’ll bet most people would be fine with broad strokes as a starting point.

Alternatively, perhaps I tell Facebook that I’m an extrovert with a great sense of humor who loves to connect but who is concerned about how photos with me as the subject are published to the world. Again, I think there are interpretations that can be made with respect to the boundaries that this user wishes to set.

Would this perfectly work every time? Certainly not. But neither does the real world model. At least maybe this could be a way to mitigate the fact that the social graph with respect to data portability/privacy is in fact an interconnected set of multi-dimensional matrices that represents the mother of all provisioning problems – every person dealing with every attribute of every relationship within every community they are a part of, and now also between many of the communities they are part of.

Here is what I envision. Imagine a very small number of possible attributes to describe a person’s privacy tolerance, that are displayed as part of your account settings. My guess is, if you see a descriptive word in your account that is the default, but doesn’t describe you, you will go and change it (rather than just ignoring a wall of possible privacy settings that doesn’t give you any interpretation of the implications). Perhaps to be more visual, you could set up an equalizer at the bottom of the page representing different ranges of tolerance for various uses of data, that users can set with one button click by using a preset and then fine tune if needed.

Hm, I wonder what the privacy version of the “stadium” preset would be? :)

Herds & Communities

Last week was a humbling and empowering week. RSA 2008 has given me a good kick in the pants in a number of ways, all of which have inspired and challenged me to think on things I’d never contemplated before.

Quite a few people at RSA wanted to know the “how” of user-centric technologies, yet the biggest question was undeniably “why”? Why would I implement this new technology? Why is OpenID or Information Cards or ID-WSF or anything else truly better than what has gone before?

One thing I truly believe is that we are not building these technologies in order to blindly replace one identity mechanism with a different identity mechanism; the cost & extra complexity associated just wouldn’t compute. There has to be a tangible step forward – not just mysterious head-nodding between experts.

On Shoulders of GiantsWe talk at length about improvements in security, privacy and a million other things – but all of those things are just window dressing on the fundamental paradigm shift that we rarely address. I think we all need to work to create widespread understanding of the reasons why society should care about to whom they authenticate. The answer to such a question can be evaluated independently of the technologies involved — so for the rest of this conversation, you can and should dismiss the technical details. Instead, imagine a world where various identity technologies are available, well constructed and tested, and where a decision to adopt is a simple configuration decision, not a coding adventure or a proof-of-concept. Yes, I know we aren’t anywhere near that yet — but for a minute, let’s step away from the trees and look past to the prosperous village on the other side of the forest.

If I were to give a name to the vision I have of the future, it would be “federated community”. Users sign up for a community, based on some common interest and returned value, and are then able to leverage their identity where they choose, in areas where the context of that identity somehow enriches their web experience. You may say wait! We have this already! Yahoo! is a community, Google is a community, AOL is a community. No, they are not. The YGA crowd are ranchers with herds of cattle. Flickr was a community which was merged into a herd, much to the dismay of the community members. There were obvious plusses and minuses to the merger – but I think it is reasonable to note the anger and consternation that users felt when their community specific identities were force-merged into generic herd identities. These days, companies like Google and Yahoo! can be said to “own” users in the same way that the telcos could have been said to “own” users prior to cell phone portability. This silo-based mentality is a dying business model, and the big guys know it – what will replace it?. This is the BIG CHANGE that we never talk about.

We have already come a long way towards federated community. People want their identities to cross site boundaries, they want to link their output from many sites together into one or more collections — as long as they retain control. The problem is — how to link? Most smaller sites are walled in completely, while the herds get around this by creating massive silo-only service offerings – every herd has photo sharing. groups. email. Yet one herd can’t use the other herd’s service. It’s a big turf war, and if you have friends in every herd, you end up managing accounts in every silo. Of course, if you’re a big site that wants to federate with the herd, you can use their APIs – but there is an API for every herd, and no standard API for the smaller communities at all (the oAuth and OpenSocial guys might disagree here, they seem to be fighting for the same things, just with different weapons). For now though, imagine that herds & communities alike become Identity Providers, and that sites wishing to interact with herds & communities become Relying Parties.

Once the tech is stable and ubiquitous, Identity Providers will provide authentication services as a byproduct, not a goal, and there will be a major and a minor arcana of Identity Provision services that evolve. In order to join the major arcana of Identity Providers in my future world, the provider will need to own some piece of information that many people & sites will want to consume. This is not data that once given is never necessary again (such as your name & email address or other personal data) – it is living data that consumers will want to come back to again and again, the kinds of data that our economy thrives on already **.

In my future world then, the major arcana of Identity Providers will be, for example, Slashdot. Second Life. Equifax. Amazon. Ebay. These types of business can prosper, not from serving your data, but from serving out interpretations of your data — interpretations that are cooked up with a secret sauce that ensures the continuity of the business model. Consumers will be the sites who want to work within that world. Imagine a network of sites that you can visit & take your slashdot karma with you. The user has the advantage of seeing a reputation they have worked hard to achieve gain more credibility. The site owners participating in this network reduce barriers to entry to their own site because users don’t need to rebuild reputations. Site owners also have a way to filter spammers and trolls. Slashdot becomes the hub and reaps the advantages of owning the secret sauce recipe that everyone wants. It is entirely possible that consumer sites then begin contributing back to Slashdot, and we now have an ecosystem. This is the kind of thriving inter-site community that becomes possible when data is shared. I also hope that this era will usher in the return of the pseudonym, a lovely and important part of the internet that is currently taking a beating from snotty, literal-minded “real people only” social networking sites.

The minor arcana of Identity Providers are what I’ll call “Membership Providers”. They are the smaller groups that you join because they are your peeps. Sports clubs. Church groups. Families. Hobby Clubs. Toastmasters. These are the kinds of Identity Providers who may not have much in the way of secret sauce, but whose users will join anyway – not because they expect to use their membership in a million places, but because they feel an affinity, and because it feels good to have affiliations. These kinds of associations don’t *have* to make their own provider, but I think that many will if the software makes it easy — imagine hosted Identity Provisioning Services instantiated in a button-click; Integration of Identity Provision Services into accounting software for management of membership dues, into web advertising components for reciprocal deals between memberships and businesses, then imagine federated relationships between various affiliations that might be linked to a parent organization, so that by becoming a member of the Alberta Motor Association, you get ancilliary benefits at sites where deals have been negotiated by the Canadian Motor Association.

Now – for all this, where does this leave the user? Why should the user care whether they are part of a herd or a community? I don’t think they will care at the beginning. I think they will do whatever they have to do in order to get whatever good or service is their goal – however, once their identity is (a) portable and (b) meaningful in additional useful contexts, I believe that the loyalty equation changes for the better, and that as a result, marketing strategies and business models will evolve too.

This is the kind of world that I see evolving as a result of and a reason for the technology we are working on. OrganicIt is a lot of work to change this kind of plumbing, and who knows what actual technology incarnation or combination thereof will get us there — No matter what happens, the current approach where everybody spends programming time linking into every mothership via API in order to add value will not cut it. We need a way for communities to form and flourish and decay that is organic. To that end, if you were to ask me what the vision is for any technology that follows the Identity Provider paradigm, I would say that the “why” is so that we can make a system where communities can interact, transact, and relate to each other without the tech getting in the way. This is the ultimate end goal for me – if I didn’t believe that we can build a much better house, I certainly wouldn’t spend so much time perfecting the engineering on a radically new foundation.

If you think that my vision of the future is a big fat load of bollocks, feel free to poke holes, I’m sure there are many — all I ask is that in addition to making fun of my thoughts for the future, you provide your own, alternative vision, so that we as an industry can communicate these various viewpoints to the people who just want to know why.

**: See Bob Blakley’s “Identity Oracle” writings to see how I stand on the shoulders of giants in much of what I say here.

Alrighty then – let’s talk roles.

In my post on user context decisions in the Enterprise, I built on a foundation that perhaps should have been better defined before drawing conclusions. A few people noticed it, and I think they make great points — so let’s step away from the fancy schmancy terms and look at [my conception of] the underlying issue.

Here is my problem with current technical definitions/applications of roles. In most organization, roles are expected to be true of a given person 100% of the time. Jenny is *always* a “production accountant level II” if that role is present in her profile.

Roles are indeed in the domain of the “identity weenie” — but alone, roles are nothing but a maintenance nightmare – they exist to be leveraged. Rules on the other hand, are the problem of the “authorization weenie” and are written (for example) as a WAM policy that says “All Production Accountant Level II resources can access the accounting SharePoint instance”. When you collect roles into a profile and collect rules into a policy and then evaluate for a given user, resource, and point in time, what you eventually get is an entitlement, ie “Jenny should get into the accounting SharePoint instance”. The goal is to have transitive logic between roles and rules, such that two different people can take on the two different statements being made. Jenny’s Manager can authoritatively state (through a workflow approval) that Jenny is indeed a production accountant. The owner of the Accounting Sharepoint instance can authoritatively state (through an authorization policy) that all production accountants should have access to their site.

This is, of course, just my interpretation of the verbage. Heaven knows there are many many other interpretations out there, I could be waay behind the times. Still, the basic logic I’ve just outlined forms (I believe) a simplistic basis for most identity projects out there. All of it is based on the idea that whatever set of roles are present for a given account at a given time are all simultaneously true.

What happens when the system detects the static presence of two conflicting roles? What happens if one role is “truer” than another at some point in time?

There is no simple way to say that John is a broker 100% of the time, but 50% of the time he represents Client A and only Client A, and the other 50% he solely represents Client B. There is no way to represent mutual exclusivity of roles in a single user profile (that I’m aware of).

In the case where two roles are assigned to the same person, but should never be simultaneously applicable, Enterprises have limited choices. If, however, there is a layer in between the consumer and the provider that lets you mask roles based on user-chosen context, in my mind this problem goes away. I don’t see how you can do it without the user part — but perhaps I’m just not thinking hard enough :)

I hope I’ve now managed to dig myself in sufficiently deep that pretty well anyone will be able to take potshots — have fun :)

Dear Enterprise Application Vendors:

I believe we’ve hit a crossroads, my friends. Here’s what’s happening. We have a groundswell of support and interest in technologies that reduce the need for passwords in the Enterprise. Some of these technologies have been around awhile. Some of them are new. All of them want to integrate with YOU, the Enterprise Application. Action is necessary in the immediate future.

In talking to your fellow vendors, I can almost feel the panic – you can’t possibly support all of the new technologies coming out, you aren’t even supporting technologies that are years old — how do you choose?

My advice is not to put money into one-off integrations — but instead to work to abstract the authentication/identification details from your core application code altogether. Now is the time to make those architectural changes, and to do so as a result of strategic vision rather than a frenzied response to a line item in a critical customer RFP.

No matter what technology rises or falls, flexibility in authentication methods will become a key differentiator in the next 5-10 years for Enterprise applications. Prior to this, the applications have pre-existed and SSO projects have attempted at great expense to integrate what is already there. I believe that in the next few years, the tables will turn. Cost of Enterprise Identity & Access Management integration will be factored into Enterprise Application business cases.

My preference? Set up your application so that the customers can write their own identity front-end integrations. Allow your client base to directly underwrite & collaborate on support for the technologies that they need.

I think the trend is clear here — whether it is user-centric identity, 2-factor authentication, federation, or classic SSO– something (and maybe many things) will supplant the login forms and isolated proprietary communication of identity data that happens today. You can surf that wave, or you can let it pound you into the sand… which will it be?

For those of you in the IT industry — if you agree, be VOCAL. We all know that the squeaky wheel gets the grease. If you want flexibility in identity integration for your Enterprise, you have to ask for it, ask early, ask often, and ask LOUDLY…

Disturbing and Thought Provoking

If you want to get to the core of identity, it doesn’t get any simpler than this: one minute you are present. And the next minute, all the bits are there, they just don’t add up to the same thing anymore.

These photos are powerful and beautiful and in some ways frightening, and the stories to go with the pictures made me cry. I suggest having a bit of time and privacy to view this photo-essay.

Life Before Death

Found via dooce

Baking Security in for 2007

I remember being incredibly incensed by a Catalyst conference panel some years ago, where one of the panelists haughtily declared something to the effect of “if engineers built bridges the way coders wrote programs”… you can guess the rest of the analogy. The expectation seemed to be that if we somehow only allowed “licensed” programmers to work and kept the rest out, life would be ever so peachy.

I’m afraid this sentiment hasn’t grown on me with time. It is absurd to imagine turning every programmer out there into a security expert – and just because they aren’t a security expert, it doesn’t mean they shouldn’t be programming. As user-centric identity technologies ‘tip’ into mass adoption, people of all experience levels will be coding with the goal of accepting information cards, some of whom will be at or beyond the limit of their understanding as they follow someone else’s instructions, or incorporate someone else’s sample code. The challenge is to make it easy for all of those people to do it right.

This is my hope for 2007. It is inspired by an article, written by Jeremiah Grossman and published at gnucitizen.org. Here is a quick excerpt:

The only way I see software security improving significantly is if “security” is baked into the modern development frameworks and be virtually transparent. Remember, the primary developers mission is to pump out code to drive business and that’s what they’ll do not matter what. When developers find that its WAY easier and WAY better to do RIGHT by security, then we’ll get somewhere. Not before… being a web application vulnerability assessment vendor positions you to see this happen first hand. Our data makes it quite clear, which websites are more secure than others.

At WhiteHat we assess vulnerabilities in hundreds of websites each month coded in all sorts of programming languages. Its clear to us systems designed with modern development environments like .NET and J2EE are WAY more secure than their predecessor. Session handling issues go away. So does large amount of XSS and SQL Injection. Are they all rock solid and infallible? No, of course not, but the differences are hard to ignore. To improve the security of software, the development framework seems to be making the most difference.

I consider this an excellent description of what the Windows Communication Framework gives us. Of what Higgins will give us. Of what Rob Richards’ xmlsec PHP libraries give us. A layer of abstraction written by those who know how to be secure, so that not everyone has to be an expert.

So – my compliments and best wishes for 2007, to the people who are working hard to bake security into user-centric identity components, instead of bolting it on later. You know who you are. Thank you for thinking of it, so that I don’t have to.

Lastly, I’d like to offer up an alternate analogy. I think what Jeremiah Grossman is talking about, and the ways in which all of the identity frameworks are already building their systems could be compared to how pyro-technicians create fireworks.

All sorts of hard work, scientific knowledge, research, and testing combines to make a dangerous combination of materials into something that can be safely used simply by planting it, pointing it the right direction and lighting a fuse, because you can be pretty damn sure that some of the people who are going to be playing with the finished product are not going to have pyrotechnical training. In fact they will probably take what you’ve done and manage to turn it into something that you never thought anyone would do –

— but if the pyro-technicians have done their jobs well enough, the world will still be able to enjoy the end result and reason for having started this all in the first place, in reasonable safety. Note that nobody can make a firework 100% safe — because nobody can guarantee that it will be used properly. What they can do is to make sure that when it is used correctly, it is very safe indeed.

My goal for 2007 is to help with the using correctly part. More on this soon…