Yes, some like this feature are prerequisites for others.
Kind Regards,
Werner
On Sat, Nov 19, 2016 at 1:48 PM, Rudy De Busscher <rdebusscher_at_gmail.com>
wrote:
> All,
>
> The *clientSecret* is a concept of OAuth2 (within the authorization code
> grant flow) which needs to be kept secret, just as a password.
>
> So that is a candidate for the password Aliasing concept.
>
> Best regards
> Rudy
>
>
> On 18 November 2016 at 23:16, Will Hopkins <will.hopkins_at_oracle.com>
> wrote:
>
>> Werner,
>>
>> The attachment did make it through.
>>
>> My take is it's premature to say that OAuth/OpenID Connect will be in EE
>> 8. There's been some discussion about it internally, and I was asked to
>> get a sense of how the EG felt about it, but it's by no means a given that
>> we'll move forward with it, especially given its size and complexity
>> relative to the time frame of EE 8.
>>
>> I would also note that "Secret Management (incl. Password Aliasing)"
>> would presumably remain in EE.next even if OAuth moved to EE 8 -- or do you
>> see an OAuth dependency on secret management?
>>
>> Will
>>
>> On 11/18/2016 01:57 PM, Werner Keil wrote:
>>
>> Dear Experts,
>>
>> Please find a link to my recent Java2Days talk (the smaller room was
>> packed, people even stood in the back, it could have filled the bigger one,
>> too if it was held there;-) about Java EE Security for Java EE 8 and 9.
>>
>> http://www.slideshare.net/keilw/java2days-security-for-javae
>> e-and-the-cloud
>>
>> The topics and especially the roadmap I presented was largely based on
>> KK's JavaOne presentation. After talking to Dmitry he suggested it's good
>> to also keep the disclaimer (Rudy had a slightly different one in his talk)
>>
>> Yesterday (the last day seemed a lot less crowded, especially talks
>> around the end e.g. on CDI 2 were almost empty) David Delabasse talked
>> about Java EE ".next" in general, also but not only Security. He certainly
>> had the same disclaimer, so nothing is written in stone, but hinted,
>> features like OAuth or OpenID Connect (essentially that means OAuth, since
>> it's based on OAuth2) were "nice to have" in Java EE 8 already.
>>
>> So instead of the feature breakup and roadmap I have in my slides (or KK
>> did before) this would look like the attached PDF taken from page 59. And
>> only 2 features ("Security Microservices" and "Packaging") would be left
>> for Java EE 9 while the lion share could or would end up in JSR 375 for
>> Java EE 8.
>>
>> Do all of you think that's realistic?
>> Don't forget especially the TCK unless a working java.net replacement
>> allowed "collaborative development" in the sense of jcp.next 5 (successor
>> to JSR 364) before next Summer will be up to Oracle because the current
>> license for that is not Open Source, so TCKs of all EE JSRs except by Red
>> Hat are not developed in the open and members of the EG even if we all were
>> willing to help normally can't work on that.
>>
>> I hope attachments work, at least in the Google Groups alias? If not, I
>> can resend it to those of you who are interesting in a direct mail, but you
>> also get the idea from the Slideshare presentation, just shift all but the
>> bottom 2 to "Java EE 8";-)
>>
>> Kind Regards,
>>
>> Werner
>>
>>
>> --
>> 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/CAL%2Bwt-52Q5U%2B1vWP6h5WAfCivC4dNXMCGH49gacO
> J9sL%3DB1T%2Bg%40mail.gmail.com
> <https://groups.google.com/d/msgid/jsr375-experts/CAL%2Bwt-52Q5U%2B1vWP6h5WAfCivC4dNXMCGH49gacOJ9sL%3DB1T%2Bg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>