To help to clarify why I asked those questions (and my chain of thought) here are two extra entries with my personal opinion. The first one is a post that that I started writing a couple days ago, and the 2nd one, is a response I just posted on the SC-L and esapi-user mailing lists:
1st one (note that some of the questions asked here are already answered in some of the comments to the original post)
My position is that ESAPI is a great example of what an enterprise security API should look like. But we have to be very careful when we say 'use ESAPI', because we risk that people actually use ESAPI on their applications (i.e. download the jar and copy it into their application, and use it)
I think we need to be careful to do this recommendation for several reasons. The first one is that when we say 'use EASPI', we are basically positioning ESAPI in competition with all the other frameworks (including J2EE in this case, for the Java side of things).
The second one is we have to provide much more visibility to the bits of ESAPI that are ready to be used in production. My understanding is that there are a lot of modules in ESAPI and not all of them have the same level or quality or readiness.
Some of our target audience is going to be developers without a lot of experience in application security, but who want to implement their security controls/features right, So we have to be very, very clear, whether we are providing them with the right advice on ESAPI, namely on which modules are actually enterprise-ready. (for ex: Is it just the encoding module or the logging module? Or is the authentication module also ready for enterprise or application use?)
For me, part of the solution is to explicitly break ESAPI into three parts.
The first one is the interfaces. Basically, the security controls that an ESAPI API or ESAPI compliant framework should have.
The second one should be a reference implementation(s), which is what we have today (and is the one that should be commercially supported by third parties).
The third one, are unit tests for the interfaces. This is a bit where I'm actually quite interested, and I call these the ESTAPI, which is the Enterprise Security Testing API.
With the ESTAPI, I'll be able to run these tests against all supported frameworks, whereby for each framework, all I need are little connecters between the ESAPI interface and the particular framework functionality/behaviour. Then we will be able to test the frameworks for their security capabilities. I think this will actually provide a much more pragmatic and much more objective analysis of the framework, allow the mapping of the supported security controls & behaviour, and allow the framework's clients to have much more visibility into what's happening on those frameworks.
Again, I don't want to put ESAPI down. I think ESAPI is a great project. I think it's one of the most successful and powerful projects for OWASP and we just need to clarify it a little bit. In fact, I think the more successful ESAPI is, the more this becomes a problem. I don't think ESAPI has blown up yet because ESAPI hasn't reached a wide level of adoption by software developers or commercial applications.
Remember that one day we will have to deal with the problems of applications built on top of ESAPI that have security vulnerabilities or that are being successfully compromised by malicious hackers.
2nd one (posted on on mailing lists)