| Time | Item | Who | Notes |
|---|
| 5 min | Agenda review, new introductions, review of previous minutes | | |
| | What do we want the Privacy SIG to do? | Group | |
| | Work on the Release 2018 document - Rows 21, 23, 24
- Review discussion on rows 12/13, 15, 16
| | - Row 21: Not security/privacy related. It is about failing gracefully when components are not available. Need to move to a more appropriate tab.
- Row 23: Difficult to assess as drafted for inclusion in Release 1. Need to have an idea of how to address it in the platform. There are explicit requirements for data retention. Also the question about where the data lives – data that must be stored at the institution or in the country – and partition the data so that this is supported. Need research to identify the scenarios where this applies, then talk about how to hand this off to development teams. Conversations with security/privacy officers can help frame this.
- Row 24: Somewhat of a workflow problem during the authN/authZ process. What is in the software should be able to handle two-factor authentication, but not necessarily specify or hard-code a particular implementation. Cornell, for instance, uses Duo. A quick survey through product council could get us initial details of what is happening with two-factor authentication on campus (Peter Murray will ask Product Council).
- Row 12/13: Focus on higher sensitivity data as a requirement. Try to do it everywhere; identify where it isn't possible and note this early. As a "stretch goal" it gives us the option to defer some of the interfaces if necessary.
- Row 15: What limited functionality could we identify where authN/authZ isn't necessary? Also being talked about in the User Management SIG. What comes out of the Privacy SIG may be policies that describe how we determine what things can be anonymously accessed. There might be smaller installations that don't have a discovery/access layer. Since we don't have anyone that is talking about using the system in this way, this may not rise to a first release requirement.
- Row 16: Are there use cases where we need to know the IP address of the user as an additional/secondary validation check?
|
| | Inviting campus representatives to FOLIO. Process? What background should we give representatives in advance of meeting with the SIG? | Group | - From Cornell, background has been provided to Tim and he has asked questions that prepare him for meeting with the SIG.
- Adam Chandler: Send an email to Tim proposing one of the next Tuesdays to meet with the SIG. Peter Murray will then delete the remaining repeating meetings.
- Coming out of these meetings will be questions that implementors will ask and that as a community we should be ready to answer.
|
| 15 min | Report from Product Council Identify SIG representatives - A convener: sets agenda, manages meeting, reports summary to weekly project update
- A Forum facilitator: participates in weekly FOLIO Forum Facilitator's call and Forum activities
| | |
| 5 min | Meeting review | | |