These are the final results of the JSR Review Ballot for JSR #351. The Executive Committee for SE/EE has approved this ballot.
JSR351
StageJSR Review Ballot
Ballot durationSep 20, 2011 to Oct 3, 2011
Votes

SE/EE

Credit Suisse
Eclipse Foundation, Inc
Ericsson AB
Fujitsu Limited
Goldman Sachs & Co.
Google Inc.
Hewlett-Packard
IBM
Intel Corp.
Keil, Werner
London Java Community
Oracle
Red Hat
SAP SE
SouJava
VMware
Vote Log

SE/EE

On 2011-09-22 Ericsson AB voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-09-29 Credit Suisse voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-09-30 SAP SE voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-09-30 Red Hat voted Yes with the following comment:
Red Hat's vote is based on the technical merits of this JSR and is not a vote on the licensing terms.  Red Hat would prefer a licensing model that creates an open arena for everyone, including those not members of the JCP and removes any ability for one individual or vendor to exert undue control over a standard. We are an open source company and hence would like to see such a licensing model for JCP contributions. Note however, that this comment is not necessarily directed at the license terms for this JSR, but is a statement of Red Hat's preferred licensing model.
------------------------------------------------------------------------------
On 2011-10-02 Eclipse Foundation, Inc voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-10-03 Keil, Werner voted Yes with the following comment:
While sharing some concerns of London JUG, especially those regarding local, cultural or gender-specific issues not fully covered in the proposal, I hope, the JSR may cover also areas of Single Sign-On and Identity Management where Proliferation and quasi-standards by often competing Open Source projects or Social Networks cause a great risk and reluctance of adoption among Enterprise Users. Although I'm proud about the challenge of rewriting a SAML Identity Provider for WebLogic 8.2 some years ago (the only other known case was in China btw;-) I would prefer if other projects and customers could find an easier way regardless of the product or vendor they chose.
------------------------------------------------------------------------------
On 2011-10-03 IBM voted Yes with the following comment:
IBM's vote is based on the technical merits of this JSR and is not a vote on the licensing terms.  IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage.  We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction. This comment is not necessarily directed at the current business or license terms for this JSR, however, it is a statement of IBM's preferred licensing model.
------------------------------------------------------------------------------
On 2011-10-03 Hewlett-Packard voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-10-03 Intel Corp. voted Yes with no comment.
------------------------------------------------------------------------------
On 2011-10-03 Fujitsu Limited voted Abstain with no comment.
------------------------------------------------------------------------------
On 2011-09-26 Oracle voted Yes with the following comment:
Please note that when JSR 348 is finalized and implemented in Java Community Process version 2.8 (JCP 2.8), we'll transition this JSR to JCP 2.8.
------------------------------------------------------------------------------
On 2011-10-02 London Java Community voted No with the following comment:
JSR 351 attempts to standardise a domain model for identity.  It is unclear why you would need to standardise the entire domain model, instead of leaving this in the arena of the application programmer. Even if you're in favour of standardising common domain models such as this, the present form of JSR 351 has several very
serious problems.

Firstly it's very US-centric, e.g. references to social security numbers.  Other countries use different identifying codes, for example
the National Insurance number in the UK (and many countries have no unique number identifier which would be equivalent to an SSN).  It is also unspecified as to what the format of bank account numbers are. In this instance even though there is an international bank identifier, it is rarely used by people when describing their accounts.

Several of the identity attributes JSR 351 mentions (e.g, nationality and gender) are incredibly difficult to define in a manner that is
unambiguous, accurate and precise. For example, gender is not simply a male/female choice. There are other possibilities which need to be taken into account, for example the possibility that a person doesn't consider themselves to be aligned with any specific gender (this last possibility is under serious consideration for codification into a number of national data standards, for example the Australian Passport Authority). This poses concerns given the proposed integration of the standard into the Java security model.  The expert group should seriously consider the implications of, for example, people being unable to access medical treatment due to security policies predicated upon gender.

Within the current model, the standardisation is then very weak, as validation of fields becomes almost impossible, and the "standard" degrades to simply being a collection of fields with very bland data types, most of which need to be optional. This is hardly the basis for an effective standard.

There are numerous secondary issues - as an example we think that the connectivity piece of the API has the potential to rapidly become a
kitchen-sink api, as it tries to cater for connecting to everywhere ("FaceBook Connect, OpenID Connect, and OAUTH 2.0").

We recommend that this JSR be withdrawn - in its current from we do not consider it fit for purpose, and recommend that these issues are instead explored in an open source project led by interested parties (with full community involvement) which is not considered a standards
track project at this time. 

This JSR could be reconsidered for submission when some of these issues have been worked out, but at this time it is not suitable for consideration as a standard and should be rejected.
------------------------------------------------------------------------------