Burton Group Identity Blog

OSIS User-Centric Identity Interop at Catalyst Europe 2007

Blogger: Bob Blakley

OSIS conducted the third in their series of User-Centric Identity Interop events yesterday at our Catalyst conference in Barcelona.  As we did in San Francisco, Burton Group hosted and provided support for the event.

There were a few differences between the Barcelona interop and the earlier event held at Catalyst North America 2007.   The most noticeable difference is that the Barcelona interop has been conducted entirely in public.  You can visit the Interop wiki to see details of the organization, planning, use cases, and participants; if you’re in a hurry, though, I’ll summarize here.

Fourteen projects and organizations participated; you can see the list here.

The participants tested 6 identity selectors, 13 identity providers, and 24 relying parties.  The Barcelona interop added a significant amount of testing of OpenID interoperability; 6 OpenID providers and 5 OpenID relying parties participated.

The participants have posted their results on the wiki, and a few words are in order about these results.  The first thing you’ll notice is that there are a significant number of “failure” and “issue” results.  This is very good news for two reasons.

The first reason it’s good news is that it means enough new test cases were designed for this interop to uncover new problems.  What you don’t see in the matrix is that when testing began, there were even more failures – which means that a lot of the new issues identified during the exercise have already been fixed.

The second reason the “failure” and “issue” results are good news is that they’re outnumbered by the successes.  When you consider that the things tested in Barcelona were all identified as problems at the previous interop, you’ll get an idea of how much work has been done by the OSIS community in only 4 months to improve interoperability and agree on standards of component behavior.

I’d like to call your attention to one more thing.  At the Catalyst North America interop in San Francisco, all the interop participants were onsite, sitting in a room together.

Here in Barcelona, as you can see in the Participant Profile table, about half the participants worked remotely.  What this means in practical terms is that a lot of the components in this interop were accessed over the Internet, in the same configuration you’d use if you deployed them in your business.

I expect that the results table will continue to evolve for a while as additional information from the event is digested and entered into the wiki; I’ll probably post another blog entry with some analysis of the significance of the results after the conference is over and I’ve gotten some sleep.  But my preliminary sense is that this interop continued to demonstrate progress toward an open, deployable, interoperable identity metasystem.

I’m grateful to all the participants for their hard work, and I hope the next interop moves the ball even further forward. Also, we thank Microsoft for sponsoring the sponsoring the network connectivity as well as the catering for this event.

Nothing is Bulletproof

Blogger: Mark Diodati

Tim Renshaw is a VP at TriCipher, and he has a blog over at http://eyedentityonline.com.  TriCipher is a consumer authentication company; its technology provides mobile PKI in various forms, and provides additional security by splitting the private key.  He had a post about my two-part interview with Jeff Gould at eWeek (the second part of the interview is here, and Tim’s blog entry is here).  Basically, he says I don’t know what I am talking about.  How can I resist a reply?

One fact that I have stated continually over the years is that no mainstream authentication method (consumer or enterprise) is bulletproof.  Even the PKI solution Tim touts is problematic, and I don't agree with his assessment that it will solve the consumer authentication problem.  It's clear from talking to the world's largest financial institutions that most FIs are not prepared to deploy a full-blown client and/or hardware solution - U.S. consumers don't want them (note: the recent VeriSign/eBay announcement is not a bellwether for general consumer usage), and the FIs are unprepared for the onslaught of help desk calls.  But, let's assume for the sake of argument that FIs could deploy smart cards on a large scale.

Smart cards offer a highly tamper-resistant storage mechanism for private keys.  Most people would agree that smart cards are the most mainstream secure storage mechanism for private keys (after all, the deployment of HSMs to end users is impractical, right?).  I like the technology for the right use cases, and I think it is perhaps the best authenticator available from a security perspective (provided, as with any authentication technology, that the identity proofing is done correctly).  But even smart cards are subject to attack.  Let's say that the client middleware is configured to authenticate the user once via PIN (or biometric), then enable continual access to the private key.  User malware can send data down to the smart card for signing by the private key, but the user would never know.  Let's kick it up a notch - let's make the user enter the PIN every time a signing function is required (ignoring usability implications).  Malware could send down data to the card for signature that is different from what the user is expecting to sign.

Software-based PKI solutions overcome some of the smart card deployment concerns, but they are not as secure as smart cards and are subject to similar attacks as the one Tim specifies for typing biometrics.

Another fact that I have also stated over the years is that authentication solutions must be layered to provide an adequate level of identity assurance that is required for the application.  This is why you are seeing the FIs overlay risk analytic engines on top of primary authentication mechanisms.  No one technology will do the trick.  I’m not summarily dismissing either the typing biometric or PKI technologies.  To suggest however, that PKI will solve the consumer authentication problem is disingenuous.

Oracle acquires LogicalApps

Blogger: Lori Rowland

Recently, Oracle further extended its investment in the governance, risk, and compliance (GRC) market by announcing its intent to purchase LogicalApps, an enterprise applications control management (EACM) vendor. This acquisition comes as no surprise for those following the GRC market, as Oracle and LogicalApps have a rich history together. LogicalApps has been a certified Oracle partner for over 6 years. LogicalApps was founded in 1999 and has been primarily focused on providing deep, low-level controls such as transaction monitoring, separation of duties (SOD), and access control technologies for the Oracle E-Business Suite. In early 2007, LogicalApps purchased Applimation to expand its suite to include controls for the PeopleSoft environment.

SAP made a similar acquisition in 2006 with the purchase of Virsa Systems. As predicted in Burton Group’s Identity and Privacy Strategies Report When Provisioning Isn’t Enough: Enterprise Application Controls Management (subscription required), Oracle’s acquisition of an EACM vendor was an inevitable next step.

There are several independent vendors at large that provide similar controls management and transaction monitoring for ERP environments including Approva, ACL Services, and Oversight Systems. Oracle and SAP’s recent GRC acquisition and strategy announcements have left people wondering what the future holds for these vendors. 

There are obvious benefits to implementing Oracle and SAP’s controls management solutions to manage the respective environments. Who knows SAP SOD policies or sensitive transactions better than SAP, right? Oracle and SAP are in a unique position to provide detailed, low-level controls for their own environments. However, control requirements are not typically administered in a vacuum. Controls span multiple systems, platforms, applications, and environments. From an access control perspective, SOD is not limited to an SAP, PeopleSoft, or Oracle environment. Rather, SOD controls must span ALL of these environments as well as legacy or custom applications. 

Another question organizations must ask themselves is: “Should the fox be watching over the hen house?” Many organizations require or prefer a third-party, independent solution to audit and manage controls over their environment. It is important to ensure that the software you select to manage your controls does not introduce a SOD violation itself (e.g. policy administrator same individual or system as policy auditor).

Oracle and SAP have stated that they plan to continue support for applications and platforms outside of their respective environments. This may be true; however it would seem that the most significant investment will be made within their unique environments. Oracle’s LogicalApps and SAP’s Virsa acquisitions are both part of a much larger GRC strategy. These organizations will continue to build out their GRC strategies which today are primarily focused on the Oracle and SAP environments, respectively.

So what does the future hold for the independent control management and monitoring vendors?  I believe that these vendors will remain competitive. Many organizations are looking for an independent, cross-application alternative. To gain momentum, these vendors will likely partner with identity management identity audit, role management, activity monitoring, and other security and risk management vendors to offer integrated solutions to common customers. Independent vendors may also become acquisitions for system management vendors such as CA, HP, and IBM.

The term “GRC” is becoming overloaded. It is important to carefully evaluate all of your security, risk, and audit requirements when evaluating GRC solutions. Your GRC strategy will likely include multiple technologies from multiple vendors. EACM technologies are no exception to this rule. 

The Growing IdM Suite

Blogger: Mark Diodati

Over the years, we have watched IdM vendors acquire companies and their products to round out their suites.  The list is long, and goes back before anyone was talking about “identity management”.  CA acquired Platinum in 1999, which brought enterprise SSO and UNIX security solutions into the stable.  You might argue that an OS security product is not part of IdM, but it provides authorization services and therefore fits the definition.  In late 2004, it acquired Netegrity and its flagship product SiteMinder.  Oracle has been on a tear recently, having acquired Oblix (WAM and federation), Octet String (virtual directory), Thor (user provisioning) Bharosa (consumer authentication), and Bridgestream (role management).  IBM has done the same thing, with its acquisition of DASCOM (WAM) in 1999, Access360 (provisioning) and Metamerge (metadirectory) in 2002.  Sun has made similar acquisitions (e.g., Waveset for provisioning).  The list is by no means exhaustive.

The trend begs the question: “What’s next?”  Ignoring the obvious GRC market, three product markets are ripe for acquisition in the near term: enterprise SSO, virtual directories, and privileged account management.  My prediction does not place me in the same league as Nostradamus (or Criss Angel for that matter, who dabbles in this art), as Oracle has already acquired a virtual directory company (Octet String).  As the consumer authentication and entitlement management markets mature over time, companies with these products will also be candidates for acquisition.

Few enterprise SSO companies exist in the marketplace.  ActivCard (now ActivIdentity) acquired Protocom to enhance its existing capabilities.  The company with the biggest bulls-eye on its back is Passlogix.  Passlogix OEMs its v-Go eSSO product to Oracle, Sun, and IBM.  The Citrix product has a residual amount of Passlogix code in it.  Whoever picks up Passlogix has the opportunity to shake up the market and irritate its competitors.  CA has its own eSSO product as a result of its acquisition of Platinum (which had acquired Memco). 

Similarly, there are very few virtual directory vendors.  BMC Software acquired Calendra, Oracle acquired Octet String, and SAP acquired MaXware.  The remaining vendors are Radiant Logic and Symlabs, and they are good targets for IBM, CA, and Sun as they all have WAM systems and LDAP directories that integrate quite nicely with the virtual directories.  Yes, Sun’s directory picked up some limited virtual directory capabilities this year, but the capabilities aren’t competitive with the other products.  More than any other product, virtual directories make IdM projects (e.g., WAM, eSSO, federation) possible because they abstract away the many identity repositories for consuming applications.  The virtual directory enables the vendor to sell more of the products in its suite.

As you may have guessed, there are very few privileged account management vendors.  There are seven vendors in total, with three vendors entering the market this year.  These products restrict access to the password associated with the account by enforcing its checkout and changing it frequently.  Given the products' substantial growth since 2006 due to compliance pressures (the number of customers has at least doubled), the acquisition of Cloakware, Cyber-Ark, or e-DMZ Security by an IdM vendor is a reasonable outcome.

What do you think?  Let us know.

Now that we’ve discussed potential acquisition candidates, two remaining questions come to mind.  We’ll address these questions in a future blog entry.

• Does the continued acquisition of additional products enhance the IdM Suite?

• Was the IdM suite ever meaningful?

Personas Need Reputation, Too! The Idiot’s Guide to Relational Continuity Sockets Layer (RCSL)

Blogger: Mike Neuenschwander

With all the interest in LLP last week, we’re getting a lot of questions about RCSL. For example, the blog team over at Emergent Chaos asks what work we have done on RCSL. I’ve also had several e-mails asking me how RCSL compares to various Internet standards.

So it seems as good a time as any to write up our latest thinking on RCSL. Here it goes.

What is RCSL?

RCSL is a protocol. It doesn’t exist yet; it’s something we’re proposing.

We’re not stuck on the name—think of it as a codename. Kim Cameron claims “the name makes it sound like scientists are still glueing [sic] body parts together in the basement.” Since it’s nearly Halloween, we’ll stick with RCSL at least through October 31st.

Some of RCSL’s characteristics are:

• It enables multiple parties to share a single session

• Sessions can be long-lived (days, weeks, months)

• It emits “claims” based on the outcome of the session, whether broken prematurely, altered, or completed successfully

Why is this interesting? RCSL is the basis for a reputation model for the Internet. It also provides a foundation for resilient, stable relationships and transactions online.

Here’s how it works:

1. Participants are required to ante up collateral to start an RCSL session. How much and of what kind is worked out among the participants. We’re hoping that patterns emerge for common transaction types and that participants can simply point to a template—a.k.a. “game”—with pre-specified rules, roles, and outcomes.
2. RCSL then creates a multi-party session. The RCSL session can be encrypted, but it doesn’t have to be—in some cases you may want others to observe the session. Either way, each participant receives a key to the session. The key also designates the participant’s role in the session.
3. Participants remain in the RCSL session until all parties agree to end the session. The conditions for exit can be predefined, so the session ends automatically when conditions are met. Any changes in the RCSL configuration causes the protocol to generate claims about the change. For example, if someone drops out early or if the collaboration fails, RCSL sends a notification message (a claim—possibly through an RSS feed) to a predetermined aggregator.
4. RCSL aggregators combine RCSL outcomes with other information to establish participants’ ratings.
5. RCSL claims can be used to release escrowed collateral and grant merits of some kind.

Keys to RCSL sessions behave like real-life keys

With RCSL, each participant is given a key to the session. If anyone tampers with the session, the participants are aware of it immediately—it’s like someone budding into a conversation. If the participants welcome the newcomer, RCSL reissues keys to everyone in the session including the new participant. If the participants see the newcomer as an intruder, they can take measures to shut him/her out.

Participants can transfer their role in the session to another entity, but doing so also resets session keys so the new role holder receives a key and the exiting participant is locked out.

Another important feature about RCSL keys is that you know when you’re no longer in possession of one. If you lose an RCSL key or if one is stolen, it will be apparent to the owner. Just like in the real world, if you lose your wallet or cell phone, you usually realize it quickly.

My presentation at Catalyst North America offered a scenario for how RCSL works and I’m doing an encore in Barcelona next week – come check it out. For more background on why RCSL is important, see the Law of Relational Risk—specifically the principle of Relational Continuity.

Identity - Lost in the Standards

Blogger: Kevin Kampman

Last year, there was an initiative launched by the American National Standards Institute (ANSI) and the Better Business Bureau (BBB) to examine ways to prevent identity theft. Last month, I attended a plenary session of the Identity Theft Prevention and Identity Management Standards Panel (IDSP) to learn how this effort was progressing. I was also interested to learn how the needs of consumers are being addressed.

The goal of the IDSP is to develop an inventory of existing standards related to identity. This work has been divided into three areas: Issuance, Exchange, and Maintenance and Management. The attendees came from a variety of communities, including government and standards bodies, financial and credit services, professional services, the software industry, and others.

The inventory of standards and regulations related to identity is impressive. Without diving into details, there are many we know on a regular basis, such as HIPAA and GLB. Many others are more obscure and limited to a particular domain. One would think that with the extensive list of controls, identity would be well understood and articulated.

However, the devil is in the details. For example, some of the regulations, like REAL ID, are mired in political challenges between the state and federal governments. Others, like HSPD-12, are limited to the federal government.

Many identity issues live on the fringes, for example, where no birth certificate was issued, or when someone migrates to the US from another country. Particular vulnerability areas were also identified, such as the exploitation of children by parents or guardians, theft of military or elderly identities, assumption of identities from the deceased, and so on.

Other identity issues stare us directly in the face. I recently spoke with a business intelligence analyst on a cross-country flight. He was quite concerned about how information about our affinity, debit, and credit purchases are aggregated and sold to other parties for unrelated purposes, such as insurance eligibility. The implication is that if you buy a carton of cigarettes or a bottle of liquor, this information will be used without your knowledge to provide or deny coverage, or to identify the rate you’ll pay.

This exchange of so-called personal information may not be covered by privacy regulations and represents an ethical challenge that most people don’t consider, much less care about (until it is used to their disadvantage). Standards that force people to opt-in, rather than to opt-out of this information sharing are sorely lacking, as are the ethical guidelines about what information should be shared for what purpose.

The work being accomplished by the IDSP will go a long way towards exposing what is, and isn’t in place to regulate the use of identity information. The latter will most likely be exposed by unfortunate experiences, tested in the courts, and addressed by the state and federal governments. It would be a significant benefit to everyone if the efforts of the IDSP expose these gaps and inconsistencies and make mitigation recommendations to commercial and government interests.

What the Identity Oracle Isn’t

Blogger: Bob Blakley

Kim Cameron of Microsoft picked up the New York Times’ coverage of our LLP concept in a blog entry today.  His entry is generally excellent, but I’d like to pick on one little piece of it.  In the course of discussing the Burton Group’s identity concepts, Kim writes:

“Bob provides links to more resources, including one on Identity Oracles  - his sexy name for the  claims transformer generating “minimal disclosure tokens”.”

It’s important to be very clear here, so I’m going to say this pretty bluntly.  This statement is utterly and completely wrong.  An Identity Oracle is NOT a “claims transformer generating minimal disclosure tokens”.  It’s not even a claims transformer.  It’s not even a server.  It’s not even technology.

I’ve said twenty times from various stages and in writing on my personal blog and here that as long as we continue to try to solve privacy problems using technology, we are going to continue to fail, and the Internet will continue to lack an identity layer, and it will continue to be a privacy hazard.  Identity and privacy are not technology problems – they’re social, legal, and economic problems – and no technology can solve these problems.

The Identity Oracle is not a technology.  It’s a business.  Its business plan says “We allow people to enjoy the benefits of their identities while protecting them against the risks of misuse of their identities”.   It charges money for its services.  It works like this:

A human – let’s call him “Bob” – signs up for an account with the Identity Oracle.  The Identity Oracle collects some personal information about Bob, and signs a legally binding contract with Bob describing how it will use and disclose the information, and how it will protect the information against uses and disclosures which are not allowed by the contract.  The contract prescribes a set of penalties – if Bob’s information is used in any way which is not allowed by the contract, the Identity Oracle PAYS Bob a penalty: cash money.

When Bob wants to get a service from some giant, impersonal corporation (say “GiCorp”) whose business depends in some way on Bob’s identity, Bob refers GiCorp to the Identity Oracle; GiCorp then goes to the Identity Oracle and asks a question.  The question is NOT a request for Bob’s personal information in any form whatsoever (for example, the question is NOT “What is Bob’s birthdate”). And the Identity Oracle’s response is NOT a “minimal disclosure token” (that is, a token containing Bob’s personal information, but only as much personal information as is absolutely necessary for GiCorp to make a decision about whether to extend the service to Bob – for example a token saying “Bob is over 18”).

Instead, GiCorp’s request looks like this:

“I am allowed to extend service to Bob only if he is above the legal age for this service in the jurisdiction in which he lives.  Am I allowed to extend service to Bob?”

And the Identity Oracle’s response looks like this:

“Yes.”

The Identity Oracle, in normal operation, acts as a trusted agent for the user and does not disclose any personal information whatsoever; it just answers questions based on GiCorp’s stated policies (that is, it distributes only metadata about its users – not the underlying data). 

The Identity Oracle charges GiCorp and other relying-party customers money for its services.  The asset on the basis of which the Identity Oracle is able to charge money is its database of personal information.  Because personal information is its only business asset, the Identity Oracle guards personal information very carefully.

Because disclosing personal information to relying-party customers like GiCorp would be giving away its only asset for free, it strongly resists disclosing personal information to its relying-party customers.  In the rare cases in which relying parties need to receive actual personal data (not just metadata) to do their jobs, the Identity Oracle requires its relying-party customers to sign a legally binding contract stating what they are and are not allowed to do with the information.  This contract contains indemnity clauses – if GiCorp signs the contract and then misuses or improperly discloses the personal information it receives from the Identity Oracle about Bob, the contract requires GiCorp to pay a large amount of cash money to the Identity Oracle, which then turns around and reimburses Bob for his loss.

This system provides Bob with much stronger protection than he receives under national privacy laws, which generally do not provide monetary damages for breaches of privacy.  Contract law, however, can provide any penalty the parties (the Identity Oracle and its relying party customers like GiCorp) agree on.  In order to obtain good liability terms for Bob, the Identity Oracle needs to have a valuable asset, to which GiCorp strongly desires access.  This asset is the big database of personal data, belonging to the Identity Oracle, which enables GiCorp to do its business. And allows the Identity Oracle to charge for its services.

The Identity Oracle provides valuable services (privacy protection and transaction enablement) to Bob, but it also provides valuable services to GiCorp and other relying-party customers.  These services are liability limitation (because GiCorp no longer has to be exposed to private data which creates regulatory liability and protection costs for GiCorp) and transaction enablement (because GiCorp can now rely on the Identity Oracle as a trusted agent when making decisions about what services to extend to whom, and it may be able to get the Identity Oracle to assume liability for transactions which fail because the Oracle gave bad advice).

As long as we keep talking about “claims transformers” (which are computers) instead of “identity providers” and “identity oracles” (which are businesses) we are going to continue to build products nobody uses.  It’s not an accident that there are no commercial consumer identity providers today – no one is paying any attention to how such an entity would make money, and until investors know how they’re going to get paid, nobody is going to go into the Identity business.

The Identity Oracle is a business model for a service which provides consumer identities in a way which simultaneously protects individuals’ privacy and generates revenue for the business investor.  A claims transformer (which is a particular type of server) could be used to carry the “yes” and “no” tokens which the Identity Oracle transmits to its relying-party customers – but many other technologies could carry these “yeses” and “nos” too.  The Identity Metasystem technologies will be successful in the long term if and only if they enable successful business models – and the first step in this enablement is to stop pretending that building the technology is all that’s necessary to build the business.

You can see my original definition of the Identity Oracle here.

Limited Liability Persona in the New York Times

Blogger: Bob Blakley

Yesterday Denise Caruso took up the LLP torch in a New York Times technology section article entitled “Securing Very Important Data: Your Own”.  The article nailed the definition of the LLP, quoting Mike Neuenschwander thus:

To this end, Mr. Neuenschwander and his colleagues have floated the intriguing concept of the L.L.P.: the Limited Liability Persona. This persona would be a legally recognized virtual person in which users could “invest” the financial or identity resources of their choosing. Once their individual personas are created, consumers would be able to use them as their legal “alter ego,” even in financial transactions. “My L.L.P. would have its own mailing address, its own tax ID number, and that’s the information I’d give when I’m online,” Mr. Neuenschwander said.

Melissa Lafsky, the Times’ Freakonomics blogger, has added Denise Caruso’s article to her “FREAK-est” links list under the title “Identity data: the newest hot commodity for businesses”.   

To go beyond self-congratulation for a moment, we’d like to call your attention to another quote in the Times’ article, because Denise Caruso has made a very important point.  She quotes Drummond Reed, who says “The myth is that companies have to know all this information about you in order to do business with you ... [b]ut from a liability perspective, the less I know about my customers the better.”  Drummond might as well be reciting the headlines himself here: it was just last Thursday that the National Retail Federation issued an open letter to the credit card industry asking them to stop putting retailers on the horns of a dilemma by requiring them to store personal data, but then turning around and penalizing them when the stored data is stolen.

LLPs can help protect individuals by giving them identities which contain only a limited amount of personal information.  But they can’t help protect relying parties like retailers who collect, store, and (to some degree) protect personal information.  What’s needed is a whole system of legal constructs and new entities geared toward reducing identity and privacy risk for all parties.  The LLP is part of this equation.  Other parts of the equation are Identity Oracles (which allow relying parties to reduce transaction risk without collecting identity information; we wrote about them here) and a Relational Continuity Sockets Layer (which allows multiple parties to bring only the information and resources which are actually required for a transaction into a controlled environment which is fair and safe for all parties; we wrote about the RCSL here). If you’ve read the Times article and you want to go into more depth, you can see our original LLP coverage here, and we’ll be writing and speaking more about LLPs, Identity Oracles, and the RCSL during the coming months.