Know Thyself

I am trying something a bit different with this blog entry, which is to tag team it with a colleague. The idea for this entry came out of an email exchange inside Oracle about identity and privacy. It was an interesting enough discussion that a third colleague thought it would be worthy of a blog entry. From my perspective, it's a chance to work with a great colleague and vent my spleen while doing so. What's better than that?

I should do a brief introduction here to my co-blogger, Roger Sullivan, who is VP of Business Development for Oracle Identity Management. I could provide Roger's more formal CV but suffice it to say that on a "street creds" level, Roger is a very well respected identity management kahuna (e.g., he is also President of the Liberty Alliance).  On a more personal level, a few years ago, Oracle acquired a company of which Roger was then-CEO. I remember punching the air with multiple "woo hoos" when I heard the news, because I knew Roger and thought that the fact we were "acquiring" him as part of the deal was at least as important as the technology (which itself was pretty cool).
The original email exchange Roger and I (and others) had was around federated identity. There is probably a fancier definition of federated identity with which Roger can enlighten us, but as a practical matter you can think of it as being able to have an "identity" that is recognized in multiple arenas that have some business relationship among them. For example, suppose I go to a web site for FooHotels. FooHotels has a business relationship with a car rental agency, RentHotCars (they offer joint car rental/hotel packages, and you get hotel points for renting cars and vice versa). From a consumer standpoint, I'd like to be able to go to a single web site, book a hotel and rent a car (and get all those points!) without having to separately identify myself to each entity. In particular, if I jump to from, I'd like to be able to do that without typing in yet another cryptic username and password. I can do that through the magic of federated identity.
One of the beauties of federated identity is that the standards work in this area was driven by real businesses (not merely technologists in search of a problem to solve "elegantly"). As such, a lot of work to-date has been pragmatic, implementable, and focused on a clear problem that it would be useful to solve. And Roger has been a leader in developing those standards. Woo hoo!
<Roger> Mary Ann, you are too kind.  I think it is safe to say that all of the Identity Management acquisitions, including the recent announcement of Bharosa joining the family have, been great moves for Oracle and our customers.  The synergies created by the union of these "best of breed" companies have been truly remarkable and have catapulted Oracle into a leadership position in the Identity Management market.
Mary Ann has provided a great description of the essentials of Federation.  What else would I say to a former U.S. Navy officer with a loaded weapon?  (Read on...)
Federated Identity Management provides benefits to each of the participants.  For the Service Provider, federation extends their reach into their markets.  For the Identity Provider, it provides a singularly secure mechanism of storing the essential identity elements.  And for the individual user, it provides a safe and secure means of disclosing only the required information necessary for the task at hand.
<Mary Ann> To me, the business need (and utility as a user) of a being able have a federated identity is a different issue than having (or needing to have) a single identity recognized by lots of disparate entities who don't have a business relationship. This lack of business need (dare I say Need to Know?) coupled with many people's natural desire for privacy to me means that we don't actually need a single identity and in fact, I'd really resist it. I do resist it.
For example, I have multiple "identity cards" in my wallet (I have lots of them in fact, judging by the thickness of my wallet). These identities are issued by different organizations, each of which has a different authority to issue them (and don't in general need to know of my other personas). For example, I have a concealed weapons permit in the state of Idaho (which required me, among other things, to take a gun safety class and pass an FBI check). I also have an American Express card. American Express neither knows nor cares that I am licensed to carry concealed in Idaho and the state of Idaho presumably neither knows nor cares what my credit rating is, as long as I pay my taxes on time. This is one reason why I have two cards: it reflects the fact that these identities have no relationship with each other, and each has "authority" to recognize "Mary Ann's identity" that are unrelated. They don't even need to know I am the same person.
<Roger> Mary Ann has hit upon the fundamental issue that concerns many who are using web-based services.
Consider the following example of how we interact in our daily (non-electronic) lives.  Let's say that I'm driving home from work and receive a call from my wife asking me to stop at the store for some milk.  I don't have much cash, so I swing by my bank's ATM machine.  This simple example involves at least four distinct identity elements.  [Pause now while the "Jeopardy" music plays and you try to identify at least four forms of identity.]
The cell call will probably have my wife's name on the screen as I answer because her number is passed through the cell network and I have that number associated with her name in my contact list.  There is reasonably strong assurance that it will be her on the other end, unless she has loaned the phone to someone else.
At the ATM machine, I'll need to insert my ATM card (something I have) and enter a PIN code (something I know) in order to provide multi-factor authentication that it's really me trying to access my bank account.  This is good for the bank and especially good for the security of my funds.  I like providing these extra steps.
At the convenience store, the only "authentication" required is that of the $5.00 bill that I present for the milk.  For some transactions, there is an implicit right to anonymity.  Neither the store clerk nor I have any need to know the other's identity for this transaction.  If, on the other hand, I looked considerably younger than I do and was buying beer, the clerk would have an obligation for me to provide proof of legal age on some sort of recognized identity card.  I know that this is expected in the various day-to-day transactions in which I participate.
What we want to achieve in the electronic world, is the same kind of humanly intuitive interaction with web-based services.  The minimal set of appropriate credentials - and only those - provided for the transaction at hand.
[PS: The 4th form was my driver's license with beaucoup identity information on it.  If I want the privilege of driving, then I will agree to carry and provide this authentication mechanism to the local constable on reasonable demand.]
<Mary Ann> Unfortunately, more and more of our representative identities are linked through the magic (or curse) of Social Security Numbers (SSNs). As such, we have the "collapsing" of identity, sort of the metaphysical equivalent of having one persona instead of many, which has made it a lot easier for identity thieves to flourish. It used to be the case that losing a single credit card did not lead to an identity theft nightmare. You just called the company and cancelled the card (I only did this once, when I "lost" a credit card that later turned up).  Now, if you lose (or misplace) one "identity" that is based on your SSN, or someone else gets access to it, they can often "link" to all your other personas. You didn't lose one card, you lost your entire identity.
The entire identity theft explosion has been fueled by too darn many people using Social Security Number for purposes for which it was never intended: as a single unique identifier (that enables linkages between non-related personas, many times for no purpose that could possibly be construed as beneficial to a user).  Putting it differently, if my magazine subscription record is leaked, so people know that I take Surfer's Journal, I really would not care. (So what? It's a great publication and no harm to me if people know I read it.)  However, if my "subscription record" were to include my Social Security Number (for no good reason, and there is no good reason to use it), I am in deep kimchee because that SSN allows a bad guy access to many other Mary Ann personas. Bad guy can "become" me.
If a Social Security Number is ubiquitous (and it is) but not secret (it has been used as people's health care number and driver's license number, conveniently located on your health care card or driver's license in 12 point font, bold) and the key to "who you are," it is the perfect storm of one "key" (which is not secret and cannot be changed) unlocking your entire identity, so that it can be stolen. The only worse thing would be substituting your fingerprint as your "unique identifier," which is also not secret and can't be changed.
I confess to being a professional crank on this issue. Some years ago, I registered for a class at UC Berkeley Extension (which had and presumably still has excellent classes). They wanted my Social Security Number in order for me to register. Here's how the dialogue went:
UCB: "We'd like your Social Security Number."
Me: "Why, is this a taxable event? Because if it isn't, you shouldn't be using SSN."
UCB: "We want to uniquely identify you."
Me: "That's your problem. I know perfectly well who I am. Besides, if you want a unique identifier, use a database sequence number. Trust me; I know about these things."
I won the argument through sheer stubbornness. (In the interests of full disclosure, I am told that UC Berkeley no longer uses SSN as student identifiers, so good on them. Perhaps in my own small, cranky way, I helped them see the light.)
I should note that Oracle has technology (transparent data encryption, woo hoo!) that can encrypt columns (or entire tablespaces, as of Oracle Database 11g) of sensitive information like Social Security Numbers. It's a nice weapon in the security person's arsenal. A great one, in fact. But the entire world is not Oracle, and encryption, as wonderful as it is, doesn't help you if the data is "inappropriately accessed" in decrypted form.  Eventually, data - any data - has to be decrypted to use it.
<Roger> As Mary Ann points out, Oracle provides sophisticated security mechanisms in order to protect the information that our solutions manage.  In addition, we strongly believe that these solutions must be based on industry proven standards.  This provides our customers with the investment protection and flexibility that web-based applications require in a connected world.  There is a very long list of boring acronyms that detail the identity-related standards that our products support.  Moreover, there are equally long lists of standards for virtually every product area in the company.  A fundamental criterion for the successful integration of acquired companies is their adherence to relevant standards.  This enables Oracle to quickly achieve a return on its acquisition investment.

<Mary Ann> Clearly, there are times when an organization needs to collect sensitive information (like your employer, who needs your SSN to for tax reporting purposes). Many organizations take appropriate care to secure that information. Those aren't the folks that make my blood boil.
You do have to ask, and I have, why is really sensitive data being collected by so many people who do not need it and who don't secure it? Especially when it is users and not "collectors" who pay the costs of recovery from identity theft? It's like someone demanding to borrow my car (something of value to me), getting drunk (not acting responsibly with my property), wrecking my car, and leaving me to pay the repair bill. It's a rotten deal. Any reasonable person would say, "You shouldn't borrow my car; get your own. If you are going to borrow it and you wreck it in a drunken stupor, you pay for it. The entire megillah."
<Roger> Identity standards have been well established for the means of collecting and "connecting the bits" so that the necessary identity information can be protected and securely shared for legitimate purposes.  The danger is that, once the bits are connected for illicit purposes, they can spread at light speed through web infrastructure.  The identity industry is beginning to establish policy standards that go beyond simple interoperability of the technology.  Rules can be created so that there are secure electronic safeguards in place to ensure that only legitimate connections can be made, thereby significantly reducing the opportunity for identity theft.  Additionally, one can assure that the mechanisms for managing the data and performing risk analysis can be thoroughly audited.  Establishing, implementing, deploying, and auditing these standards-based solutions will add enormous confidence to those who are using web-based services.  And that will yield comparable market growth.  
<Mary Ann> I like what I am hearing from you, Roger! Federated identity is a wonderful thing when there is a business purpose for linking my identities, as there so often is. As someone who is forever being asked to create another username and password for yet another website, I wish we had more of this where it makes sense. However, federated identity is most assuredly not "having a single persona that relies on an immutable non-secret for security." Only God and my mom - well, maybe only God - knows or should know all the different facets of my persona, or anybody's persona. I for one would like to keep it that way.
<Roger> So, Mary Ann does your spleen feel sufficiently vented?
<Mary Ann> On this topic, yes! Thanks for adding color, detail and expertise to the discussion, and for being part of the solution, not the problem.

For more information:

Liberty Alliance:

Surfer's Journal, a great publication:

Roger Sullivan's blog:

Oracle's acquisition of Bharosa:


Post a Comment:
  • HTML Syntax: NOT allowed



« July 2016