Re: JetBrains' concerns with JSR-375


Will Hopkins
 

EG:

Forwarding this mail from JetBrains, with their permission. They are happier with the PFD spec, but did provide a list of concerns they have. They understand that it will be difficult to make any non-trivial changes to the spec at this point, but I think it's worth us reviewing the list to see if there's anything we want to do differently, and to respond to the concerns.

Will


-------- Forwarded Message --------
Subject: Re: JetBrains' concerns with JSR-375
Date: Thu, 27 Jul 2017 14:07:32 -0400
From: Will Hopkins <will.hopkins@...>
To: Trisha Gee <trisha.gee@...>
CC: Jeff Tancill <jeff.tancill@...>, Sergey Vasiliev <sergey.vasiliev@...>


Thanks Trisha (and Sergey).

This is very helpful feeback. Indeed, many (not all) of these questions have been discussed in the EG.

At this point, I think it makes sense to include the entire EG in the conversation. Can I forward this to the EG mailing list? Alternatively, if you (or Sergey) would like to send your concerns directly to the list, that might facilitate a more direct conversation.

Please note that, while we value the feedback, and may still be able to make small changes to the language of the spec, we are now just days away from our date to submit FAB materials. We would need a very compelling reason to make any non-trivial change to the API, and doing so would almost certainly cause us to miss our dates -- which would have a follow-on effect for the entire EE 8 release.

Regards,

Will

On 07/27/2017 12:12 PM, Trisha Gee wrote:
Hi Will,

I'd like to introduce you to Sergey Vasiliev (CC'd) who's a member of the JetBrains JCP working group.  Sergey has the most concerns around JSR-375, I'm going to list the main ones here, but Sergey is probably the best person to ask if you need further clarification.

The spec for JSR-375 is quite good, it will work, the Java EE community needs it, but there are a number of areas that seem like possible places for bugs or errors which made us uncomfortable with a "yes" vote.
  • Core IdentityStore interface: in the IntelliJ IDEA API we don’t accept commits with interfaces like: there are 2 methods, you could implement the first, the second or both and provide the third method that returns what was really implemented. Are there other alternatives? E.g. splitting into multiple interfaces?
  • It looks strange to have in IdentityStore "Set<String> getCallerGroups(CredentialValidationResult validationResult)” and "Set<String> getCallerGroups()" in CredentialValidationResult. It has been explained, it will work, but implementers have to remember all details, it looks like a place for potential bugs. 
  • What is the rule for naming caller groups? Potential issues we can foresee include duplicates, conflicts, non-related group invocations, etc.  
  • Annotations: @LdapIdentityStoreDefinition contains 20+ attributes.  Is it likely some bean will need all these non default attribute values? It could lead to some difficult-to-read code
  • “Chapter 2: Authentication mechanism” describes the HttpAuthenticationMechanism interface and "is specified only for use in the Servlet container". Isn't this more an extension of Servlet 3.x specification?
  • IdentityStore priority: “Lower numbers represent higher priority”. But “getPriority()” methods in the JDK (Thread, AWT) have “higher numbers for higher priority”.  The IntelliJ API, Spring, Hibernate and other frameworks use the same concept.  Is “lower numbers for higher priority” is used in OS threads? Or what's the reasoning behind this decision?
If you have further questions about the feedback, please feel free to contact Sergey directly, or myself. And we'll be more than happy to either receive email clarification on the questions, or links to relevant discussions in the mailing list archives - we acknowledge we're late to the process and that some (or all) of these points may have been discussed previously.  Of course, any confusion we have may also be shared by end users!

Thanks once again for reaching out and trying to understand our issues.

Trisha

On Tue, Jul 25, 2017 at 7:15 PM Will Hopkins <will.hopkins@...> wrote:
Great, thanks for letting me know. We actually have a couple more tweaks planned for an updated PFD that should be available shortly, I'll forward that along when it's ready.

Let us know if anything further comes up.


Will


On 07/25/2017 06:33 AM, Trisha Gee wrote:
Those who had concerns with the spec are much happier with the updated version.  I *still* haven't had more detailed feedback from those who had concerns (sorry), I will give them a poke.

On 23 July 2017 at 23:08, Will Hopkins <will.hopkins@...> wrote:
Hi Trisha,

Just wanted to touch base and see if there was any further feedback ...

Regards,

Will


On 07/11/2017 01:30 PM, Will Hopkins wrote:
Thanks, Trisha.

On 07/11/2017 01:12 PM, Trisha Gee wrote:

Thank you so much for reaching out and for providing the updated spec. I appreciate you have a difficult job balancing delivering something in a reasonable time frame that also provides a good set of standards for the future, and I also appreciate that our feedback is rather late in the process (but we are new to the EC!).

I will pass on the updated spec to our (JetBrains) EC working group, specifically to those who had concerns around this JSR, and will also be chasing them again for the more detailed feedback I have promised you. I'll most likely be putting you directly in touch with those who had specific concerns so I'm not getting in the way as a middle man.

Trisha


On Tue, 11 Jul 2017, 19:02 Will Hopkins, <will.hopkins@...> wrote:
Hi Trisha,

I'm the spec lead for JSR-375, and wanted to reach out to you about the concerns expressed with your "no" vote on the JSR-375 Public Review ballot.

I'm obviously interested to hear the detailed feedback you mentioned, but in advance of that I want to provide you with an updated version of the spec (attached), and the accompanying javadoc (https://www.dropbox.com/s/1bq7n8sz25eyfcb/jsr375-javadoc-1.0-b07-pfd.zip?dl=0), which we have just submitted as a Proposed Final Draft. I think it should address at least some of your concerns. In particular, it provides a solution for the issue of static attribute values for the LDAP identity store and other annotations (Issue #76) -- all annotation attributes can now be specified as EL expressions.

I'd also like to address the concern about lack of support for OpenID (I assume this means OpenID Connect), and potentially other technologies. We made an explicit decision not to include OpenID Connect, because we didn't think it would fit in the time we had available, but we do agree that OpenID Connect, and OAuth2, are important technologies. The idea was to provide a base on which features like OpenID Connect could be built, and we do think that JSR-375 is useful, both on its own merits, and as an enabling technology for future additions.

We look forward to your detailed feedback.

Best Regards,

Will Hopkins
Spec Lead
JSR-375

-- 
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

-- 
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

-- 
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

Join javaee-security-spec@javaee.groups.io to automatically receive all group messages.