I’ve looked at the Jira’s and also chatted with Khalilah. She’s asking from 3 perspectives: part “FOLIO-FIT” (where should password requirements be stored), part “general architecture (how should we store previous passwords)” and part “industry-appropriate” (are the blacklists/common password lists appropriate?). I would recommend Kurt and Heikki for “FOLIO-FIT”, perhaps you Jakub for “general architecture” (or Vince or Adam or other core developers?) and I’m happy to weigh in on “Industry-appropriate” aspects.

Perhaps this can’t be answered via email - I’ll add to the agenda for Wednesday.
 
-mdg


On Jul 23, 2018, at 1:35 PM, Jakub Skoczen <jakub@indexdata.com> wrote:

Tod and Mike,

Please review Jira tickets listed next to the issues for more detailed information. Those items require a wider review, not limited to the main contributors of mod-login/user and mod-notify. For Password Management, I assume Khalilah and the team can make the call by reviewing proposed specifications (NIST 800-63B and ISO 27001, HaveIBeenPwned blacklist) with the SIGs and/or following best practices. I think this has limited impact on general FOLIO architecture and modules outside of login handling. I have not reviewed the impact on SSO mentioned by Tod, though.

As far as E-mail sending and templating is concerned -- mod-notify is not directly applicable here as it targets FOLIO internal notifications. When Heikki and I discussed forwarding select notifications over e-mail (as a potential future feature) we talked about mod-notify acting as a client to a FOLIO "email sending" module. In fact such "mod-email" module would have potentially many uses across FOLIO -- already mentioned forwarding for select in-FOLIO notifications (mod-notify), but also Patron Notices (which requires bulk sending capability and templating) or any ad-hoc emailing capability exposed via the workflow engine. mod-email API should be fairly straightforward and I have proposed EPAM takes a stab at it (see UIU-568). What I am not entirely clear about is the flow --  modules can interface directly with mod-email (probably unavoidable in some cases anyway, like bulk patron notices) or mod-notify is promoted to THE notification API used for both in-FOLIO notifications and external (usually Patron facing) messaging. The former is less complex, the latter would require repurposing mod-notify API and adding a capable filtering and routing subsystem.

On Mon, Jul 23, 2018 at 6:38 PM Mike Gorrell <mdg@indexdata.com> wrote:
The first RFC was going to be a “test” of the process. So while we have something documented, we should realize it’s not final in terms of the process. We never (purposely) defined exactly how we would choose reviewers as we wanted to maintain latitude.

In terms of reviewing this specific case, I agree it looks like it’s in the mod-login/mod-users. Kurt Nordstrom looks to be the heaviest contributor. I assume EBSCO has experience with this type of functionality so they may also be able to contribute some reviewers. As for mod-notify - Heikki is the heaviest contributor so I’d likely turn to him.

-mdg


On Jul 23, 2018, at 12:24 PM, Tod Olson <tod@uchicago.edu> wrote:

Hi Jakub, 

Easy one first: the current RFC process looks to be documented in the README.md of the RFCs repo:
https://github.com/folio-org/rfcs

Though we are still awaiting our official first submission and Vince is on vacation.

More difficult:
Could you be a more explicit about what you see that rises to the level of an RFC? Are these establishing new patterns and protocols for interoperability of modules? Would you think of them as FOLIO infrastructure? 

I would expect the password management (bad password lists, etc.) will be part of mod-login and will have to not interfere with SSO, so that could be a consideration. And for sending email, mod-notify would seem to be what is needed (or the non-yet-extant mod-notification that Mike Taylor referred to last week) and would be common infrastructure for use by many modules.

The RFC process is very new, not yet tested. I don't yet have a feel for how we apply it, so want to be explicit.

-Tod

On Jul 23, 2018, at 10:50 AM, Jakub Skoczen <jakub@indexdata.com> wrote:

TC,

Khallah, who is the PO for the new EPAM team, is looking for reviewers to review technical designs that her team plans to follow. Currently, there are two areas to review:

1. Password management (Rules, Blacklist, Reuse) UIU-499, UIU-509, UIU-510
2. FOLIO E-mail sender module UIU-568

I have pointed at several folks from the core team that might help and others volunteered their input through Jira. Given, however, that the TC have established the RFC process I propose we use this more formalised approach for requesting reviews. Would that make sense? If so, do we have documentation of the RFC process that we could point the EPAM developers at? Finally, once RFC documents are prepared, how would we assign reviewers (I can't recall we discussed this though I had to skip the TC meeting last week)?

--
Regards,
Jakub Skoczen

To unsubscribe from this list please go to http://archives.simplelists.com


To unsubscribe from this list please go to http://archives.simplelists.com


To unsubscribe from this list please go to http://archives.simplelists.com



--
--
Regards,
Jakub Skoczen

To unsubscribe from this list please go to http://www.simplelists.com/confirm.php?u=SeK0ArgpLZB2ijVHc1q8eivZ4CXy8J2w