Adventures of an Eternal Optimist

I love working with smart people.  I went into the ICF schemas working group call with my set of gobbled-together proposals, and everybody seized on it and started breaking those ideas down into their separate pieces, using language with far more structure than my own words.

There were some excellent points made:

• What are the expectations of the “Display Claim” versus the actual claim in providing human-readable claim values?  Is it reasonable (or even preferable) to define a claim value that is not human-readable and trust that the STS will be responsible for mapping that value to something useful?
• Is it expected that the selector will do a metadata discovery on each and every claim passed?  I had never even thought of such a thing, so will have to learn more.

I will keep you up to date with the conversation, which is expected to continue on the working group mailing list this week.  The mailing group is:  http://groups.google.ca/group/icf-wg-schemas,  I believe anyone can read, but you have to be an ICF member to participate.   If you are keen to participate, let me know.

During IIW, the ICF Schema Working Group proposed and approved its first standardized claim definition.  I’ve been following the workings of the schema group but not closely, and I was taken by surprise at the values defined as part of this precedent-setting claim element:

Claim Name:  age-18-or-over

Proposed Values:

• 0
• 1
• 2

What?  Want to know what the values MEAN?  Sorry, you’ll have to look that up.  What you see above is what a Mother or Father will see when they view values passed between the Identity Provider they are trusting to make claims about their children’s age, and a website that may restrict content based on that value.

Do you see the problem?  Why on earth even have a selector if the standard claims we propose are not understandable by end users?  Why use a meaningless number?  To make it easier for the machines?  For the developers? That’s crazy!  Why don’t we make it easier for the people that are making selector-level security decisions on a daily basis?  These schema types have to be created so that whenever possible, the data passed is legible to those attempting to understand the context of identity data flowing around them.  Heck, if we created a vocabulary for content that could be distinctly identified and parsed by Selectors, we could even localize.

It’s taken me since IIW to really get my head around this – but I believe we need to set some very specific best practices around these schema elements, first and foremost being the primary design principle that these atomic elements should be designed for regular people, not for developers, and not for machines.

I’m going to do my best to argue this point today on the ICF working group call.   If you think this is important, whatever your stance on the issue might be, I urge you to join the Information Card Foundation and to make your voice heard.   Contact me if you aren’t sure what you need in order to join, I will put you in touch with the right people.

I think that best practices around claims schema is THE MOST IMPORTANT thing happening right now.  It is worth taking the time to get this right.  We’ll only get one shot at it.

The public version of the claim catalog is here:   https://informationcard.net/wiki/index.php/Claim_Catalog

Today was an interesting day for the Identity geeks of the world.  A viral outbreak of concern broke out among twitter users over site called “Twitterank”.    Twitterank asks for your credentials and displays a number theoretically outlining your theoretical socal viability in the twitterverse.

Once the word “phishing” became attached to the service, people became fascinated.  I have no idea of the order of it all – but several things happened:

• A ridiculous number of people decided to try out the alleged phishing site.  Some of them even changed their password afterwards.
• References were passed around to a site called “Twitterawesomeness” that appears to exist as a very pointed statement about how easy it is to phish a site like twitterank. The disclaimer states:

I’m in ur Twitterz, stealin ur credz!
It’s ok, 178 other people gave their passwords too!

• The author of Twitterank came out with this statement:

I’m not out to steal ur twitterz. Frankly, I wish I didn’t have to ask for your account info, but Twitter doesn’t offer APIs using any other authentication mechanism (according to the docs). So blame them.

So let’s see then:

1. twitterank is right.   The best way to protect the passwords of the users of your service is to provide alternatives to giving away your password.   Granting permission for another entity to see your data is something Twitter can securely enable – or ignore.  We know where they stand so far.
2. twitterawesomeness is right too.  It doesn’t matter whether twitterank is crooked or honest.  Anyone who wishes to spend the 10 minutes to emulate twitterank’s main page can harvest passwords, if they can get people to click on a modified link.  Obviously not a difficult task – especially when people only see a “tinyurl” for most of the links they click.  Heck, just register “twitterrank.com”.  People will come to you.
3. To all you folks who changed your password — do you use that password anywhere else?  Cause if I were going to steal username/password combinations, it certainly wouldn’t be to read a twitter stream.  But I’m sure nobody would be crazy enough to use the same combo at twitter and at their bank…  what about the password you might have had when you tried the service a month ago?
4. In fact – even if you don’t use that combination at your bank, I might be able to still get there. I would use the credentials to harvest your email address from twitter, and then try to login to that email account.    If I was lucky and got a hit, I could then start putting your email address into password recovery pages for all sorts of interesting places.  Once you have email, you have the keys to the kingdom.

Of course, I could also just phish your bank site.  Occam’s razor applies here.  Still, the point has been proven.

Mashable Link

ZDNet Link

Electronic Arts has just backed into an interesting twist to the TOS story.   They are linking your online terms of service to the physical video games you buy — if you violate their online TOS, your right to run every video game linked to that account will be revoked.

This adds a massive lightning stroke of accountability into the affair, doesn’t it?   Suddenly, the forums aren’t just a “value-add”, they are also a potential “value-take-away”.   I have this picture in my head of Family Member A explaining to Family Members B and C how A lost his/her temper in the EA forums last night, and now the whole family has lost not only their access to their games, but possibly their game statistics & reputations too, depending on what EA does to enforce the ban and the subsequent serial number invalidation.    Ah, it all comes back to Identity mgmt and asset mgmt, doesn’t it?

I suppose you could consider this the Real-time Blackhole List approach to reputation & social networking.

As lost as we might be right now, the future is very, very bright.    One of the biggest forcing functions that I see on the horizon is cloud computing.    It’s one thing to have a whole bunch of internally controlled silos that don’t talk to each other — but imagine all those silos spread across the internet.

Cloud computing is a practice that garners high risk without disciplined Identity Management.  Enterprises have traditionally had the luxury of laziness when it comes to application integration because removal of physical and network access can compensate for late or non-existent deprovisioning of internal accounts.  There is no corporate perimeter to save you with cloud computing. Automated Enterprise control of at least web access or account status is the only way to mitigate the risk for customers of any size – and this is a great thing, because it means that practically every customer of a cloud service has an identical worry.  When the vast majority of the the client base has an issue, that issue gets vendor attention.

In addition, it is obvious that a huge number of SMALLER Enterprises are going to subscribe to cloud services.  More than anything, I’d like to see resources in place such that at the time a smaller company makes that jump, they can find and follow a few cookbook Identity practices that most Enterprises don’t think to care about until they have severe pain.   If we can help smaller companies to institute solid, integrated Identity practices BEFORE they buy big HR products and massive internal help desk systems and complicated document management software, maybe we can ease the pain before it ever starts, rather than having to apply band-aids after the fact.   Preventative medicine is so much cheaper for all, isn’t it? Perhaps when faced with the choice of adopting an easy-to-integrate cloud service or an impossible-to-integrate in-house software product, companies will choose easy-to-integrate.  If that happens, suddenly those big, lumbering software vendors might get a clue that they cannot operate in a vacuum, and that ease of integration matters.

Case in point: the company I work for, Nulli Secundus.  We recently abandoned our Sun Messaging Server installation for a cloud service.  One of the biggest complaints about Sun Messaging Server was its complete and utter inability to facilitate integration of the web client into our SSO infrastructure – not being able to integrate is pretty embarrassing for a company that specializes in Web Access Management.  With the cloud service, SAML support is already there, waiting for us.   The decision was a no-brainer, the cloud service made it unbelievably easy to switch.   I imagine a lot of small companies are doing the same thing. Once we get SAML integration working for this first service, integration of following SAML-enabled services will be effortless – application sales & marketing teams with any kind of intelligence should see that this waiting and available infrastructure is great sales leverage.  These are the trends that turn into tipping points enacting massive change – we just need to seize the opportunity and provide guidance & pressure in order to maximize the benefit while things are forming and flexible.

So – our current state doesn’t keep me up at night.  Not when we have all of this opportunity in front of us…

The track I spent almost all of my time at this year’s Catalyst conference was:  “Identity Management: Are we There Yet?”

I came out of that track convinced that we have lost touch with the actual question of why we are doing all this work in the first place.    Long before I attended Catalyst, I’ve become more and more worried about the way in which companies are being “assisted” in their work around Identity Management. It seems to be all about ‘getting’ the right product/services, and not about finding a solution that fills a need.

In my opinion, and you’re very welcome to disagree here, nobody “gets” Identity Management.  It is not a destination that you can arrive at.   It is more like a tour you can take, where you can have a different experience depending on how much time you have, how much money you are willing to spend, and what your particular preferences might be.  You might take a slightly different tour every year — but you never stop taking tours, because the experience you might have can always change and improve, because there is a never-ending variance in what you can see, and because the sights are not static – the world changes.

What has happened in Identity Management in the last two years is generally a great thing — niche solutions are evolving to respond to demand that is too specialized for the big Identity & Access frameworks to build in (product fields like Privilege Management and Adaptive Access Control are examples of this).  In addition, there has been a product response to the obvious need to have accurate and complete data on which to base Identity and Access Policy upon – examples of this include Role Management and Mining.   Ideally, the result of all this innovation should be that a patchwork of products are evolving to cover more of any given company’s needs out of the box.

In reality, however, I don’t see a patchwork of complimentary products – I see a whole bunch of products with a whole bunch of overlap and no obvious or well-stated way for an Enterprise to figure out how to knit it all into an actual solution for their original problem.   Perhaps I’ve just not read the right documentation,  but I couldn’t tell you how or whether Privilege Management solutions integrate with provisioning solutions in order to have good combined audit reports.  I have no idea how an Entitlement Management solution might co-exist with an Access Management solution.   I see a fairly strong divide between “Corporate” workflow systems like Remedy and “Identity” workflow systems like those in Novell Identity Manager or Sun Identity Manager that I would like to see go away.

At Catalyst,  I learned a fair bit about each little type of Tinkertoy.  What I wanted was more of a sense of the different ways that different Enterprises might wish to assemble something useful from all the pieces.  Perhaps Burton has expanded their reference architecture to include these new niche product genres and they just didn’t present that architecture at Catalyst (or perhaps I missed it) ?  If not, I hope that such a thing is on their slate in the near future, I think it would help a lot.

So here we are, a little bit lost, I think. Certainly not “There” – but I think the expectation that anyone ever gets “There” is false anyway.  In the process of deciding that we’re lost, I had to sit and think about what exactly Enterprises expect to accomplish in buying Identity product;  I’ve come up with my own definition, in as concise a form as I can think to make it;  I’ll post it shortly and see how it stands up to scrutiny.

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.

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:

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

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

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.