William Vambenepe's blog

Here we go again. Yet another institution who “takes the protection of [my] personal information very seriously” wrote to me to let me know that they lost some unencrypted backup tapes with my SSN and everything. In a way I’d prefer if they said that they don’t take the protection of my personal information seriously. Because now I have to assume that they are incompetent even at the tasks they take seriously, which presumably also includes performing financial transactions (it’s a bank). That they plead dumbness rather than carelessness kind of scares me.

Well, not really. This letter is just damage control of course and whatever reassuring verbiage they put doesn’t mean anything. Everyone is just playing pretend, which is how this whole “identify theft” problem started (”we’ll pretend that the SSN is confidential information and that we can use it to authenticate people”).

A few months ago I wrote that it is now safe to steal my identity because the credit watch service provided by Fidelity following their similar screw-up (laptop stolen from a car that time) had expired. Of course the new breach comes with two years of credit monitoring, courtesy of the incompetent bank.

So here is yet another reason to not buy credit monitoring services (in addition to the fact that they don’t work and that you can get the same thing for free): it’s only a matter of months before the next breach and the free two years of credit monitoring that will ensue.

Note to whoever stole the laptop of a Fidelity employee two years ago, with personal information (SSN and more) for everyone enrolled in HP’s retirement plan: it is now safe to make use of the information. Congratulations on being patient.

I received an email telling me that the “credit watch” service in which all affected HP employees (and ex-employees) were enrolled for free has expired. Of course, we are invited to start paying Equifax to keep it running. $65 per year (and that’s supposedly a discounted rate, mind you, half the “normal” price) to run a DB query once a week on my behalf. Not bad. I should be in that business.

In what ways is the lost data less dangerous two years later? The “1 or 2 years of free credit watch” offer that is typical after events such security violations is obviously just a PR move to allow the guilty party to look like they are taking responsibility for their embarrassing display of incompetence. And it probably costs them very little, if anything, to provide this, considering how good a customer acquisition strategy it is for the “credit watch” department of the credit agencies. The fact that Fidelity and their pears don’t have to bear any real cost for this is the reason why it keeps happening.

If I sound a bit detached about this, it’s not that I am not worried about someone impersonating me by using my SSN and birth date. It’s just that I am not more worried about that specific laptop theft than I am about the hundreds of employees at medical offices, dental offices, insurances companies, banks etc that already have access to this information.

The solution is to publish every single SSN on a web site and stop pretending they can be used for authentication.

[UPDATED 2008/7/7: One more name in the long list of companies that have (often through a subcontractor) leaked so-called "personal" information about their employees. It's only news because the employer is Google and anything Google-related is for some reason considered newsworthy. Danny is kind to be appreciative for the one year of free credit monitoring. It probably costs Google close to nothing. Which is why Google and the others don't really care about the problem.]

With the Oracle announcements at the RSA conference this month (things like Oracle Role Manager and this white paper), the Identity Governance Framework (IGF) is back in the news. And since HP publicly released the Governance Interoperability Framework (GIF) earlier this year, there is some potential for confusion between the two (akin to the OSGi/OGSI confusion). I am not an author or even an expert in either, but I know enough about both that I can at least help reduce the confusion.

They are both frameworks, they are both about governance, they both try to enable interoperability, they both define XML formats, they were both privately designed and they are both pushed by their authors (and supporters) towards standardization. To add to the confusion, Oracle is listed as a supporter of HP’s GIF and HP is listed as a supporter of Oracle’s IGF.

And yet they are very different.

GIF is an attempt to address SOA governance, which mostly relates to the lifecycle of services and their artifacts (like WSDL, XSD and policies). So you can track versions, deployment status, ownership, dependencies, etc. HP is making the specification available to all (here but you need to register) and has talked about submission to a standards body but as far as I know this hasn’t happened yet.

IGF is a set of specifications and APIs that pull access policy for identity related information out of the application logic and into well-understood XML declarations. With the goal of better controlling the flow of such information. The keystones are the CARML specification used to describe what identity related information an application needs and its counterpart the AAPML specification, used to describe the rules and constraints that an application puts on usage of the identity-related information it owns. The framework also defines relevant roles and service interfaces. Unlike GIF, which is still controlled by HP, IGF is now under the control of the Liberty Alliance Project. Oracle is just one participant (albeit a leading one).

Could they ever meet?

A Web service managed through a GIF-like SOA governance system could have policies related to accessing identity-related information, as addressed by IGF (and realized through CARML and AAPML elements). GIF doesn’t really care about the content of the policies. Studying the positions of the IGF and GIF specifications relative to WS-Policy would be a good way to concretely understand how they operate at a different level from one another. While there could theoretically be situations in which IGF and GIF are both involved, they do not do the same thing and have no interdependency whatsoever.

[UPDATED 2008/4/18: Phil Hunt (co-author of IGF) has a blog where he often writes about IGF. He also wrote a good overview of IGF and its applicability to governance and SOX-style compliance.]

Rumors prompted me to do a Google search on << HP “identity management” exit >>. The second resulting link brought confirmation in the form of this Burton Group article.

From the article, HP is not declaring “end of life” on its IDM products (the “Select” family, made up of Select Access, Select Audit, Select Federation and Select Identity) but they are restricting them to the current customers rather than going after new ones. Which sounds like an end of life, albeit a slow one that gives customers plenty of time to plan and execute their transition. Good for HP, because that’s one area in which you really don’t want to make precipitous decisions (as sometimes happens when an IDM effort is kicked off as a result of a negative security event).

My first reaction is to wonder what this means for my ex-colleagues, including the IDM people I sat next to (most of them from the Trustgenix acquisition) and the remotes ones I interacted with in the context of HP’s software standards strategy (Jason Rouault and Archie Reed, both well-known and respected in the corresponding standards efforts). These are all smart people so I am sure they’ll find productive work either in HP or outside (the IDM domain is booming).

My second reaction is puzzlement. This move is not very surprising from the point of view of the market success and financial returns of HP’s IDM suite so far. But it is a lot more surprising in the context of HP’s BTO strategy. I am sure they realize the importance of IDM in that context, I guess they must have decided that they can do it based on partner products rather than HP products. Hopefully they can maintain the expertise even without further developing products.

The Burton Group article quotes Eric Vishria, “HP Software Vice President of Products”. Based on his title I would have been in his organization so I would have known him if he had been there when I was at HP. Which tells me that he probably came from the Opsware acquisition, soon after I left. The Opsware people now have a lot of influence in HP Software and it looks like they are not shying away from bold moves.

[UPDATED 2008/5/22: HP appears to have struck a deal to migrate its IDM users to Novell.]

As far as I can tell, Flash is an advertising delivery platform for the Web. This is why I have not installed the Flash player in my Firefox browser. It saves me (especially when combined with the Adblock Plus Firefox add-on) from a lot of obnoxious animations. And a few security vulnerabilities too, (this latest one is what prompted me to write this quick entry to help readers protect themselves while retaining the option to use Flash).

Despite all the hype about Flash, I very rarely run into a page that requires it for something useful. A few sites are Flash-only (mostly restaurant web sites from my experience, apparently restaurant owners are easy preys for incompetent Web site designers) and when I find one I usually take that as a sign that I am saving myself a lot of frustration by taking my business elsewhere.

Still, once a while I need to view a Flash applet. Ideally, I would like to have Flash installed but disabled, such that I can enable it for a given page with a single click. This doesn’t seem to be possible (my guess is that Adobe knows very well that Flash is mostly used in ways that are not welcomed by users and that they would likely disable it most of the time if given the option). So here is a convenient way to achieve the same effect:

While I have not installed the Flash player in Firefox, I have installed it in IE. I have also installed the IE Tab Firefox add-on which allows one to switch from the Firefox rendering engine to the IE rendering engine within a given Firefox tab. It can be configured to place a small icon in the status bar. Clicking on that icon switches the rendering engine, which means that suddenly the Flash player is enabled for the page you are looking at. One-click enable/disable as requested!

You can also configure IE Tab to automatically switch to IE rendering for some pre-configured sites. So if there are Flash-dependent sites that you use on a regular basis, just enter them there and the IE rendering engine will automatically be used whenever you are on those sites. Again, this all happens inside your Firefox tab, it doesn’t start a separate IE browser. Enjoy.

[UPDATED on 2007/12/24: I wrote this entry to try to help readers and it turns out I am the one who's getting helped after all. Many commenters pointed to the Flashblock firefox add-on which is designed specifically to do what I get done in a round-about way with IE Tab. I looked for such an add-on some time ago and didn't find it, which is why I devised the work-around. Thank you all for the info.]

[UPDATED 2008/5/14: Another reason to keep Flash turned off: Crossdomain.xml Invites Cross-site Mayhem.]

[UPDATED 2008/6/9: Looks like Flashblock can be circumvented (in a way that my more basic FF vs IE setup cannot). BTW, I closed comments on this entry because for some reason it was attracting a lot more comment spam than all the others combined. Email me (see about page) if you want to post a comment here.]

… because the issue has been mixed up with the whole terrorism/DHS hysteria. Game over. So now we have “Real ID” which won’t stop any terrorist but somehow is marketed as an anti-terrorist measure. I don’t like this law because it is too focused on physical identification (ID card) and not virtual identification. Trying to impersonate someone in person is difficult, dangerous (you risk being arrested on the spot or at least having your face captured by a security camera) and doesn’t scale. Doing it virtually is easy, safe and scales (you can even do it from anywhere in the world, including places where labor is cheap and the FBI doesn’t reach much). So this is where the focus should be. Also, this law is not respectful of privacy (the “unencrypted bar code” issue, even though if someone really wanted to systematically capture name and address from ID cards today they could take a picture of the ID and OCR it, the Real ID-mandated bar code would only make things a little easier).

On the other hand, I also can’t go along with the detractors of this law when they go beyond pointing out its shortcomings and start ranting about this creating a national ID card. While it’s true that this is what it effectively does, someone needs to explain to me why this is bad and why this would make the US a “police state”. If really such IDs are so damaging to liberties, why is it ok for every state to have them? What makes a national ID more dangerous than a state ID?

I agree that the Real ID effort is a bad cost/benefit trade off in terms of protection against terrorism. But leaving terrorism aside, we do need a robust (not necessarily perfect) way to authenticate people to access bank accounts and other similar transactions. In that respect, something like Real ID is needed. And in that context, the cost/benefit trade-off can be hugely positive if you think of how much impersonation costs and how much friction it creates in the country’s economy.

As long as we live in denial about what a Social Security number represents and as long as we can’t think sanely about terrorism, there can’t be an answer to the authentication problem.

An article in today’s New York Times reports that “the Social Security numbers of tens of thousands of people who received loans or other financial assistance from two Agriculture Department programs were disclosed for years in a publicly available database”.

Almost there folks! But tens of thousands is not enough, we need to cover everyone. The simplest effective way to dent the “identity-theft” (or more exactly “impersonation”) wave is to go beyond this first step and publish on a publicly accessible web site all social security numbers ever issued and the associated names. And get rid once and for all of the hypocritical assumption that SSN have any authentication value. We need a reliable authentication infrastructure (either publicly-run as a government service or privately-run, that’s a topic for another day) and this SSN-based comedy is preventing its emergence by giving credit issuers (and others) a cheap and easy way to pretend that they have authenticated their customers.

Over the last couple of years, I have received two alerts that my SSN and other data have been “compromised” (one when Fidelity lost a laptop containing data about everyone enrolled in HP’s retirement plan and one from a university) and my wife has received three. Doesn’t this sound like a bad joke going on for too long (and I should know about bad jokes going on for too long, they are my specialty)? And of course this doesn’t count the thousands of employees at dentist, medical offices, and many other businesses that have at some point had access to my data (and anybody else’s).

So, to the IT people at the Census Bureau I say “keep going”! But of course that’s not the reaction they had. The rest of the NY Times articles goes on with the usual hypocritical (or uninformed) lamentations about putting people’s identities at risk. “We took swift action when this was brought to our attention, and took the information down.” says an Agriculture Department spokeswoman. And of course there is the usual “credit report monitoring” offer (allowing the credit report agencies to benefit from both sides of the SSN-for-authentication debacle). Oblivious to the reality even though it manifests itself further down in the article: “The database [...] is used by many federal and state agencies, by researchers, by journalists and by other private citizens to track government spending. Thousands of copies of the database exist.”

Another quote from the article: “Federal agencies are under strict obligations to limit the use of Social Security numbers as an identifier”. The SSN is a fine identifier. It’s using it as a mean of authentication that’s the problem.

[UPDATE] This is now a Slashdot thread. The comments are pouring in. Some get it (like here, and here). This one seems to get it too but then goes on to advocate dismantling the social security system which at this point is only connected by name to the issue at hand.

[UPDATED 2008/7/2: Sigh, sigh and more sigh while reading this article. The cat is so far out of the bag that a colony of mice has taken residency in it. The goal shouldn't be to try to make the SSN hard to get, it should be to make it useless to criminals. That approach isn't even mentioned in the article.]

WSRF/CDL/WS-Addressing complexity used as a security barrier? Ouch!

The question recently came back on the WS-Addressing mailing list of whether Reference Parameters can/should be used as the SOAP equivalent of cookies. Something more along the lines of session management than addressing. See Peter Hendry’s email for a clear description of his use case. The use case is reasonable but I don’t think this is what WS-Addressing is really for as I explain in bullet #3 of this post. What interested me more was the response that came from Conor Cahill and his statement that AOL is implementing an “EndpointReferenceUpdate” element that can be returned in the response to tell the sender to update the EPR. I am not fond of this as a mechanism for session management, but I can see one important benefit of this mechanism: getting hold of a “good” EPR for more efficient addressing. Here is an example application:

Imagine a Web services that represents the management interface of a business process engine. That Web service provides access to all the currently running business process instances in the engine (think Service Group if you’re into WSRF). Imagine that this Web service supports a SOAP header called “target” and that header is defined to contain an XPath statement. When receiving a message containing a “target” header, the Web service will look for the (for the sake of simplicity let’s assume there can only be one) business process instance for which this XPath statement returns “true” when evaluated on the XML representation of the state of the business process instance. And the Web service will then interpret the message to be targeted at that business process instance. This is somewhat similar to WS-Management’s “SelectorSet”. A sender can use this mechanism to address a specific business process instance based on the characteristics of that instance (side note: whether the sender understands and builds this header itself or whether it gets it as a Reference Parameter from an EPR is orthogonal). But this can be a very expensive dispatching mechanism. The basic implementation would require the Web service to evaluate an XPath statement on each and every business process instance state document. Far from optimal. This is where Conor’s “EndpointReferenceUpdate” can come in handy. After doing once the XPath evaluation work of finding out which business process instance the sender wants to address, the Web service can return a more optimized EPR to be used to address that instance, one that is a lot easier to dispatch on. This kind of scenario is a lot more relevant in my perspective to the work of the WS-Addressing working group than the session example.

An important consequence of a mechanism such as “EndpointReferenceUpdate” is that it makes it critical that the Web service be able to tell which SOAP headers are in the message as a result of being in the EPR used by the sender and which ones were added by the sender on purpose. For example, if a SOAP message comes in with headers “a”, “b” and “c” and the Web service assumes that “a” and “b” were in the EPR and “c” was added by the invoker, then the new EPR returned as part of “EndpointReferenceUpdate” will only be a replacement for “a” and “b” and the Web service will still expect “c” to be added by the sender. But if in fact “c” also came from a reference parameter in the EPR used by the sender then follow-up messages will be incomplete. This puts more stress and responsibilities on the already weak @isReferenceParameter attribute. And, by encouraging people to accept EPRs from more and more sources, it puts EPR consumers are even greater risk for the problems described in bullet (1) of this objection.

EPR (Endpoint References, from WS-Addressing) are a shiny and exciting toy. But a sharp one too. So here is my contribution to try to prevent fingers from being cut and eyes from being poked out.

So far I have seen EPRs used for five main reasons, not all of them very inspired:

1) “Dispatching on URIs is not cool”

Some tools make it hard to dispatch on URI. As a result, when you have many instances of the same service, it is easier to write the service if the instance ID is in the message rather than in the endpoint URI. Fix the tools? Nah, let’s modify the messages instead. I guess that’s what happens when tool vendors drive the standards, you see specifications that fit the tools rather than the contrary. So EPRs are used to put information that should be in the URI in headers instead. REST-heads see this as a capital crime. I am not convinced it is so harmful in practice, but it is definitely not a satisfying justification for EPRs.

2) “I don’t want to send a WSDL doc around for just the endpoint URI”

People seem to have this notion that the WSDL is a “big and static” document and the EPR is a “small and dynamic” document. But WSDL was designed to allow design-time and run-time elements to be separated if needed. If all you want to send around is the URI at which the service is available, you can just send the URI. Or, if you want it wrapped, why not send a soap:address element (assuming the binding is well-known). After all, in many cases EPRs don’t contain the optional service element and its port attribute. If the binding is not known and you want to specify it, send a around a wsdl:port element which contains the soap:address as well as the QName of the binding. And if you want to be able to include several ports (for example to offer multiple transports) or use the wsdl:import mechanism to point to the binding and portType, then ship around a simplified wsdl:descriptions with only one service that itself contains the port(s) (if I remember correctly, WS-MessageDelivery tried to formalize this approach by calling a WSRef a wsdl:service element where all the ports use the same portType). And you can hang metadata off of a service element just as well as off of an EPR.

For some reason people are happy sending an EPR that contains only the address of the endpoint but not comfortable with sending a piece of WSDL of the same size that says the same thing. Again, not a huge deal now that people seem to have settled on using EPRs rather than service elements, but clearly not a satisfying justification for inventing EPRs in the first place.

3) “I can manage contexts without thinking about it”

Dynamically generated EPRs can be used as a replacement for an explicit context mechanism, such as those provided by WS-Context and WS-Coordination. By using EPRs for this, you save yourself the expense of supporting yet-another-spec. What do you loose? This paper gives you a detailed answer (it focuses on comparing EPRs to WS-Context rather than WS-Coordination for pretty obvious reasons, but I assume that on a purely technical level the authors would also recommend WS-Coordination over EPRs, right Greg?). In a shorter and simplified way, my take on the reason why you want to be careful using dynamic EPRs for context is that by doing so you merge the context identifier on the one hand and the endpoint with which you use this context on the other hand into one entity. Once this is done you can’t reliably separate them and you loose potentially valuable information. For example, assume that your company buys from a bunch of suppliers and for each purchase you get an EPR that allows you to track the purchase as it is shipped. These EPRs are essentially one blob to you and the only way to know which one comes through FedEx versus UPS is to look at the address and try to guess based on the domain name. But you are at the mercy of any kind of redirection or load-balancing or other infrastructure reason that might modify the address. That’s not a problem if all you care about is checking the ETA on the shipment, each EPR gives you enough information to do that. But if you also want to consolidate the orders that UPS is delivering to you or if you read in the paper about a potential UPS drivers strike and want to see how it would impact you, it would be nice to have each shipment be an explicit context Id associated to a real service (UPS or FedEx), rather than a mix of both at the same time. This way you can also go to UPS.com, ask about your shipments and easily map each entry returned to an existing shipment you are tracking. With EPRs rather than explicit context you can’t do this without additional agreements.

The ironic thing is that the kind of mess one can get into by using dynamic EPRs too widely instead of explicit context is very similar in nature to the management problems HP OpenView software solves. Discovery of resources, building relationship trees, impact analysis, event correlation, etc. We do it by using both nicely-designed protocols/models (the clean way) and by using heuristics and other hacks when needed. We do what it takes to make sense of the customer’s system. So we could just as well help you manage your shipments even if they were modeled as EPRs (in this example). But we’d rather work on solving existing problems and open new possibilities than fix problems that can be avoided. And BTW using dynamic EPRs is not always bad. Explicit contexts are sometimes overkill. But keep in mind that you are loosing data by bundling the context with the endpoint. Actually, more than loosing data, you are loosing structure in your data. And these days the gold is less in the raw data than in its structure and the understanding you have of it.

4) “I use reference parameters to create new protocols, isn’t that cool!”

No it’s not. If you want to define a SOAP header, go ahead: define an XML element and then describe the semantics associated with this element when it appears as a SOAP header. But why oh why define it as a “reference parameter” (or “reference property” depending on your version of WS-A)? The whole point of an EPR is to be passed around. If you are going to build the SOAP message locally, you don’t need to first build an EPR and then deconstruct it to extract the reference parameters out of it and insert them as SOAP headers. Just build the SOAP message by putting in the SOAP headers you know are needed. If your tooling requires going through an EPR to build the SOAP message, fine, that’s your problem, but don’t force this view on people who may want to use your protocol. For example, one can argue for or against the value of WS-Management’s System and SelectorSet as SOAP headers, but it doesn’t make sense to define those as reference parameters rather than just SOAP headers (readers of this blog already know that I am the editor of the WSDM MUWS OASIS standard with which WS-Management overlaps so go ahead and question my motives for picking on WS-Management). Once they are defined as SOAP headers, one can make the adventurous decision to hard-code them in EPRs and to send the EPRs to someone else. But that’s a completely orthogonal decision (and the topic of the fifth way EPRs are used - see below). But using EPRs to define protocols is definitely not a justification for EPRs and one would have a strong case to argue that it violates the opacity of reference parameters specified in WS-Addressing.

5) “Look what I can do by hard-coding headers!”

The whole point of reference parameters is to make people include elements that they don’t understand in their SOAP headers (I don’t buy the multi-protocol aspect of WS-Addressing, as far as I am concerned it’s a SOAP thing). This mechanism is designed to open a door to hacking. Both in the good sense of the term (hacking as a clever use of technology, such as displaying Craig’s list rental data on top of Google maps without Craig’s List or Google having to know about it), and in the bad sense of the term (getting things to happen that you should not be able to make happen). Here is an example of good use for reference parameters: if the Google search SOAP input message accepted a header that specifies what site to limit the search on (equivalent to adding “site:vambenepe.com” in the Google text box on Google.com), I could distribute to people an EPR to the vambenepe.com search service by just giving them an EPR pointing to the Google search service and adding a reference parameter that corresponds to the header instructing Google to limit the search to vambenepe.com.

Some believe this is inherently evil and should be stopped, as expressed in this formal objection. I think this is a useful mechanism (to be used rarely and carefully) and I would like to see it survive. But there are two risks associated with this mechanism that people need to understand.

The first risk is that EPRs allow people to trick others into making statements that they don’t know they are making. This is explained in the formal objection from Anish and friends as their problem #1 (”Safety and Security”) and I agree with their description. But I don’t agree with the proposed solutions as they prevent reference parameters to be treated by the service like any other SOAP header. Back last November I made an alternative proposal, using a wsa:CoverMyRearside element that would not have this drawback and I know other people have made similar proposals. In any case, this risk can and should be addressed by the working group before the specification becomes a Recommendation or people will stop accepting to process reference parameters after a few high-profile hacks. Reference parameters will become the ActiveX of SOAP.

The second risk is more subtle and that one cannot be addressed by the specification. It is the fragility that will result from applications that share too many assumptions. I get suspicious when someone gives me directions to their house with instructions such as “turn left after the blue van” or “turn right after the barking dog”, don’t you? “We’re the house after the green barn” is a little better but what if I want to re-use these directions a few years later. What’s the chance that the barn will be replaced or repainted? EPRs that contain reference parameters pose the same problem. Once you’ve sent the EPR, you don’t know how long it will be around, you don’t know who it will get forwarded to, you don’t know what the consumer will know. You need to spend at least as much efforts picking what data you use as a reference parameter (if anything) as you spend designing schemas and WSDL documents. If your organization is smart enough to have a process to validate schemas (and you need that), that same process should approve any element that is put in a reference parameter.

Or you’ll poke your eye out.