ACTION REQUIRED: JSR-375 Expert Group


Bill Shannon
 

Will Hopkins wrote on 08/10/17 06:17 PM:
Bill,

So the category of "trivial" changes you describe corresponds to the description of errata in your JCP Processes writeup?
No, the kinds of trivial changes that might be make between FAB and Final Release are a small subset of errata.

That being the case, what JCP process applies to errata? I didn't see a reference to it on the process or spec lead pages (though I didn't do a deep dive). Is errata something I can just do? Does it get vetted or approved somehow? How do I document it (i.e., with a change list or something)?
As the page says:

Which process do I use for which change?

We always use the Maintenance Release process for spec errata.



Lastly, would acknowledgements fall into the category of errata? I'd like to acknowledge Alex Kosowski's role as spec lead getting the JSR off the ground.
I would consider that a trivial change.


Will Hopkins
 

Bill,

So the category of "trivial" changes you describe corresponds to the description of errata in your JCP Processes writeup?

That being the case, what JCP process applies to errata? I didn't see a reference to it on the process or spec lead pages (though I didn't do a deep dive). Is errata something I can just do? Does it get vetted or approved somehow? How do I document it (i.e., with a change list or something)?

Lastly, would acknowledgements fall into the category of errata? I'd like to acknowledge Alex Kosowski's role as spec lead getting the JSR off the ground.

Will

On 08/04/2017 04:26 PM, Bill Shannon wrote:
Arjan Tijms wrote on 08/ 2/17 02:05 PM:
As a reminder, the API Javadoc is also an integral part of the spec text.

In particular this means that after the submission this is totally frozen too and not even things like typos, formatting or even line endings can be changed anymore.
As Will explained, the materials submitted to the JCP aren't exactly the final versions since at least things like the license and the version number will change, and we have to allow for the possibility that the vote will fail and larger changes will be required.

We use our best engineering judgment when deciding whether to fix other "trivial" bugs such as typos, formatting, or line endings.

That said, many of the comments in this thread go beyond trivial obvious fixes, and would require at least a JCP errata MR to update the document without changing the spec requirements or version.

See my definition of errata in my JCP Processes writeup.


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


Bill Shannon
 

Arjan Tijms wrote on 08/ 2/17 02:05 PM:
As a reminder, the API Javadoc is also an integral part of the spec text.

In particular this means that after the submission this is totally frozen too and not even things like typos, formatting or even line endings can be changed anymore.
As Will explained, the materials submitted to the JCP aren't exactly the final versions since at least things like the license and the version number will change, and we have to allow for the possibility that the vote will fail and larger changes will be required.

We use our best engineering judgment when deciding whether to fix other "trivial" bugs such as typos, formatting, or line endings.

That said, many of the comments in this thread go beyond trivial obvious fixes, and would require at least a JCP errata MR to update the document without changing the spec requirements or version.

See my definition of errata in my JCP Processes writeup.


Will Hopkins
 

Werner,

Just to make sure I've captured the net result of your feedback after discussion, the one change you'd now propose is to add a referenced to JDBC 4 in Section 3.5, in relation to the @DatabaseIdentityStoreDefinition?

Can you be more specific about the version? To Arjan's point about CDI, using a a version that's supported in EE 7 makes Soteria more portable. Looking at the JSR-221 page, looks like an MR is in process now that wants to be JDBC 4.3, and the EE 7 platform spec seems to reference JDBC 4.1 (the way the spec is written doesn't make it easy to see at a glance which versions of various specs it requires; all I found is that JDBC drivers used with EE 7 must be JDBC 4.1 compliant).

I've add this to the issue I have tracking these potential changes: https://github.com/javaee/security-spec/issues/62, so please confirm I've got it correctly.

Will

On 08/03/2017 06:33 AM, Werner Keil wrote:
I saw, these exist in multiple places, so Servlet and EJB are mentioned in different chapters like 4.5

Nevertheless, I believe JDBC 4 should be mentioned and a reference added in 3.5 as the  @DatabaseIdentityStoreDefinition.
is part of chapter 3.

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


Will Hopkins
 

Thanks, David!

On 08/03/2017 01:04 AM, David Blevins wrote:
Hi Will,

I think the JSR is overall a step forward and I support it.

Like Arjan I also have a “too bad this missed the boat” list item.  When the spec launched in 2015, the need for JWTs were a bit fuzzy.  At some point between then and now their need became crystal clear.  I kick myself in the butt for not coming back and pushing for them sooner while there was still time :)

We will live to fight another day, what we have is a solid foundation, you’ve been an great lead and I really look forward to the next round!


-- 
David Blevins
310-633-3852

On Aug 1, 2017, at 4:29 PM, Will Hopkins <will.hopkins@...> wrote:

FYI, this message was also sent directly to EG members.


-------- Forwarded Message --------
Subject: ACTION REQUIRED: JSR-375 Expert Group
Date: Tue, 1 Aug 2017 19:26:38 -0400
From: Will Hopkins <will.hopkins@...>
To:


Expert Group:

I am preparing to submit the attached draft of the JSR-375 spec for a Final Approval Ballot. As part of the process, I need to confirm that the Expert Group agrees the JSR is ready to go to Final Release.

Members of the Expert Group, please reply to this mail to confirm that you agree the JSR is ready. Agreement will be assumed for Expert Group members who do not respond within 24 hours.

Thanks,

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
<jsr375-spec-1.0-fab.pdf>


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


Arjan Tijms
 


On Thu, Aug 3, 2017 at 12:14 PM, Werner Keil <werner.keil@...> wrote:
In 2.5 of the Spec, was referring to CDI 1.2, not 2.0 (which is included in Java EE 8 and Final by now) on page 22 deliberate?

The dependencies are also Java EE 7, so as the minimum version for CDI it sounds OK.

Indeed. I think this came up during one of the calls or perhaps on the list (can't quite remember) as well. We would have loved to take advantage of some of the CDI 2.0 features, but in the end it didn't happen. So everything is exclusively based on Java EE 7 APIs, perhaps unfortunately, but the upside is that the RI can be used on existing EE 7 servers as well.

Kind regards,
Arjan


 



Werner Keil
 

I saw, these exist in multiple places, so Servlet and EJB are mentioned in different chapters like 4.5

Nevertheless, I believe JDBC 4 should be mentioned and a reference added in 3.5 as the  @DatabaseIdentityStoreDefinition.
is part of chapter 3.


Werner Keil
 

Chapter 3.5 of the spec IMO is missing references to Servlet (it already exists and linked in the text as  [SERVLET31]), EJB (same for [EJB32]) and possibly JDBC 4 (JSR 221) as a default data source is used in @DatabaseIdentityStoreDefinition.

None are significant show-stoppers, but would be nice to have them in a final 1.0 version of the spec.

I should be able to fill out my OCA, but if others could factor that into the spec faster, please do.

Werner


Werner Keil
 

In 2.5 of the Spec, was referring to CDI 1.2, not 2.0 (which is included in Java EE 8 and Final by now) on page 22 deliberate?

The dependencies are also Java EE 7, so as the minimum version for CDI it sounds OK.


Werner Keil
 

It could be done via a MR, but especially in Java EE those things always take a bit before they get into updates of the umbrella standard or new products.


David Blevins
 

Hi Will,

I think the JSR is overall a step forward and I support it.

Like Arjan I also have a “too bad this missed the boat” list item.  When the spec launched in 2015, the need for JWTs were a bit fuzzy.  At some point between then and now their need became crystal clear.  I kick myself in the butt for not coming back and pushing for them sooner while there was still time :)

We will live to fight another day, what we have is a solid foundation, you’ve been an great lead and I really look forward to the next round!


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

On Aug 1, 2017, at 4:29 PM, Will Hopkins <will.hopkins@...> wrote:

FYI, this message was also sent directly to EG members.


-------- Forwarded Message --------
Subject: ACTION REQUIRED: JSR-375 Expert Group
Date: Tue, 1 Aug 2017 19:26:38 -0400
From: Will Hopkins <will.hopkins@...>
To:


Expert Group:

I am preparing to submit the attached draft of the JSR-375 spec for a Final Approval Ballot. As part of the process, I need to confirm that the Expert Group agrees the JSR is ready to go to Final Release.

Members of the Expert Group, please reply to this mail to confirm that you agree the JSR is ready. Agreement will be assumed for Expert Group members who do not respond within 24 hours.

Thanks,

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
<jsr375-spec-1.0-fab.pdf>


Will Hopkins
 

Thanks, Arjan.

I'll add these mistakes to an issue I created to today to track a couple other typos.

My understanding is we may have an opportunity to correct that sort of mistake during/after the final ballot process. We can't change the substance of the document, but, at a minimum, the license text needs to be updated, and I've been given the impression it would be permissible to fix typos, etc. It's also possible that objections will be raised during the ballot that would need to be addressed.

Will

On 08/02/2017 06:40 PM, Arjan Tijms wrote:
Hi,

The JSR is ready in my opinion.

We have largely achieved what we wanted to achieve, and the things that were not done are such that they can be done in a next release. It's somewhat of a personal regret of me that we didn't get to specify the additional planned methods for the SecurityContext (specifically the login() method), and that the CDI/JSR375 version of @RolesAllowed was not incorporated.

Nevertheless, these omissions in no way take away from the core value of the current work or influence its readiness for the JSR to be released.

A few small things here and there in the JSR would not have been my first choice, but as the JCP is of course about consensus and compromises, I can absolutely live with the versions of those things about which we reached consensus.

So overall I'm really happy with the result :)

As for the spec document, there's a few small additional things I noticed, but nothing major:

>This chapter overview information and terminology related to this specification, and also includes a general requirements not specified elsewhere in this document. 

This sentence doesn't read so well.

I guess it should be something like: "This chapter contains an overview of information ..."  and "includes general requirements ..."


>
 validateRequest() will be invoked before the doFilter() method of any servlet filter or the service() method of any servlet in the application for requests to constrained as well as to unconstrained resources, and, in addition, in response to application code calling the authenticate() method on the HttpServletRequest

For completeness this should maybe include SecurityContext as well.

On page 21

>
 if (status.equals(IN_PROGRESS)) {
              facesContext.responseComplete();
          }
I just noticed this, but we forgot to update this status to the renamed version; "SEND_CONTINUE". As it's only an example it's not critical, but still...

Kind regards,
Arjan Tijms



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


Arjan Tijms
 

Hi,

The JSR is ready in my opinion.

We have largely achieved what we wanted to achieve, and the things that were not done are such that they can be done in a next release. It's somewhat of a personal regret of me that we didn't get to specify the additional planned methods for the SecurityContext (specifically the login() method), and that the CDI/JSR375 version of @RolesAllowed was not incorporated.

Nevertheless, these omissions in no way take away from the core value of the current work or influence its readiness for the JSR to be released.

A few small things here and there in the JSR would not have been my first choice, but as the JCP is of course about consensus and compromises, I can absolutely live with the versions of those things about which we reached consensus.

So overall I'm really happy with the result :)

As for the spec document, there's a few small additional things I noticed, but nothing major:

>This chapter overview information and terminology related to this specification, and also includes a general requirements not specified elsewhere in this document. 

This sentence doesn't read so well.

I guess it should be something like: "This chapter contains an overview of information ..."  and "includes general requirements ..."


>
 validateRequest() will be invoked before the doFilter() method of any servlet filter or the service() method of any servlet in the application for requests to constrained as well as to unconstrained resources, and, in addition, in response to application code calling the authenticate() method on the HttpServletRequest

For completeness this should maybe include SecurityContext as well.

On page 21

>
 if (status.equals(IN_PROGRESS)) {
              facesContext.responseComplete();
          }
I just noticed this, but we forgot to update this status to the renamed version; "SEND_CONTINUE". As it's only an example it's not critical, but still...

Kind regards,
Arjan Tijms



Arjan Tijms
 

As a reminder, the API Javadoc is also an integral part of the spec text.

In particular this means that after the submission this is totally frozen too and not even things like typos, formatting or even line endings can be changed anymore.


Will Hopkins
 

FYI, this message was also sent directly to EG members.


-------- Forwarded Message --------
Subject: ACTION REQUIRED: JSR-375 Expert Group
Date: Tue, 1 Aug 2017 19:26:38 -0400
From: Will Hopkins <will.hopkins@...>
To:


Expert Group:

I am preparing to submit the attached draft of the JSR-375 spec for a Final Approval Ballot. As part of the process, I need to confirm that the Expert Group agrees the JSR is ready to go to Final Release.

Members of the Expert Group, please reply to this mail to confirm that you agree the JSR is ready. Agreement will be assumed for Expert Group members who do not respond within 24 hours.

Thanks,

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