Date   

Re: Expert Group meeting this week, or next?

Rudy De Busscher
 

For me all the proposed days are possible.

Rudy

On 18 July 2017 at 22:45, Ivar Grimstad <ivar.grimstad@...> wrote:

Monday/Tuesday early evening CET next week works for me.

Ivar


On Tue, 18 Jul 2017, 23:41 Arjan Tijms, <arjan.tijms@...> wrote:
Hi,

This Thursday/Friday would be less ideal for me, but next week Monday/Tuesday would be fine. Indeed early in the evening CET would work best for me at least.

Kind regards,
Arjan Tijms




On Tue, Jul 18, 2017 at 10:16 PM, Will Hopkins <will.hopkins@...> wrote:
Perhaps ... what's a Doodle?

On 07/18/2017 02:35 PM, Werner Keil wrote:
Most of those sound OK for me (assuming it's clear which one gets picked in the end;-)

Could we use a Doodle?

Werner

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


--

Java Champion, JCP EC/EG Member, JUG Leader



Re: Moving to Java EE Github?

Will Hopkins
 

I think I'm about ready to migrate the repos to the javaee organization.

If anyone has work in flight that will be disrupted, please let me know. Otherwise, I'll plan to do the migration sometime tomorrow (Wednesday, 7/19).

The plan is to migrate as follows:
  • security-spec -> javaee/security-spec
    • issues are already there (migrated from java.net)
    • migrate the source only, using git clone
    • recreate releases based on migrated tags at the destination
    • will lose pull-request history, but should preserve everything else we need.
git clone --bare $GITHUB_URL_OLD_REPO
cd <repo-name>.git
git push --mirror $GITHUB_URL_NEW_REPO
  • security-api -> javaee/security-api
    • use github "transfer" function to migrate entire repo
  • soteria -> javaee/security-ri-soteria
    • use github "transfer function to migrate  entire repo
    • rename repo when transfer completes

I'll make a full (bare) clone of each repo before transferring it.

Seem like a reasonable plan?

Will




On 07/11/2017 02:21 PM, Werner Keil wrote:
Ok, let us know, if you need any help by those who have the necessary rights.

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Re: Soteria Updates for PFD Changes

Arjan Tijms
 

Hi,

On Tue, Jul 18, 2017 at 10:54 PM, Will Hopkins <will.hopkins@...> wrote:

  • EL support -- Arjan, I know most of that is done -- is it finished for all annotations? Anything left to do there (ignoring DatabaseIdentityStoreDefinition.hashAlgorithm for a moment)?

EL support for all attributes is implemented now. Could do with more test coverage, but unless I missed something I think this is done.

DatabaseIdentityStoreDefinition.hashAlgorithm is there largely too. It now accepts an EL string -> string method expression. The bean where that method resides can get its parameters from whatever location is suitable for the user. To make it really complete a simple key/value list can be added to the annotation so parameters can be specified right from the annotation.

 
  • Changes to the LdapIdentityStoreDefinition -- I see that the new attribute values have been picked up, does the behavior match what's expected per the updated javadoc, or does that need to be investigated/updated?  It doesn't look, for example, like search scopes are supported, or group lookup via memberOf attribute (using caller DN from CredentialValidationResult).

The implementation of any new attributes has not been done. I renamed the existing one to match the PFD and EL enabled all of them, but that's it.

 
  • Changes to DatabaseIdentityStoreDefinition, primarily support for default hash algorithm? I think we actually need something better here than is spec'd, so probably best not to do more work on hash algorithm right now.

See above. Hashing is now being done, but could be fleshed out a bit more.
 
  • Changes to notifyContainerAboutLogin() to support expected behavior for caller vs. app principals? Looks like that's not done, or not fully done, though the signature changes have been made.
I think the RI (GlassFish/Soteria) doesn't need to make any additional changes here, as its defaults already work (in GlassFish the caller/app principal would already be the same, as it returns from HttpServletRequest#getUserPrincipal etc what the CallerPrincipalCallBack from JSR 196 puts into it).

Other servers can, when necessary, implement this in their own way. I'll walk through the spec text and code again to see whether I didn't miss anything for the RI.

 
  • The changes to use AuthenticationException instead of AuthException look like they're complete.
Yes, that's been taken care of.
 
  • Anything else anyone knows of?

As far as RI matching spec text, I think the above list is complete. 

The spec text could perhaps do with some clarifications, specifically as Rudy mentioned in another topic the LoginToContinue. Reading the spec I think theoretically everything is there, but it's terse and vendors may not fully interpret it as intended.

Kind regards,
Arjan Tijms


 

Thanks,

Will

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803



Re: LDAP Annotation and Database Hashing Proposal

Will Hopkins
 

Hi Arjan,

Thanks for implementing this. I've actually been spending some time thinking about this as well, and was about to make a proposal -- didn't realize you were working on it, too -- and I wonder if it would be better to simply specify a named CDI bean as the hash function? It's simpler (I think) than specifying an expression, which seems like overkill when all we want to do is enable users to indicate a hashing implementation.

Also, I think it's probably better to specify a verify(password, hashedPassword) function -- which does the compare internally -- rather than leave it up to the DatabaseIdentityStore implementation to do the compare. That allows the author of the hash algorithm to, e.g., implement a constant-time compare function, to guard against timing attacks. Better, I think, to abstract all aspects of the crypto.

Thoughts?

(I also have some comments on the PBFDF2 parameters chosen.)

Will

On 07/18/2017 05:06 PM, Arjan Tijms wrote:
Hi,

I just did an initial implementation of the EL method expression proposal for the hash function and the default PBKDF2 hash.

See: https://github.com/javaee-security-spec/soteria/commit/7b7432794a493a186295d3e87211943e48f30502

The code looks as follows:

    if (hasAnyELExpression(dataBaseIdentityStoreDefinition.hashAlgorithm())) {
            ELContext elContext = CdiUtils.getELProcessor().getELManager().getELContext();
            
            MethodExpression hashMethodExpression = ExpressionFactory.newInstance().createMethodExpression(
                elContext, 
                dataBaseIdentityStoreDefinition.hashAlgorithm(), 
                String.class, new  Class<?>[] {String.class} );
            
            hashFunction =  s -> (String) hashMethodExpression.invoke(elContext, new Object[] {s});
        } else if ("PBKDF2".equals(dataBaseIdentityStoreDefinition.hashAlgorithm())) {
            hashFunction = s -> pbkdf2(s, salt);
        } else {
            hashFunction = identity();
        }

The Expression Language part creates a MethodExpression from the expression, which it then invokes via a lambda.

In the validate() method that lambda is called as follows:

  List<String> passwords = executeQuery(
            dataSource, 
            dataBaseIdentityStoreDefinition.callerQuery(),
            usernamePasswordCredential.getCaller()
        ); 
        
        String hashedPassword = hashFunction.apply(usernamePasswordCredential.getPasswordAsString());
        
        if (!passwords.isEmpty() && hashedPassword.equals(passwords.get(0))) {


The following shows an example of how application code uses this:

@DatabaseIdentityStoreDefinition(
    dataSourceLookup="${'java:global/MyDS'}", 
    callerQuery="#{'select password from caller where name = ?'}",
    groupsQuery="select group_name from caller_groups where caller_name = ?",
    hashAlgorithm = "#{applicationConfig.doHash}"
)
@ApplicationScoped
@Named
public class ApplicationConfig {
 
    public String doHash(String in) {
        return in; // can do anything here and get parameters from wherever
    }
    
}




The PBKDF2 hash is implemented as follows:

    public String pbkdf2(String password, byte[] salt) {
        try {
            return 
                Base64.getEncoder()
                      .encodeToString(
                          SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1")
                                          .generateSecret(
                                             new PBEKeySpec(password.toCharArray(), salt, 1024, 64 * 8))
                                          .getEncoded());
            
        } catch (NoSuchAlgorithmException | InvalidKeySpecException e) {
            throw new IllegalStateException(e);
        }
    }

Here we need some extra options to specify parameters, basically the salt and the number of iterations. I think the easiest way would be to have a key/value list called "hashAlgorithmParameters" or something in the annotation.

For example:

     * <p>
     *  Parameters are specified using the format:
     *  <i>parameterName=parameterValue</i>  with one parameter per array element.
     * <p>
 
     */
    String[] hashAlgorithmParameters() default {};

Thoughts?



-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Re: LDAP Annotation and Database Hashing Proposal

Arjan Tijms
 

Hi,

I just did an initial implementation of the EL method expression proposal for the hash function and the default PBKDF2 hash.

See: https://github.com/javaee-security-spec/soteria/commit/7b7432794a493a186295d3e87211943e48f30502

The code looks as follows:

    if (hasAnyELExpression(dataBaseIdentityStoreDefinition.hashAlgorithm())) {
            ELContext elContext = CdiUtils.getELProcessor().getELManager().getELContext();
            
            MethodExpression hashMethodExpression = ExpressionFactory.newInstance().createMethodExpression(
                elContext, 
                dataBaseIdentityStoreDefinition.hashAlgorithm(), 
                String.class, new  Class<?>[] {String.class} );
            
            hashFunction =  s -> (String) hashMethodExpression.invoke(elContext, new Object[] {s});
        } else if ("PBKDF2".equals(dataBaseIdentityStoreDefinition.hashAlgorithm())) {
            hashFunction = s -> pbkdf2(s, salt);
        } else {
            hashFunction = identity();
        }

The Expression Language part creates a MethodExpression from the expression, which it then invokes via a lambda.

In the validate() method that lambda is called as follows:

  List<String> passwords = executeQuery(
            dataSource, 
            dataBaseIdentityStoreDefinition.callerQuery(),
            usernamePasswordCredential.getCaller()
        ); 
        
        String hashedPassword = hashFunction.apply(usernamePasswordCredential.getPasswordAsString());
        
        if (!passwords.isEmpty() && hashedPassword.equals(passwords.get(0))) {


The following shows an example of how application code uses this:

@DatabaseIdentityStoreDefinition(
    dataSourceLookup="${'java:global/MyDS'}", 
    callerQuery="#{'select password from caller where name = ?'}",
    groupsQuery="select group_name from caller_groups where caller_name = ?",
    hashAlgorithm = "#{applicationConfig.doHash}"
)
@ApplicationScoped
@Named
public class ApplicationConfig {
 
    public String doHash(String in) {
        return in; // can do anything here and get parameters from wherever
    }
    
}




The PBKDF2 hash is implemented as follows:

    public String pbkdf2(String password, byte[] salt) {
        try {
            return 
                Base64.getEncoder()
                      .encodeToString(
                          SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1")
                                          .generateSecret(
                                             new PBEKeySpec(password.toCharArray(), salt, 1024, 64 * 8))
                                          .getEncoded());
            
        } catch (NoSuchAlgorithmException | InvalidKeySpecException e) {
            throw new IllegalStateException(e);
        }
    }

Here we need some extra options to specify parameters, basically the salt and the number of iterations. I think the easiest way would be to have a key/value list called "hashAlgorithmParameters" or something in the annotation.

For example:

     * <p>
     *  Parameters are specified using the format:
     *  <i>parameterName=parameterValue</i>  with one parameter per array element.
     * <p>
 
     */
    String[] hashAlgorithmParameters() default {};

Thoughts?



Soteria Updates for PFD Changes

Will Hopkins
 

EG,

Trying to get a sense of how much work is left to get soteria updated to match the PFD version of the spec. A good chunk is already done, but I'd like to check on the following items, and will create JIRA issues for them if needed:
  • EL support -- Arjan, I know most of that is done -- is it finished for all annotations? Anything left to do there (ignoring DatabaseIdentityStoreDefinition.hashAlgorithm for a moment)?
  • Changes to the LdapIdentityStoreDefinition -- I see that the new attribute values have been picked up, does the behavior match what's expected per the updated javadoc, or does that need to be investigated/updated?  It doesn't look, for example, like search scopes are supported, or group lookup via memberOf attribute (using caller DN from CredentialValidationResult).
  • Changes to DatabaseIdentityStoreDefinition, primarily support for default hash algorithm? I think we actually need something better here than is spec'd, so probably best not to do more work on hash algorithm right now.
  • Changes to notifyContainerAboutLogin() to support expected behavior for caller vs. app principals? Looks like that's not done, or not fully done, though the signature changes have been made.
  • The changes to use AuthenticationException instead of AuthException look like they're complete.
  • Anything else anyone knows of?

Thanks,

Will

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Re: Expert Group meeting this week, or next?

Ivar Grimstad
 

Monday/Tuesday early evening CET next week works for me.

Ivar


On Tue, 18 Jul 2017, 23:41 Arjan Tijms, <arjan.tijms@...> wrote:
Hi,

This Thursday/Friday would be less ideal for me, but next week Monday/Tuesday would be fine. Indeed early in the evening CET would work best for me at least.

Kind regards,
Arjan Tijms




On Tue, Jul 18, 2017 at 10:16 PM, Will Hopkins <will.hopkins@...> wrote:
Perhaps ... what's a Doodle?

On 07/18/2017 02:35 PM, Werner Keil wrote:
Most of those sound OK for me (assuming it's clear which one gets picked in the end;-)

Could we use a Doodle?

Werner

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


--

Java Champion, JCP EC/EG Member, JUG Leader


Re: Expert Group meeting this week, or next?

Arjan Tijms
 

Hi,

This Thursday/Friday would be less ideal for me, but next week Monday/Tuesday would be fine. Indeed early in the evening CET would work best for me at least.

Kind regards,
Arjan Tijms




On Tue, Jul 18, 2017 at 10:16 PM, Will Hopkins <will.hopkins@...> wrote:
Perhaps ... what's a Doodle?

On 07/18/2017 02:35 PM, Werner Keil wrote:
Most of those sound OK for me (assuming it's clear which one gets picked in the end;-)

Could we use a Doodle?

Werner

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803



Re: Expert Group meeting this week, or next?

Will Hopkins
 

Perhaps ... what's a Doodle?

On 07/18/2017 02:35 PM, Werner Keil wrote:
Most of those sound OK for me (assuming it's clear which one gets picked in the end;-)

Could we use a Doodle?

Werner

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Re: Expert Group meeting this week, or next?

Werner Keil
 

Most of those sound OK for me (assuming it's clear which one gets picked in the end;-)

Could we use a Doodle?

Werner


Expert Group meeting this week, or next?

Will Hopkins
 

EG:

I'd like to meet again, either late this week (Thursday/Friday) or early next week (Monday/Tuesday)

It seems like early afternoon EDT/early evening CET works best for most; please reply with preferred days/times. If there's not a clear consensus I'll ask someone to put up a survey like someone did for the one in April.

Thanks,

Will
-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Re: Java EE Security.next and JWT (JSON Web Tokens)

Arjan Tijms
 

Hi,

On Wednesday, July 12, 2017, Werner Keil <werner.keil@...> wrote:
com.google.api.client.auth.oauth2.TokenResponse

For anything that could become part of an official JSR deliverable, that doesn't sound so good;-/

Indeed, which was the most important reason to not include it as-is ;)
 
Agorava also used Scribe in the initial draft phase, but it was changed, so other than CDI compliant DeltaSpike the only thing that is not fully based on Java EE would be Jackson right now.
PicketLink, but IMO all relevant aspects of PicketLink are now found in JSR 375/Soteria, so porting https://github.com/agorava/agorava-core/tree/develop/agorava-picketlink to use Soteria should be extremely easy. The Oauth part is already there independent of Google or other libraries.

Sounds cool ;)
 

Kind Regards,
Werner


Re: Java EE Security.next and JWT (JSON Web Tokens)

Werner Keil
 

com.google.api.client.auth.oauth2.TokenResponse

For anything that could become part of an official JSR deliverable, that doesn't sound so good;-/
Agorava also used Scribe in the initial draft phase, but it was changed, so other than CDI compliant DeltaSpike the only thing that is not fully based on Java EE would be Jackson right now.
PicketLink, but IMO all relevant aspects of PicketLink are now found in JSR 375/Soteria, so porting https://github.com/agorava/agorava-core/tree/develop/agorava-picketlink to use Soteria should be extremely easy. The Oauth part is already there independent of Google or other libraries.

Kind Regards,
Werner


Re: Java EE Security.next and JWT (JSON Web Tokens)

Arjan Tijms
 

Hi,

I would also assume that only the consuming part is needed as an authentication mechanism.

The typical use is to authenticate with Facebook, Google and Twitter. Another OAuth2 client example that's already based on Soteria: https://github.com/omnifaces/soteria-google-oauth-client

Kind regards,
Arjan Tijms


On Wed, Jul 12, 2017 at 6:43 PM, Werner Keil <werner.keil@...> wrote:
For the consuming part have a look at http://www.agorava.org/ (created by CDI Spec Lead Antoine and myself as a result of a "Social" JSR being turned down by the EC and to succeed Seam Social)
Except Mockito there are very few parts that are not based on standards or can be under Java EE 8 (with a little work Jackson Binding can be replaced by JSON-B 1.0)

CDI (1.1) and JAX-RS 2.0 are already used.

Werner



Re: Java EE Security.next and JWT (JSON Web Tokens)

Werner Keil
 

For the consuming part have a look at http://www.agorava.org/ (created by CDI Spec Lead Antoine and myself as a result of a "Social" JSR being turned down by the EC and to succeed Seam Social)
Except Mockito there are very few parts that are not based on standards or can be under Java EE 8 (with a little work Jackson Binding can be replaced by JSON-B 1.0)

CDI (1.1) and JAX-RS 2.0 are already used.

Werner


Re: Java EE Security.next and JWT (JSON Web Tokens)

Will Hopkins
 

In terms of OAuth2, I don't think it's a case of standing up an authorization server, it's more a case of being able to consume OAuth2 access tokens, as distinct from OpenID Connect identity tokens. Support for access tokens, especially (or perhaps exclusively) for JAX-RS applications, would presumably be very popular. Access tokens bring with them a certain amount of complexity, though, as they involve two distinct "subjects" (application client, resource owner) and an authorization model involving claims (scopes) asserted by the authorization server, that the resource server must honor. Since claims are app-specific, there's also an implied requirement for out-of-band configuration exchange with the authorization server, which would be useful to automate in some way (maybe something like SAML2 metadata?), and resource servers/apps probably need some type of configuration to describe the format/content of tokens they're willing/able to consume.

On 07/11/2017 05:43 PM, David Blevins wrote:
A few thoughts:

  - Crypto: It’s only the extended policy files (JCE) that are restricted.  The JVM has rsa-sha256 built-in, so we’re good.  JWTs support anything, but we’d have an opinionated perspective and say “the server must support verifying an RSA-SHA256 signed JWT”.  Anything else could be vendor specific (aka open to being a requirement later).

  - OAuth2: I’m not sure it makes sense for us to “include” OAuth 2.0.  Specifically, the app server issuing OAuth 2.0 access tokens is not a pattern I see anyone doing or on the horizon.  What I see is people propping up OAuth 2.0 gateways in front of their LDAP server.  These OAuth 2.0 servers are issuing JWT tokens with a “snapshot” of LDAP data, they are signed by the OAuth 2.0 Gateway.  More and more the server is not the one performing the token grant with the Gateway and obtaining the JWT access token.  It’s often being done by the browser via javascript or the mobile device, after which point the token is passed with all calls.  The app server needs only to check the signature to verify the JWT when a request comes in with an "Authentication: Bearer <the jwt access token>” header.  This can be done with a RSA public key provided by the OAuth 2.0 Gateway.

The short version, IMO, our job is really just to require the server can verify the token.  Ideally with an additional requirement that the server support being able to map fields from the json map (the token’s payload) to answer “isCallerInRole” and “getCallerPrincipal” calls.

I think if we got that far, we’d be good for several years.



-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Re: Java EE Security.next and JWT (JSON Web Tokens)

David Blevins
 

A few thoughts:

- Crypto: It’s only the extended policy files (JCE) that are restricted. The JVM has rsa-sha256 built-in, so we’re good. JWTs support anything, but we’d have an opinionated perspective and say “the server must support verifying an RSA-SHA256 signed JWT”. Anything else could be vendor specific (aka open to being a requirement later).

- OAuth2: I’m not sure it makes sense for us to “include” OAuth 2.0. Specifically, the app server issuing OAuth 2.0 access tokens is not a pattern I see anyone doing or on the horizon. What I see is people propping up OAuth 2.0 gateways in front of their LDAP server. These OAuth 2.0 servers are issuing JWT tokens with a “snapshot” of LDAP data, they are signed by the OAuth 2.0 Gateway. More and more the server is not the one performing the token grant with the Gateway and obtaining the JWT access token. It’s often being done by the browser via javascript or the mobile device, after which point the token is passed with all calls. The app server needs only to check the signature to verify the JWT when a request comes in with an "Authentication: Bearer <the jwt access token>” header. This can be done with a RSA public key provided by the OAuth 2.0 Gateway.

The short version, IMO, our job is really just to require the server can verify the token. Ideally with an additional requirement that the server support being able to map fields from the json map (the token’s payload) to answer “isCallerInRole” and “getCallerPrincipal” calls.

I think if we got that far, we’d be good for several years.


--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
310-633-3852

On Jul 11, 2017, at 10:59 AM, Will Hopkins <will.hopkins@oracle.com> wrote:

It's indeed to late to add JWT support, or OpenID Connect, or OAuth2. ;)

Regarding encryption, wouldn't it be feasible to depend on crypto libraries without actually delivering them? I.e., say, "This API and RI works when the Xyz crypto lib is present, compatible versions are X, available from Y. Please obtain these libraries before attempting to use this JSR"? It would probably be fairly straightforward to keep crypto out of the API itself.

Will

On 07/11/2017 09:36 AM, Werner Keil wrote:
Actually JetBrains mentioned something like OpenID only, which they hopefully mean "OpenID Connect" since OpenID in its original form is long dead?;-)

I also abstained on JSR 310 both in the Public Draft (https://jcp.org/en/jsr/results?id=5603) and PFD. Due to issues, of which only the lack of ISO 8601 standard support was properly resolved.
While circular dependencies between TemporalAmount and RI element Duration were not resolved (on the ohter hand, the DateTimeFormatter returns only API level abstract Temporal types, not concrete final classes, so it is quite inconsistent and most importantly makes an independent implementation totally impossible)

After talking to Antoine at JavaOne he said, that server-side OAuth or OpenID Connect support would be very hard to accomplish in the brief timeframe EE 8 was given.
Arjan also highlighted, that OAuth, JWT, etc. depend on cryptography and the list of countries, that do not allow cryptography is rather long: https://en.wikipedia.org/wiki/Restrictions_on_the_import_of_cryptography#Status_by_country
(I gave a talk on JSR 321, Trusted Java at JavaOne Russia, but I did not do a live demo because using a TPM chip is illegal there;-)

Therefore adding crypto-libraries to Soteria/Glassfish by default could mean a lot of trouble for this JSR and products based on it.
Not sure, if they ever can be official parts of the RI in the future, or this will be entirely up to 3rd party vendors and open source projects.

That is among the reasons, why "security-samples" and similar extensions are probably as important as Soteria itself, if not more.

Kind Regards,
Werner
--
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Released javax.security.enterprise-api version 1.0-b07

Will Hopkins
 

Artifacts are now published in the "releases" repository at maven.java.net.
-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Re: EC Vote and Proposed Final Draft submitted to JCP

Guillermo González de Agüero
 

Great news Will and thanks to everyone involved on this. There's only one step left!


Regards,

Guillermo González de Agüero


El mar., 11 de julio de 2017 20:30, Will Hopkins <will.hopkins@...> escribió:
A couple of announcements:
  • The Public Review Ballot passed, with 21 yes votes, 1 no vote, and 3 who didn't vote at all. The no vote was from JetBrains; I have reached out to them to ensure I understand their concerns, and to let them know that at least some of their concerns have already been addressed.
  • I've also released a PFD version of the spec and API, tagged 1.0-b06 in GitHub, and submitted it to the JCP. I would have liked more time for the EG to review, but I'm on a tight schedule. I'm aware of at least one error in the spec, so we may need to publish an update.
With that in mind, I would encourage everyone to read the updated spec/javadoc (attached/linked to this email) and comment, using the subject, "Proposed Final Draft Comments from <name>", but please limit comments to issues that represent significant errors, omissions, or limitations that affect the API's usability -- adding new functionality is not an option at this point! ;)
Thanks for everyone's help in resolving the last few technical issues. I plan to spend this week working on migrating the repos into the Java EE organization and cleaning up JIRAs.

Will
-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Re: EC Vote and Proposed Final Draft submitted to JCP

Will Hopkins
 

With the spec attached, this time, and javadoc linked: https://www.dropbox.com/s/1bq7n8sz25eyfcb/jsr375-javadoc-1.0-b07-pfd.zip?dl=0.

On 07/11/2017 02:30 PM, Will Hopkins wrote:
A couple of announcements:
  • The Public Review Ballot passed, with 21 yes votes, 1 no vote, and 3 who didn't vote at all. The no vote was from JetBrains; I have reached out to them to ensure I understand their concerns, and to let them know that at least some of their concerns have already been addressed.
  • I've also released a PFD version of the spec and API, tagged 1.0-b06 in GitHub, and submitted it to the JCP. I would have liked more time for the EG to review, but I'm on a tight schedule. I'm aware of at least one error in the spec, so we may need to publish an update.
With that in mind, I would encourage everyone to read the updated spec/javadoc (attached/linked to this email) and comment, using the subject, "Proposed Final Draft Comments from <name>", but please limit comments to issues that represent significant errors, omissions, or limitations that affect the API's usability -- adding new functionality is not an option at this point! ;)
Thanks for everyone's help in resolving the last few technical issues. I plan to spend this week working on migrating the repos into the Java EE organization and cleaning up JIRAs.

Will
-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

341 - 360 of 736