You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Conference Call Info: Video Bridge 22102

  1. Dial the Auto Attendant at 812-856-7060
  2. Enter the conference number (22102) followed by the # key (e.g., 22102#)

Attendees

Who

With

Attended

Aaron Neal

Indiana U / Kuali

(tick)

Benn Oshrin

Internet2 / Various

(tick)

Eric Westfall

Indiana U / Kuali

(tick)

Jeremy Rosenberg

SFU

(tick)

Jimmy Vuccolo

PSU

(tick)

Renee Shuey

PSU

(tick)

RL "Bob" Morgan

U. Washington / Internet2

(tick)

Steven Carmody

Brown

(tick)

Matt Sargent

Kuali

(tick)

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.
    •  
  • No labels