These are the final results of the JSR Review Ballot for JSR #85. The Executive Committee for SE/EE has not approved this ballot.

JSR85

StageJSR Review Ballot

Ballot durationSep 26, 2000 to Oct 9, 2000

Votes

SE/EE

Accenture

Apache Software Foundation

Apple Computer, Inc.

BEA Systems

Borland Software Corporation

Caldera Systems

Cisco Systems

Compaq Computer Corporation

Fujitsu Limited

Hewlett-Packard

IBM

Lea, Doug

Oracle

Progress Software

Sun Microsystems, Inc.

WebGain

Vote Log

SE/EE

On 2000-10-09 Borland Software Corporation voted No with the following comment:
We don't believe that adding a rules based authorization system can be made simple enough for users and furthermore, it eliminates the possibility of using simpler authorization models. It should also be possible to map the current permission based system into a rules based system where role memberships are dynamically determined
based on rules and policies.
------------------------------------------------------------------------------
On 2000-10-09 Fujitsu Limited voted No with the following comment:
Fujitsu supports the opinion expressed by Sun and IBM and requests the Spec Lead to submit two JSRs.
------------------------------------------------------------------------------
On 2000-10-09 Oracle voted No with the following comment:
Oracle concurs with the reasons given by Sun and IBM.  We are particularly concerned about the complexity of the security APIs in general and this JSR in particular.  This vote notwithstanding, Oracle supports exploration of rule-based security within the JCP.
------------------------------------------------------------------------------
On 2000-10-09 Compaq Computer Corporation voted No with the following comment:
For reasons given by Sun and IBM
------------------------------------------------------------------------------
On 2000-10-09 Hewlett-Packard voted No with the following comment:
HP votes "no" for the same reasons identifed by Sun and IBM.
------------------------------------------------------------------------------
On 2000-10-09 Caldera Systems voted No with the following comment:
Caldera agrees with the previous comments concerning the dividing up of this JSR.
------------------------------------------------------------------------------
On 2000-10-09 BEA Systems voted No with the following comment:

BEA concurs that this initiative would be better treated as two seperate JSRs---one for auditing and one for rules-based authorization.

BEA is in favor of extending the J2EE security model to support rules-based authorization (an increasingly common customer request), but would like to see more clarity around the relationship between such a new JSR and the existing Java security specifications (i.e., the issue Sun raised).
------------------------------------------------------------------------------
On 2000-10-09 IBM voted No with the following comment:
This JSR needs to be split into 2  as there are two large topics included, each of which needs different kinds of expertise.  We believe that there should be one JSR for rules based authorization and one for audit.  We strongly recommend that the JSR be re-written and re-submitted as 2 JSRs.  In addition our other concerns are:

The JSR points out that EJB and JAAS have conflicting security models.  We disagree, as JAAS can be used to implement a J2EE security model with  additional classes.  We are concerned where this comment may be leading and would like to understand more.
While we agree that there may be a need for rules-based policies, we are very concerned about the added complexity and believe this needs serious debate and discussion. We need to carefully think through the value of adding a lot of complexity to the security model, if the flexibility is worth the added  complexity or will it just cause programmers to take another approach to avoid the complexity.
------------------------------------------------------------------------------
On 2000-10-07 Sun Microsystems, Inc. voted No with the following comment:
  The Java platform security APIs are already quite complex and
  it is not clear how this proposal will interact with the existing
  APIs.  The proposed "rule based" security appears useful, but it
  is not clear that it is important enough to be implemented as a
  core J2EE platform API.  Instead, it may be better to clarify the
  J2EE security model so as to allow such facilities to be added
  by third parties.  The J2EE security model is specified in the
  J2EE Platform Specification (JSR-058).  Any updates to the J2EE
  security model should be handled as part of that umbrella JSR.
------------------------------------------------------------------------------
On 2000-10-03 Progress Software voted Yes with no comment.
------------------------------------------------------------------------------