User-Managed Identity Starts at Home

Secure Personal IdentityRecent news about intrusions into the online accounts of public figures like U.S. presidential candidate Sarah Palin and prominent companies like Twitter remind me of the not-too-distant past. These appeaer to be bellwether events pointing out that the general public is starting to realize the protection of their identity starts with what they can (and should) control. It sometimes takes high profile cases like this to energize action, a cycle that appears to repeat itself.

About 8 years ago I took on the challenge of securing the digital borders around the e-commerce systems for the Kraft Group’s sports properties. At that time, I could see a storm cloud gathering on the networked horizon as we built a system to unify all of the current properties and set the foundation to build out a series of interconnected portal communities. Looking forward, I knew that it was only a matter of time before a major press-worthy event would raise everyone’s awareness regarding the protection of user privacy, in the form of personally identifiable information (PII), and associated payment information.

Our business strategy was to build a core commerce engine that could handle online transactions embedded within each separate portal. Key to our success was enabling users to have a persistent identity throughout their engagement with our products. In this way we could minimize the barriers to their interacting with our content, as well as streamlining the purchase pipeline. Essentially, once users logged into any of our portals (to access premium/personalized content, manage accounts, and purchase products), we were able to effectively cater to them by simplifying their experience.

The problem with this single-sign-on model was that if a user account was compromised, the intruder could have free reign over the victim’s PII and associated payment information. I had to make the case for going the extra mile(s) by designing strict access control procedures, knowing that something bad was going to happen to a company soon and that we should be ahead of any reactionary solutions imposed upon us. I had a feeling that after some bad press, the e-commerce industry would be pressured to lock down the porous borders that were relatively common at the time.

Just such a case occurred in 2004 when hackers were able to access an estimated 8 million credit card numbers from BJ’s Wholesale Club. It took a few years for details of the incident to emerge, but it was clear even then that there were two primary issues: insecure access points, and poor audit logging. Regardless of whether it was an inside job (as was initially assumed) or an outside hack (which it turned out to be), BJ’s (among other compromised companies) had poor access control and monitoring.

This, as well as other similar incidents, prompted the creation of the Payment Card Industry Security Standards Council, founded in 2006 by American Express, Discover, JCB, MasterCard, and Visa. The payment card industry thus began requiring strict practices and controls around systems that perform above a modest threshold of transactions. It was a strong move, in advance of looming legislation, that helped steer wayward companies toward better practices. Regardless of the critiques of their programs, it has succeeded in shining a light on many problems needing to be addressed.

Fortunately, by the time the PCI guidelines hit the market, we were able to breeze through their audits. The commerce engine we’d built was tighter than what they required. It’s rare that you can so easily point to a situation like this where the extra capital cost on the front end so clearly saved money that would’ve been required to retrofit a running system.

Now, here’s where the history lesson circles around to become informative for current events. We should learn from these cases of identity intrusion and address the core issues. The obvious lesson is not to be cavalier regarding the protection of your email accounts. After all, they are your core identity asset in today’s online world. Be careful when setting up your email account and follow common sense when selecting passwords and associated “remind me” features.

Beyond what you can do for yourself today, the industry needs to step up it’s game, too. Fortunately, there are a number of efforts currently under way to help protect your identity. They just need to be more whole-heartedly embraced and helped to mature by the major players in the market. What’s uniquely interesting about many of the emerging solutions is that they’re user-centric, rather than being centered around any one company’s digital security practices. This focus helps solve the root problems: privacy protection starts at home, and it’s not a simple matter of more/better cyber-security and encryption.

For more information, and to become involved, I highly recommend following the open standards development relating to user-managed identity:

And, of course, the Internet Society Trust & Identity Initiative. Tell them I sent you.

July 22nd, 2009 | Commentary | , , , , , , | Leave a comment

Reason to Choose an Identity Provider

Buried in a post about OpenID user experience by Chris Messina is a concise bit of advice for users:

picking an identity provider should be like picking a bank or credit card provider: as a fourth-party service provider that advocates for your interest, since you’re their customer!

The “fourth-party” reference is to an article titled “Get ready for ‘fourth party’ services” by Doc Searls in the Linux Journal.

Personally, I’m not a fan of the introduction of this term for the new party around the table. I like to think that a “third party” working on the user’s behalf fits the bill just fine. Following an object-oriented mindset, the third party can adopt the properties relating to it’s responsibility in a transaction without being locked between two others (necessitating a fourth).

What I do like, however, is the concept Chris clarifies later:

Instead of agreeing to terms of service that disclaim all responsibility to you, the customer, I hope that competition in the identity space will lead providers to actually take responsibility for their services — charging good money for doing so. If your account gets hacked — no problem! — your identity provider can put back the pieces and make things right again! You could even take out online identity insurance in case your identity is ever stolen — so you can always get back to your life and recover your data without the hassle and interruption when it happens today.

To unpack this a bit, I see a compelling use case for identity providers emerging, possibly piggy-backing on the PCI Security work. So far, the first quote about picking an IdP is falling on deaf ears as users don’t really think about their choice. They use what they use and that’s about as far as it goes. What users need is a compelling reason to think in terms of choice, and the model Chris suggests might be it.

I spent some time helping to build an affinity card system with MBNA a couple years ago, and that process was telling. As it relates to this discussion, I can easily see that they would jump on the opportunity to capture a market like this. All that needs to happen is for someone to write up a clear business plan around the concept. In fact, I’ll bet there’s an MBA student out there somewhere looking for their thesis.

In a nutshell, here’s what I think this looks like:

  1. Credit Card Company (C3) sets up a new product based on it’s current card-based account system.
  2. C3 stands up a full service identity provider (possibly built using the Higgins Identity Framework)
  3. For high value services, C3 executes federation agreements with key nodes.
  4. C3 contracts with an insurer to cover losses due to ID theft / masquerading (rates most likely locked to the NIST levels of assurance as codified by the Liberty Alliance Identity Assurance Framework).
  5. C3 then advertises the new product to it’s existing customers (ID validation fees waived as an incentive)
  6. Users now have a reason to choose C3 as their IdP for all high value applications (and might as well use them for everything else, too).

C3 still has to convince it’s customers (and attract new ones) to see value in paying for a secure IdP. I don’t believe this is too far away from happening organically, so now’s the time for a C3 to start working on the product line.

Further, it’s distinctly possible that Id end points are going to force the issue by requiring verified identity assurance and security beyond what your run-of-the-mill OP can provide. Hence services like MyID.is (which has it’s own issues, of course, but that’s the direction). If a C3 gets in the game, I have a feeling they’ll be able to build a more effective federation of trust, even when used in an anonymous context.

April 8th, 2009 | Commentary | , , , , | Leave a comment

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:

  • Authentication: Identifying yourself using some type of credentialing system
  • Authorization: Having the rights to access and/or modify something.

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.

September 18th, 2008 | Commentary | , , | Leave a comment