I see that the Github organization https://github.com/javaee-security-spec still has references to the java.net infrastructure (mailing list and spec page). I don't know who has the proper rights to u

I've updated soteria so that it can be published to maven.java.net, and published version 1.0-b08. It's currently only in the "Promoted" repo -- the Glassfish build will see it there -- but I

I'm submitting these comments on behalf of Oracle's WebLogic security team. Section 1.1: Add groups to "security data" in description of Identity Store? Se

Hi, I wonder if snapshots are already published again after every commit. Currently this doesn't happen anymore, so the CI tests unfortunately don't work anymore either. Kind regards, Arjan Tijms

See https://github.com/javaee-security-spec/soteria/issues/68 Trivial change, and a reasonable request. Are we all in favour to change this?

I'd like to start a thread to discuss some issues related to SecurityContext. The first, and most important, in my view, is how it's structured. I originally understood SecurityCont

EG: The review period for the Public Review Draft has ended, and it's time to start preparing the Proposed Final Draft. To that end, we need to make final decisions on open i

EG: I've had reports that the PRD draft of the spec, while formatted much better than the previous draft, is generated with A4 page size and fonts that aren't found when printing fr

Once we move, you will need to belong to the Java EE organization at GitHub in order to make changes or (I believe) update issues. Has everyone actively working on the project joined th

I provided some feedback earlier this year but I suspect it may have been a long e-mail, I still have some comments on the latest specification. At the moment an authentication mechanism is described

Whilst JASPIC may have been an inspiration for a number of aspects of the API, is it strictly necessary to state that the mechanism would be wrapped using a ServerAuthModule - shouldn't this be an imp

On the validation provided by the IdentityStore I have a few concerns. The first is I think it is stretching the definition to effectively encapsulate the whole response to a challenge as a credential

Hi, I noticed that in the spec text a few essentials were removed in the security context. For instance the part here:  https://github.com/javaee-security-spec/security-spec/commit/db51cc841e5cb3d8fee

One feature that I don't see coverage of that I see plenty of demand for from EE developers and users is how to allow multiple authentication mechanisms to work together. A common scenario I see reque

Looking at the annotation to define an LDAP - is it possible to configure this where the entry for the user contains an attribute memberOf referencing the group the user is a member of instead of the

Just a small one. Is there a reason for omitting a bean for client cert authentication? If a client's certificate is available the servlet container is required to make it available so we have access

The build in default beans should mean some consistent implementations across different containers. On the two identity stores there doesn't seem to be any description as to how this validation will h

How should I code this? -- Will Hopkins | WebLogic Security Architect | +1.781.442.0310 Oracle Application Development 35 Network Drive, Burlington, MA 01803

Hi, I was wondering how the container should behave when invalid attributes are found on an identity store, e.g.: an invalid database JNDI lookup, malformed LDAP server url, etc. That kind of invalid

EG: I like the idea of supporting EL expressions so that users can specify their own password hashing algorithm, but I wonder if it wouldn't be better, or at least simpler, to suppo