Adventures of an Eternal Optimist

I so love to see a point well made:
[youtube=http://www.youtube.com/watch?v=_hnOCUkbix0&hl=en]

I’ve decided that there is no better way than to learn the ins and outs of a technology than to publicly assert your understanding — as long as your ego can take it, you learn very quickly where all the gaps and flaws in your logic lie :)

It turns out that all this time that I’ve been working with information cards, I’ve misunderstood the nature of .crd files and managed card portability. In my talk at RSA, I stated that managed cards had a different portability model than self-issued cards, because a user could download a .crd file from an Identity Provider at any time, import it into a new selector, and use it to get to all of their sites where they had previously associated a card from that account at the Identity Provider.

This isn’t the way that .crd files work, as it turns out. A .crd file is not an information card – it is an information card *template*. When you download a .crd file, the master key for the card is not part of the file, it is generated upon import — thus if you import a .crd file into two different selectors, each card will have two different master keys. Different master keys mean different privatepersonalidentifiers being sent to the Relying Party, who will most likely object. This means that even if somebody out there compromises my identity provider, they may be able to download a card that points to my identity, but it is highly likely that they won’t be able to use that card anywhere that matters (unless the Relying Party isn’t asking for ppid, that is). This revelation has opened the door for me to cook new hare-brained schemes around how cards might be used for what I like to call “user-centric forensics” –I see two possibilities for intrusion detection here:

1. If my card is an auditing card, I hope that in the future, Identity Providers will prominently feature any unsuccessful card use attempts, giving me a cue that something is wrong, and giving me data that I could use to find my attacker.

2. Depending on what the Relying Party keeps about a given card, it should theoretically be possible to detect a token submission where both the claims and the issuer are identical to a valid cardholder, but where the ppid differs (or perhaps where the submission comes from an IP address in a different country or a combination of this kind of thing). Whether such a thing is desirable or not is a different question — the RP would have to store a *lot* of data, and the resulting privacy tradeoffs might not be worth it. The PamelaWare plugins couldn’t do this kind of tracking, as we store a hash of the issuer and ppid rather than the values themselves (this is the closest thing to an RP best practice that I know).

If managed card portability is needed in the way that I originally understood it, I think it could still be done – a claim other than privatepersonalidentifier could be used to pass an identifier not tied to the master key of the card — but all in doing so, you lose one of the qualities that in my mind makes information cards unique, you would essentially revert to a two-party system, with the selector merely passing things around instead of being an essential participant. No matter what, I think this concept of card templates could be used to do some very imaginative things – now that I understand the difference, I can’t wait to go and play!

Many thanks to Vittorio for attending my RSA session and giving me such valuable feedback – I am very happy to be just a little less clueless in at least one tangible way :-D

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.

We 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. It 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.

Land of Ice and Snow? Rampant stereotyping I say!

Just because the forecast just *happens* to actually be for both snow and ice in the next four days means nothing. Pay no attention to the man behind the curtain….

y’know, sometimes I think these guys just don’t care.

If you’re going to own a powerful Web Access Management product, doesn’t it make sense to perhaps showcase your own product by making Single Sign-on and password management simple and seamless on your own customer-facing sites?

As such, I would hope that asking for SSO integration between the documentation site and the knowledge base site would not be so much to ask for. I’ve had to do password recovery on both sites today — one worked and the other failed. The second (failed) attempt just kills me — check out this flow:

• I enter my email address into the lost password form.
• I receive a new password via email. This would imply to me that I have chosen the correct email address, yes?
• I then take that very same email address and the newly assigned password and put them into the username and password boxes on the login form.
• My login fails.
  • There is no “forgot my username” link
  • The help link confirms that I should be entering my email address anyway.
  • I can get passwords galore from the lost password workflow, but none of them appears to actually work with my email address.
  • I can’t actually figure out who to talk to to get out of this lovely loop.

WTF?

I *know* they have the tools to make this a much easier process, that’s the worst part.

Aggggh…

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 :)

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…

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

Great news! The Pamela Project has received a first round of angel investment! We will now be able to expand and improve our operations!

Paris Hilton has agreed to fund the project, as part of an ad campaign for her new “Identity” line of clothing and jewelry. To reflect this large investment, we have changed the name of the project to “The Paris Hilton Project” and all of you attending next week’s RSA conference will see that a whole wall of the Interop room will be dedicated to Paris’ products, and Paris herself will be there to makeover all of the OSIS Interop Participants! Your wives, daughters, and girlfriends will thank you later. As well, we at the Pamela Project anticipate a wave of paparrazi, all wanting to know what “Identity” really is. Please inform your marketing departments accordingly.

When asked about whether Paris would also endorse Information Cards as an easy way to perform Identity transactions on the internet, Paris was quoted as saying “That’s hott”. We believe she was referring to information cards at the time.

Stay tuned for more details on this breaking news!