Attendees

Agenda

1. Introductions/Roll Call
2. All - short review of fit/gap analysis updated/additions
   1. Steve - new items on schemes and life-cycle
   2. Eric/Aaron - KIM
   3. Benn/Jeremy - OpenRegistry
   4. Renee - PSU
3. All - discussion on what our recommendation should be

Notes

• Steve - in reference to the new items that were added, the start date on affiliations is an effective date for that type of assignment
  • Eric - I'm assuming this can be future dated for pre-population?
  • Steve - yes, we also use it in conjunction with the end date to force account review for guest accounts.  Helps ensure that they should remain active or not
  • Bob - this does kind of walk the line between access management and a registry,
  • Eric - when we looked through the new items that Steve added most of them are related to Life Cycle and while that is not currently part of KIM, we see it being added in the future.  With the schemes being extensible, that didn't seem obvious to me at first, it was a new idea.  But it seems to bore than just extending a tables attributes
  • Steve - the intent is that we should make it easy, to make the system easy, to use for the specific relationships that an institution has. It should be easy to setup and use them
    • Bob - at UW, that's our biggest problem right now is that our registry isn't extensible
    • Eric - seems like we have to have extensibility as a requirement and that our charge is to make it simple and easy to do
  • Bob - we've not really dived into having the registry store non-person entities, but it seems like that's a natural part of a registry
    • Eric - with KIM that's definitely a requirement.  We have that on the additional KIM notes page related to requirements
    • Renee - in Chicago I thought we determined that non-persons were out of scope
    • Bob/Steve/Eric - that's correct, but being that it would all live in the same name space we have to offer some level of support for that.  We give accounts out for person and non-persons; however this could be a very large undertaking
    • Eric - however, in the use cases we've come across in KIM, non-persons seem to be pretty simple and don't require much information be tracked.
      • Bob - it seems that connecting these non-persons with responsible parties is the tough part
• Bob - without a doubt we have more requirements that can be added but we need to have some discussion of our recommendations for this coming Friday's meeting.  We need to say what we feel our starting point is, how many FTE it may take, and for how long.
  • Eric - Keith sent out an email to the group with a list of IAM software options, do we need to look at each of those?
    • Bob - I think Forgerock is worth looking at, I've talked to them in the past
      • Jimmy - we looked at them too.  They fit in some places for our needs but not all of them, I don't recall them having a Registry as part of their offering
      • Steve - I believe this is the old Sun IDM team that merged with Aegis to create Forgerock
      • Bob - it needs work I believe, but there could be some relevant connections.  It is open source but closely tied to their own group for contributions
      • Eric - closely built on Sun, but unknown how mature it is
      • Steve - they have 4 projects right now, but their Open IDM seems vague.  Would need to know what the plan is for the future of that
      • Bob - I have a contact with that group, I'll see what I can find out.
  • Eric - what about the 3 we have on our list now, PSU-CPR, OpenRegistry, & KIM?  With OpenRegistry what are the long term prospects for the project
    • Benn - technical it was designed to server and be open to everyone.  Politically it's been mostly Rutgers and Simon Frasier at this point that are driving the project.  However if others came in, the steering committee could be altered, it's not out of the question.  Though, how Rutgers would react to that is unclear.
    • Renee - when PSU looked at OpenRegistry it didn't seem that easy to get things on the Roadmap
      • Benn - overall I'm comfortable with this group making the best decision as they see it.  PSU and OpenRegistry may actually be more similar than we think
      • Renee - Identity Assurance Profiles is a huge thing for PSU and how we designed our system.  Within and outside of PSU an I think you have to have it, it's absolutely critical.  That was a big reason why we went down our own path
        • Benn - early on with OpenRegistry that was part of the specs, but with the requirements it wasn't clear why it wasn't incorporated.  Could be part of the roadmap.
  • Bob - it's difficult to get others to adopt others stuff.  We need to get past that barrier however if we want to development a community shared product.
    • Renee - with OpenRegistry we ran into this.  Time, is it going to be available now, soon, later, etc.
  • Eric - As for KIM, ti's complicated.  We didn't set out to build it as a registry, wanted it to be open enough that a registry wasn't needed to implement.  However, with new projects such as KS (Student) and KPME (HR) it's becoming apparent that we have to expand KIM, but not sure how much.  I'd be easy to to this with KIM though.  Bill Yock asked one time if we could just use OpenRegistry, however fit would be hard to get our stakeholders to do this.  Partners are invested ($, governance, resources, etc.) and would with to stay within the Kuali suite of offerings.  But this is a new space for us, easy solution is to say we'll build it, but it's not clear that's the right approach.
  • Renee - PSU is will to support what the decision is, if it's Kuali or OpenRegistry with information sharing etc.  However, they designed their own application for a reason and will use it.  Want to help out where they can with code, design info, etc.
    • Bob - PSU is unique in that they've developed their own thing that could potentially be part of KIM or OpenRegistry, would they be interested in sharing?
    • Renee - sharing yes, but initially it'd be difficult to contribute resources
    • Bob - at this point, PSU is the only one reviewing the application, there are no outside sources looking at the code, etc.?
    • Renee - correct.  And we have a bunch more coding left to do to meet our goal of release by the end of the year.  The best part about our application is the time we've spent with our stakeholders at PSU, years, to ensure we are giving them what they need, that goes well beyond the code.
  • Bob - at this point it appears that we are not willing to rule one or the other
    • Renee - we can't rush the decision
    • Steve - maybe let the market decide?
    • Bob - it may be that the bet decision for KIM is for them to go off on their own
      • Eric - would see it as a sub-project of Rice with targets investment.  It's own governance, etc.  Another thought is that maybe the best thing is to reconcile KIM so that it works with OpenRegistry
    • Eric - PSU has created their own application but is willing to share with KIM or OpenRegistry, whatever we decide and make it OpenSource, I heard that right?
      • Renee - that's correct
      • Eric - Kuali could spin up a project and get investors to build it up...
        • Bob - but being Kuali that has it's own set of baggage, the view that it's a monolithic enterprise
      • Eric - ...In summary I think we have a good set of requirements and with 3 big players that each has their own stance.  We might want to look at ForgeRock too.
        • Renee - Duke has some stuff, but I think it's mostly a group of connectors that would be open, but more along the lines of provisioning
  • Eric - Should we draft a summary then?
    • Bob - I'll take a stab at it
    • Eric - feel free to hit up Matt and I with any questions on Kuali stuff
• Bob - the big question, beyond the summary, is what is the best path forward (dun dun dun....)