Attendees

Agenda

1. Introductions/Roll Call
2. Action Items Review from last meeting.
   1. Bob will fold in the header from Ben's document into his page from a format perspective.
   2. Add affiliate requirement to the enrollment / registration section - Steven.
   3. Review and make notes in the document with regard to changes / additions / questions - All
   4. Need a "general bag of requirements" (notifications, reporting etc.). Change notifications to General Enterprise Requirements - (I think Renee did this) - Steven will add some stuff here.
   5. Consolidate requirements in one page by next Friday then start reviewing gaps. - All

Notes

Participants

Aaron
Eric
Steve
Jimmy
Benn

Follow-up from previous action items on adding requirements to deliverables page

• Missing some sections - lifecycle and IEP requirements - Bob and Renee
• Benn's registration section - needs to roll into the main page
• Missing assurance requirements - Bob and Renee
• Still need to add affiliate requirements to the enrollment/registration section
  • Steve - have some notes but need to type them in
• Aaron - i made a few notes in the registry

Registry questions:

REG_0180

• "The registry shall store a type associated with each person's name (for example, legal name)."
  • Need Make it explicit that you can have multiple name types
  • Need to add requirement for support for international character sets - Jimmy will add it

REG_0290

• "The registry shall support the storage of all a person's affiliations."
  • Should we add something here distinguishing between affiliations vs. roles per the email discussion)?
• Jimmy - we may want to tie that back to eduPerson as well.
• Steve - many of these terms have lost specific meaning. I think it would be useful to put a list of definitions of some of these terms at the top of this document.
  • I think we should be able to settle on a sentence or two about what the group means by "affiliations"
  • registry has to store some specific data, could be title, department, student id number, all of that is specific to each type
    • attributes related to each affiliation
    • Aaron - that ties into my question of where we keep attributes like department, organization, campus, etc.
    • Jimmy - what we did for the affiliations was tie things like address type to an affiliation
      • so you can define "student address" or "employee address"
      • Jimmy - in regards to HR-type data, we are currently storing in old IDM system, not in the registry, right now only focussing on student information (so we are capturing student title, what level at, etc.)
• Steven - I think that there isn't well-developed schema for this kind of thing, though I believe we could get rough consensus on the core set of data
  • group agrees there's value in trying to standardize that core information
• Benn we went through a similar exercise when designing open registry data model a couple of years ago, may make sense to look at that data model and see if there is anything we can derive from that
  • Steve - i'll vote for that
• Action Item - need to add information into requirements for registry regarding HR data, at least the core set
• Action Item - regarding "glossary" or definition of terms, should add some simple definitions at the top of the file for terms that might be ambiguous

Status Indicator

• Aaron - Not sure if i missed it or if it is implied, do we have some sort of status indicator? active / in active (in HR terms it might be active, terminated, retired, etc.)
  • Steven - i think this is part of the lifecycle stuff but this is key
  • depending on your affiliation type we use different lifecycle policies
• Eric - perhaps have some out of the box lifecycle statuses but also provide the ability to add custom ones for institutional requirements?
  • Benn - yes, when we did open registry we designed for this sort of thing pretty much across the board
  • Steve - one thing to note, we have at least one community (at Brown) where part of the lifecycle is to purge everyone of that type
    • Jimmy - we do that too
• Action Item: I think that's a specific enough requirement, it probably deserves it's own mention. Essentially "calendar-driven" lifeycycle
  • some sort of tool that allows you to do that would be part of the registry

Additional Discussion:

• Steve - when i was looking at this the other morning, i didn't see anything on non-person entities
  • Jimmy/Aaron - recollection in chicago was that we would focus on the "person" side of the registry
  • Steve - I think it's worth calling out that there needs to be a single namespace for these things
    • Jimmy - that's important, a single identifier for the netids and other identifiers
  • Action Item - need to add this as a requirement
• Benn - do we need to consider "test" entities?
  • you need to be able to define test account that allows you to "look like" a faculty member
  • Steve - in our case they are dummy people but are tied to individuals
    • Benn - i've seen cases where they are not tied to people, so we probably need to support both scenarios
• Eric - do they typically exist in the production copy of the registry?
  • Benn - maybe
  • Steven - in our case they do
  • Benn - in an ideal world there would be dev/test/prd isntances but we probably need to be able to support if they live in the prod instance
• Jimmy - @Steve - do you see the need to have the ability to change an address or assign a different name to them?
  • (missed writing down Steve's response)
• Action Item - need to add a requirement to be able to store "test" users in the registry, needs to be some way to distinguish them from the rest of the population
  • Benn - should we exclude this from matching? YES
  • Aaron - this worries me a bit, i don't like the idea of setting these up, but in practice this is what we end up doing
    • Benn - it might be good enough to say there's a "test" flag
• What about guest users and/or affiliates?
  • Steve - we call them affiliation accounts, but they are guest accounts, Jimmy - we call them sponsored accounts
    • Looking at AI's from last call, i have an item to put in requirements for affiliations
• Steve - one other question I had, there is no mention here of federated users
  • another group I'm involved in is called "Social Identity"
    • Jimmy - I tried to cover that with requirement REG_0280
    • Steve - do we want to be explicit then about the ability to create entries in the registry for these people who "self-register"
    • Benn - I think we can do that, probably won't make a whole lot of difference, just might have to do with how reconcilliation works and a few other things, minor differences in how they are handled
  • Steve - thinking about it up front will probably result in a 2% increase in work with the benefit of some important functionality
• Steve - another question I have written down is this underlying rules engine that supports some of these requirements so that someone can modify these via a rules engine instead of having to modify code
  • Benn - i think we can define a few standard processes
  • Eric - I think this is an implementation detail, but probably an important one in terms of making something more easily "implementable" at different institutions
  • Jimmy - one area we are seeing a need for a rules engine is in assurance
• Steve - workflow is another one of these "tools"
  • one area we've seen a need for a real workflow engine is in reconciliation (for people-based workflow)

Closing remarks:

• Jimmy - i can take a stab at a glossary at the front
• Steve - we talked about roles over email, believe the consensus was that there will be a registry for roles?
  • Jimmy - we are working on that for the access management requirements
  • Steve - if you can include me on that I would be interested in participating, willing to share idea for what I come up with
• Steve - other things I should note, i took a pass through Bob's functional model, i had a few tweaks but was very happy with what he put together
  • group agrees

Action Items

1. Need to add information into requirements for registry regarding HR data, at least the core set
2. Should add some simple definition of terms at the top of the document, especially for terms that might be ambiguous
3. Need to add "calendar-driven" lifeycycle to the requirements list
4. Add mention in requirements of non-person entities and that there needs to be a flat namespace across person and non-person entities
5. Add a requirement to be able to store "test" users in the registry
   • needs to be some way to distinguish them from the rest of the population
   • need to not be considered in the reconciliation process
6. Add explicit requirements about the ability to create entries in the registry for these people who "self-register" (i.e. via federated or other processes)
7. Do we need to add any mention to the document about tools that might be needed as part of the whole package? workflow and rules engines?