Attendees

Agenda

1. Introductions/Roll Call
2. Bob - updates on timelines/expectations for 9/16 deadline
3. All - review of fit/gap analysis
   1. Eric/Aaron - KIM
   2. Benn/Jeremy - OpenRegistry
   3. Renee - PSU
4. Bob - updates on what others are building around the Oracle Product (notes from Rob (?))

Notes

• Updates on timelines in relation to the 9/16 deadline
  • Bob/Benn - for the 9/16 deadline we need to be able to present what we have thus far as well as say what we have left to do and how much time that will take.  The overall plan is to pay it by ear till next friday to see where each group is at to decide what we'll do next.
    • access management has only had 1 meeting thus far
    • the provisioning group seems to have a good amount of things ready
• Fit/Gap Analysis
  • Eric - we have a few extra items that KIM is required to have (citizenship, employee status, FERPA elections, etc.) do we need to expand those out into their own requirements?
  • Bob - maybe we don't need to go in tot hat level of detail at this point.  UW has a requirement that all the tables be extensible, that should cover this I think.
    • REG-0410 seem to be a requirement on our list for having extensibility
  • Steve - perhaps we should look at this as the system needs to be able to deal with a variety of relationships/affiliations (student, faculty, etc.) and provide schemes.  One way to look at it is that the product would ship with schemes for these relationships with the option to extend.  I'll add this as a requirement.
  • Jeremy - with OpenRegistry we found, from our work with USF, that they looked at the registry as a way to match people with a single record and that these additional attributes are dealt with outside, not baked into the application.
  • Steve - 3 types of registries to think about.  Thin - minimal amount of info. Medium - stores general information.  Fat - stores all identity information.  Seems that medium should be the solution we shoot for.
  • Jeremy - USF has a baggage claim idea, where things are plugged in later where they are needed.  Thin as a base with hooks to make it a medium may be an approach to take.
  • Steve - I can update the requirements to go with this idea of delivering a thin w/extensible hooks to make it medium.  Need to add a requirement for life cycle framework.  Doe that fit better in Access Management thought?
    • Bob - that sounds more like access but w/changes in affiliations/tables etc. we might want to add something for triggering related information from the registry
    • Steve - a full blown state machine inside the registry
    • Eric - tracking affiliations as they change over time should be done and communicated downstream
    • Steve - I'll add something for this to the requirements w/Bob's help
  • Steve - under management functions I've added an item for purging.  I've kind of assumed that all is built on top or w/workflow in mind?
    • Eric - for KIM that for sure would be true.  But even kKIM can be used w/out using workflow or the delivered interface screens via services
    • Benn - we shouldn't require workflow but having the ability to allow institutions to implement workflow is needed.
    • Eric - it sounds like the requirement, in functional terms, is that we need to allow for approval from outside parties.  Provide the ability for review/approve
  • Renee - back on the scheme idea. PSU's plan was that the registry shouldn't be the responsibility entity for affiliations.  It should have a single record and scheme with affiliations and such handled by external systems
    • Jimmy - for Open Registry we have identifiers and tried to find common ones and only include those int he registry
    • Renee - types for attributes (addresses, etc.) makes sense, but when talking about workflow, roles, etc. this is may require a different approach
    • Bob - so in summary Steve is looking at the affiliation based scheme's but Renee feels that's too specific and probably not the approach we should take.
    • Steve - agrees that there are core pieces of info that should be stored in the registry
    • Renee/Bob - seems that some business rules are needed (?)
  • Matt - that's time. For the next meeting we'll need an intermediate one before the 9/16 status update per Bob's suggestion.  I'll pull that together.
    • In the next meeting we'll need to update our area's checkboxes for any new/changed requirements w/a brief review for any questions on new/changed ones
    • Also, we'll need to start or decide what our approach is, the hard decision stuff of what our recommendation is.  Not a full blown document, but at least what our suggested direction is.