Attendees

Agenda

1. Introductions/Roll Call
2.  Review of Registry Subcommittee Deliverables page
   1. Any changes to the layout, etc.?
3.  Discussion on requirements progress so far
   1.  Reconciliation, Registration, Matching - Benn Oshrin
   2. Management Functions, ID Store, Notifications - Jimmy Vuccolo
   3. Matching & Merging - Aaron Neal, Eric Westfall
   4. Lifecycle/Statefulness, Assurance - RL "Bob" Morgan w/Renee

Notes

Jeremy Rosenberg joined us this week.  Background - connected with Ben > 1 year ago.  SFU has needs in the IdM area.  Worked on Open Registry. Brought up the OSIdM4HE project within his organization and they are still interested in solving the problem.  Attending from a SFU perspective and not and Open Registry perspective.

Steven Carmody joined us this week.  Background -  Brown University @ Providence, Architect. Portion of his time spent on Internet2 - shibboleth and InCommon has been his focus. Ramping up a project at Brown to replace IdM homegrown solution. Interested in what they can learn from these discussions.

Discussed the format of a final report. The final report will likely be more high level with an appendix referencing the lists of requirements identified.

Do we need a template for a more generic proposal? Final format should be more in the format of what Ben / Bob has put together - will need to translate the lists to more of a narrative.

ACTION ITEM - Bob will fold in the header from Ben's document into his page from a format perspective.

Question about chunking - credential assingment and identity proofing, are they part of the registry or separate systems related to the registry? Password management would likely not fall into the Registry chunk. Credential assignment is viewed as a lower priority and a problem that is largely solved. Pieces of vetting and proofing might belong in the registry (exmp. attributes such as registration authority or proofed the data)

How does an affiliate system integrate with the registry? This would fall in the enrollment / registration group. General feeling is that it falls within the person registry.

ACTION ITEM - Add affiliate requirement to the enrollment / registration section - Steven. Note - This is a good match with where Brown is headed.

Is identity proofing in scope? Should there be rules for example on how HR people are handled in the registry (prob not) as opposed to who proofed what which should probably be in the registry.

Need some work on life cycle and assurance stuff - part of this is in the registry already (Jimmy) so we have a start.

ACTION ITEM - Review and make notes in the document with regard to changes / additions / questions - All

ACTION ITEM - 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.

Gap Analysis Discussion

KIM - Eric

Open Registry - ?? (Report might note that it is in this space, but we may not to engage for .... reasons). Should distinguish Open Registry code base from Open Registry from a project. May be worth it to do a gap analysis against the code to see if there is something worth using. This could save time if there is useful code. Would be easy to seperate the code from the project. No restrictions on the use of the code. Definitely want to look at what has been done

Should consider open sourcing the Penn State option - done some things around SOA and event driven. Renee has asked those questions at Penn State and it should be something to consider.

Can probably make a general statement on what various institutions have done already and how it might be used. We can't look at every home grown registry though - not enough time.

Should mention COmanage for completeness of the document although it might not be an appropriate enterprise product.

Should define the difference between campus central registry and external federated identities and storing / remembering them.

Will not consider commercial options from a gap analysis perspective.

If for example Penn State solution uses commercial matching option, then that is ok. Don't want our solution to exclude the possibility of including a commercial component.

ACTION ITEM - Consolidate requirements in one page by next Friday then start reviewing gaps. - All