2019-03-13 Meeting

Owned by Eric Jansson
Last updated: Mar 15, 2019
2 min read

Agenda

  1. Participants to describe in round-robin fashion
    1. intros
    2. implementations that exist
    3. needs / why those exist - what problem is this solving?
  2. Identify other known implementations who we might reach out to 
  3. Open discussion on Arizona DOE design

Notes

Only summary notes were kept. Key points and questions:

  1. The authorization should be logically ANDed with the current relationship-based auth, not an OR (as described in the proposal). This was seen as more secure: since there are shared cases, there is an added level of security - you are not taking any security away

  2. It was unclear what value or token to store in the record - the API Client ID? The API key? The LEA ID? In part, these questions derived from a need to explore more deeply the use cases: at what level are you trying to secure the records, and what are all the scenarios to support? For example, would an SEA want to support changing LEA vendors, such that the new vendor could access/edit the records from the old vendor?
    1. On changing vendors specifically, this was not seen as a major concern for SEAs: LEAs tend to not switch SIS systems during the school year, though specialty or smaller vendors (e.g. SPED) do change
    2. It seemed like this new security was probably best handles at "application" level in the Ed-Fi security model
    3. Also to consider: if vendors submit a record with the same natural key, they may get a sub-optimal error message back

  3.  A second question was if it was better/possible to write the necessary data on security entities and principals into the ODS database, so that a new auth strategy could be created that worked like the current relationship-based strategies. 
    1. Is it possible to use EdOrg Responsibility Association?
    2. Who would create the Responsibility (or other) associations? Can SIS systems write these?

SIG will reconvene in a couple of weeks to consider further questions 2 and 3 above, with SIG members analyzing use cases in the interim.