Of course Bean Validation also uses Asciidoc:
https://github.com/beanvalidation/beanvalidation-spec/tree/master/sources
On Tue, Nov 22, 2016 at 3:12 PM, Werner Keil <werner.keil_at_gmail.com> wrote:
> Another good example would be Bean Validation.
> Under "Integration" the spec mentions relevant CDI aspects:
> http://beanvalidation.org/1.1/spec/#integration-cdi
>
> I would prefer if we do that in a similar way and not refer to CDI as
> mandatory in particular functional chapters like Identity Store or Security
> Context.
>
> Happy to change that unless e.g. Arjan wants to do it first?
>
> Kind Regards,
> Werner
>
>
>
> On Tue, Nov 22, 2016 at 2:44 PM, Werner Keil <werner.keil_at_gmail.com>
> wrote:
>
>> Arjan/all,
>>
>> Thanks for the pointer.
>> In most chapters CDI is mentioned as mandatory requirement. I don't see a
>> dependency in the API other than JUnit, so I think it may not apply to the
>> API.
>> The spec may make recommendations for implementation, but the API does
>> not seem to prevent e.g. some implementation to use Spring (Spring Security
>> of course covers a lot, but who knows it could pick up some of JSR 375 like
>> it happened with other standards e.g. Bean Validation, JBatch or JPA)
>>
>> Agorava Core shows this https://github.com/agorava/agorava-core with a
>> separation into "api", "impl" and "cdi-impl" where only the "cdi-impl"
>> module requires CDI, the others could be based on other DI mechanisms like
>> Spring, Guice, etc. I would try to make that clearer, either by mentioning
>> it in some kind of "implementation note" or drop it from the spec.
>>
>> In JSRs like 354 or 363 we have separate RI guides. There requirements or
>> contstraints of the RI are mentioned, but the spec itself is neutral.
>>
>> Kind Regards,
>> Werner
>>
>>
>>
>> On Tue, Nov 22, 2016 at 2:06 PM, arjan tijms <arjan.tijms_at_gmail.com>
>> wrote:
>>
>>> p.s.
>>>
>>> The current draft chapters are:
>>>
>>> * https://github.com/arjantijms/spec-api/blob/master/spec/sr
>>> c/main/doc/identitystore.asciidoc
>>> * https://github.com/arjantijms/spec-api/blob/master/spec/src/
>>> main/doc/authenticationMechanism.asciidoc
>>> * https://github.com/arjantijms/spec-api/blob/master/spec/src/
>>> main/doc/securityContext.asciidoc
>>>
>>> The JavaDoc is also part of the spec, it can be reviewed here in source
>>> form:
>>>
>>> * https://github.com/javaee-security-spec/soteria/tree/master/
>>> api/src/main/java/javax/security
>>>
>>> Would be really great if someone from the EG could give some (early)
>>> feedback on that text.
>>>
>>> Kind regards,
>>> Arjan Tijms
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Nov 22, 2016 at 11:40 AM, arjan tijms <arjan.tijms_at_gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> On Tue, Nov 22, 2016 at 11:14 AM, Werner Keil <werner.keil_at_gmail.com>
>>>> wrote:
>>>>
>>>>> That is similar as e.g. CDI taking certain responsibilities from e.g.
>>>>> EJB. It may take time.
>>>>>
>>>>
>>>> Indeed, this is pretty much the same thing. At least in JSF I was able
>>>> to deprecate the native managed bean annotations in favour of the CDI
>>>> version ;)
>>>>
>>>>
>>>>>
>>>>> The Soteria build seems to fail now. Does that have to do with the new
>>>>> methods?
>>>>>
>>>>
>>>> Nope, it's only the TomEE build that always fails on:
>>>>
>>>> "Failed to read artifact descriptor for org.apache.tomee:javaee-api:jar:7.0-1-SNAPSHOT:
>>>> Could not transfer artifact org.apache.tomee:javaee-api:pom:7.0-1-SNAPSHOT
>>>> from/to codehaus-snapshots (https://nexus.codehaus.org/snapshots/):
>>>> nexus.codehaus.org: Unknown host nexus.codehaus.org"
>>>>
>>>> Usually if I restart just the TomEE job manually again it does succeed.
>>>>
>>>>
>>>>
>>>>> I cloned it and after adjusting some formats in classes or POM files
>>>>> tried to commit, but it seems that does not work. Soteria is not a copy of
>>>>> a java.net repository, so what's the reason some or all EG members
>>>>> cannot push to it?
>>>>>
>>>>
>>>> We have to check the rights then. All EG should be able to push.
>>>>
>>>>
>>>>
>>>>> There are also many pull requests in the pipeline, so if that was the
>>>>> only way to do this right now, I wonder, if that works or why some (e.g.
>>>>> Rudy mentioned he found a problem during the demo in Sofia) are not merged
>>>>> for some time?
>>>>>
>>>>
>>>> Mostly time as far as myself am concerned. I typically try to squash in
>>>> some time to work on Soteria during my commute, but there's only so much I
>>>> can do then until I'm welcomed to the barrage of tickets at work or the
>>>> mountain of chores at home.
>>>>
>>>> In case of the current open PRs there's also the question of the person
>>>> doing them waiting for the confirmation of signing the OCA, and then us
>>>> doing the multi store commit that conflicted with those PRs, so then have
>>>> to be rebased/redone I think.
>>>>
>>>> Kind regards,
>>>> Arjan Tijms
>>>>
>>>>
>>>>
>>>>>
>>>>> Kind Regards,
>>>>>
>>>>> Werner
>>>>>
>>>>>
>>>>> On Tue, Nov 22, 2016 at 11:01 AM, arjan tijms <arjan.tijms_at_gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Since JAX-RS resources can be injected with CDI beans, a JAX-RS
>>>>>> artefact should be able to inject and use the JSR 375 SecurityContext.
>>>>>>
>>>>>> Whether we can convince the other specs to formally deprecate their
>>>>>> own versions is another thing. For that it's perhaps a pity that there's
>>>>>> not really a concept of an umbrella spec in Java EE that sets guidelines
>>>>>> for those things. (I know there's an umbrella spec, of course, but in
>>>>>> practice it doesn't seem to concern itself much with matters like this)
>>>>>>
>>>>>> I just added the two methods to the SecurityContext btw:
>>>>>> https://github.com/javaee-security-spec/soteria/commit/
>>>>>> d41b141fef232c8d2689c7e5bb260dc19f74d933
>>>>>>
>>>>>> Kind regards,
>>>>>> Arjan Tijms
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Nov 22, 2016 at 10:45 AM, Werner Keil <werner.keil_at_gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> It would of course be good to have that sooner, but if e.g. JAX-RS
>>>>>>> 2.1 (also facing Renewal Ballot now AFAIK) could leverage that now hard to
>>>>>>> say.
>>>>>>>
>>>>>>> Kind Regards,
>>>>>>> Werner
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Nov 22, 2016 at 10:38 AM, arjan tijms <arjan.tijms_at_gmail.com
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On Tue, Nov 22, 2016 at 12:44 AM, Werner Keil <
>>>>>>>> werner.keil_at_gmail.com> wrote:
>>>>>>>>
>>>>>>>>> While OpenID Connect offers to add some optional metadata a
>>>>>>>>> concept of roles seems undefined right now, so we may not require it for
>>>>>>>>> certain use cases, but others would certainly benefit from it.
>>>>>>>>> JAX-RS has its own SecurityContext https://jax-rs
>>>>>>>>> -spec.java.net/nonav/2.0/apidocs/javax/ws/rs/core/SecurityCo
>>>>>>>>> ntext.html
>>>>>>>>>
>>>>>>>>
>>>>>>>> Indeed, so as per the JIRA issue the first and foremost goal of the
>>>>>>>> SecurityContext is essentially a cross-spec version of the JAX-RS
>>>>>>>> SecurityContext.
>>>>>>>>
>>>>>>>> Basically if it has the isCallerInRole and getCallerPrincipal
>>>>>>>> methods, it's 95% there.
>>>>>>>>
>>>>>>>> Those two methods are now found in more or less identical versions
>>>>>>>> in 4 different specs.
>>>>>>>>
>>>>>>>> Kind regards,
>>>>>>>> Arjan Tijms
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Looking at Spring Security the SecurityContext interfact there is
>>>>>>>>> somewhat closer to the one in JSR 375 but it also has a getter for an
>>>>>>>>> Authentication object.
>>>>>>>>> In https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-12 this
>>>>>>>>> could be getCallerPrincipal(), getAuthMethod() or similar but they do not
>>>>>>>>> currently exist in SecurityContect.
>>>>>>>>>
>>>>>>>>> Kind Regards,
>>>>>>>>> Werner
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Nov 21, 2016 at 11:07 PM, Will Hopkins <
>>>>>>>>> will.hopkins_at_oracle.com> wrote:
>>>>>>>>>
>>>>>>>>>> Experts,
>>>>>>>>>>
>>>>>>>>>> While I've received some input for the spec from Arjan (thanks!),
>>>>>>>>>> and there may be some coming from Werner as well, I haven't been able to
>>>>>>>>>> put the terminology section in place, and the content we have so far is, I
>>>>>>>>>> think, too thin to release as an EDR.
>>>>>>>>>>
>>>>>>>>>> I therefore propose we move forward with the renewal ballot,
>>>>>>>>>> indicating that the EDR is taking shape and expected to be released soon,
>>>>>>>>>> and that the expert group is active and involved in producing the EDR, as
>>>>>>>>>> well as the API and an associated RI. It's my understanding that there is
>>>>>>>>>> unlikely to be a problem getting the renewal ballot approved.
>>>>>>>>>>
>>>>>>>>>> What say you all?
>>>>>>>>>>
>>>>>>>>>> Will
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Will Hopkins | Platform Security Architect | +1.781.442.0310
>>>>>>>>>> Oracle Cloud Application Foundation
>>>>>>>>>> 35 Network Drive, Burlington, MA 01803
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> You received this message because you are subscribed to the Google
>>>>>>>>> Groups "Java EE Security API - JSR 375 - Experts" group.
>>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>>> send an email to jsr375-experts+unsubscribe_at_googlegroups.com.
>>>>>>>>> To post to this group, send email to
>>>>>>>>> jsr375-experts_at_googlegroups.com.
>>>>>>>>> To view this discussion on the web visit
>>>>>>>>> https://groups.google.com/d/msgid/jsr375-experts/CAAGawe04QW
>>>>>>>>> mHBt5xKR0P_02NOHwgrQ_e8pWGfEjUvPzWoAtJ4w%40mail.gmail.com
>>>>>>>>> <https://groups.google.com/d/msgid/jsr375-experts/CAAGawe04QWmHBt5xKR0P_02NOHwgrQ_e8pWGfEjUvPzWoAtJ4w%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>>>>> .
>>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>