Chris Saad recently posted a succinct clarification of the following questions related to some business issues around data portability:
- Why would a vendor allow users to leave their service?
- Why make it easy for users to take the precious data you have about them and use it on other sites?
- What is the business justification for letting data walk out the door?
He’s got some helpful diagrams that illustrate his point, so I suggest reading his post on “The mythical value of data lockin“. In short, though, it’s this paragraph that seems to sum it up:
Even if you are Google, and you know every search your users do, every document they write, every chat they have – you still don’t know their facebook social graph. You don’t know their tweet stream. You don’t know the books they bought on Amazon.
I wish I could remember where I first heard this quote to attribute the source, but it works as the bumper sticker (or Twitter) version of the same sentiment:
No matter how large a website is, the internet is bigger.
Basically, sites will ultimately learn much more about their users=customers when they plug into the sharing network than they’ll be giving up. Here at matchmine, of course, we’re all about enabling sites to access user interests and tastes (under the control of the user), so we bounce into these questions (and provide the same answers) on a daily basis.
To this point, we’re walking the data portability walk ourselves. We’re not only consuming feeds from various sources, but are also a couple days away from streaming data back out, too. It’s all part of our Openness Roadmap I hope to start talking up in the coming weeks.
In the end, all of us (e.g. users, service providers, destination sites, publishers, etc.) win when we aren’t wasting time constantly reinventing wheels (or filling out yet another form). Instead, we can use that time to focus on the unique values we bring to the collective table.
September 5th, 2008 | 
Authentication, Authorization, and Assurance
The deeper I dive into the various projects I’m working on the more I encounter the substantive differences between logging into a system and having the appropriate roles to access what they need. In my rough-n-ready approach to definitions as a way to discuss concepts:
In our daily lives, we’re familiar with the need to authenticate. Whipping out your ATM card and entering your PIN is a common example of telling the banking system who you are (or at least the identification of your account). In the expanding universe of online services, everyone’s inundated with the standard challenge/response prompting the entry of username and password.
What’s not as often visible is what happens post-authentication. Under the covers, systems generally track what you’re allowed to do once you’ve said who you are. This is where authentication enters the story. After entering your PIN, you can pull some cash from your bank account, but your access is often limited. For example, you are only authorized to access up to $N.
This is all very well and good, but oddly enough it glosses over a fundamental issue at the core of these transactions. Specifically, when the authentication credentials are assigned, it’s not always clear the issuer truly knows the identity of the credentialed party.
This is where “assurance” comes into play. I had a great dinner conversation with Peter Alterman of the GSA who was able to shine a light on the subject. Before entering a system requiring authentication (and associated authorization), you’ll need to assert your identity to a level the managers of the system find acceptable. There is, of course, a complete gamut of acceptable levels as not all systems require the same assurance of their users’ identities.
These days when we’re creating new social networking accounts every five minutes, it’s pretty clear little to no assurance is given to the site that the name you entered when registering is valid. It’s arguable whether or not that’s a problem, but it’s not very controversial that signing up for Facebook has different needs than being credentialed to access your medical records.
Then again, that’s only true insofar as you’re going to stay within that system (or largely similar ones). What happens when you start cross-linking systems in a frenzy of mash-ups and other data portability goodness? Unfortunately, the discussion with Peter really opened my eyes to the host of issues that arise when a user creates a self-credentialing account, then wants to link data from it to a system he perceives as being more secure. It was in the context of discussing a healthcare initiative I’m working on where this problem really became obvious.
Taking my personal experience here, I’ve got what I believe to be the mac-daddy of OpenID accounts. I have been using myOpenID.com (and I firmly recommend it to anyone who will listen), and was thrilled when they rolled out their two (and three) factor identification methods. Now if I want to log into an OpenID Relying Parties, I need to present not just a username / password combination, but also provide an SSL certificate and answer my cell phone, too. Now if you want to access my accounts, you need all three bits: un/pw, SSL cert, and my cell phone.
Now, here’s the ugly secret. I set up that account myself, and no one verified that I was who I said I am when I created my OpenID. Basically, you could call it “Assurance Level 0″ (i.e. no assurance of my identity whatsoever).
Who cares, you might ask rhetorically. Well, you should. While it’s fine-and-dandy for run-of-the-mill social networking systems, what happens when they start asking for your credit card number? We’re right back where we’ve been for decades. Yes, you logged into the system before entering your payment information, but when you roll back to how the account was created it’s not materially different than simply typing your credit card into a non-credentialed system.
So, basically, here’s where I am now. I’m working on a couple of projects that need to maintain a level of security throughout the process lifecycle. Apparently, I need to be much more careful how credentials are allocated, and it’s not enough to rely on self-credentialing. I’m looking into automated multi-factor identification assurance models now (akin to SSL certification methods used by VeriSign that use third-party triangulation).
If you’re curious about this assurance discussion, you might want to pop over to the Identity Assurance Framework released by the Liberty Alliance. You’ll also notice that Peter was a co-chair for some of the work that went into it. I guess I was talking to the right guy.
END NOTE: I wish I knew the origin of the saying, “to name something is to control it”. In my experience that’s nearly accurate in that once a (good) name is applied to something, it’s easier to discuss, and thus feel a sense that what’s been named is more effectively understood. That’s not necessarily true, of course, but at least agreeing on a common name is a good start. Now that I’ve got a handle on the term “assurance”, I have a sense I’ll be able to more effectively grapple with the concept.