Hi Will, Can you also add me to the Java EE Organization and the "Java EE Security Team" just like all the other active EG members and contributors? Thanks Rudy

For correctness, these are the URLs On 21 July 2017 at 05:13, Will Hopkins <will.hopkins@...> wrote:

Ok for me, but I'm not a member of the Java EE organization. Yet? (or is that not the intention) Rudy

Guillermo, Correct, class names and strings have the same issues when it comes to vendor specific extension. And classes have the benefit of type safety. In any case, I don't see how we can allow that

Well, Strings aren't type safe, do not play well during refactoring and thus are very brittle for me. If we use interfaces, like the JBoss example from Arjan, @DatabaseIdentityStoreDefinition( ... has

OK for me too

Hi Will, If I'm following correctly, only specifying a named CDI bean will lead then to (for ex based on Arjans example) @DatabaseIdentityStoreDefinition( dataSourceLookup="${'java:global/MyDS'}", cal

For me all the proposed days are possible. Rudy

Arjan, Will, Maybe an important aspect of this proposal we forgot: When is the Expression evaluated, at deploy time or when the IdentityStores is called by the IdentityStoreHandler? (and reevaluated e

Hi, Container specific features are discouraged as we want to maximize the portability. But as Arjan explained, any container is allowed to use a custom mechanism IN ADDITION TO the standard defined o

I don't think anyone of the JSR-375 EG is a member of the JavaEE organization at Github. This is the list https://github.com/orgs/javaee/people But you don't need to be a member to create issues and o

Hi, Thursday is the only option for me, Friday I'm unavailable. Best regards Rudy

Hi, In any case, for me, the group to role mapping must be configurable in a standardized way. So it is no option that it will be handled by a server application specific config. If it is really an is

Hi Will, I can following the reasoning, but the remarks feel a bit awkward. Human error always has a consequence, also when you have some kind of mapping which isn't a default one. When you add the us

Yes, I was looking at the code. I wanted to understand it better, the high-level purpose was already clear for me. (from other libraries) But, due to little server differences, the code is not really

No problem for me.

Or we can wait as long as possible to execute the EL expression. Even do it everytime the validate() is executed. Adding an option here is not an option for this release as it requires an additional m

I agree, not all properties can be easily updated to support EL expressions. And I don't blame you Arjan for not putting it in. You did already a great job. But at a minimum, we need to address a prop

Hi All, The issue is already mentioned a few times when I gave a talk and is also logged as an issue in our GitHub https://github.com/javaee-security-spec/soteria/issues/76. I think we cannot specify

Hi, I was looking for the @LoginToContinue annotation info within the spec. I see that it is only mentioning that the 2 Form definition annotations need such a member. But there is no description of t