Attendees

Agenda

1. Introductions/Roll Call
2. Updates
3. Provisioning & Registries - Keith/Eric
4. Project Proposal - Eric/Jessica/Renee/Matt
   1. Requirements Chunking Exercise - Matt
   2. Draft Proposal - Eric/Jessica
   3. Timeline and Estimates Work - Renee/Matt
5. Strategy Group Updates - Bob

Action Items

Attendees

jessica
jimmy vuccolo
dave stiener
eric westfall
matt sargent
tom depurac
Omer Almatary
lucas rockwell
Muhammad Siddique
Steve Carmondy
Renee Shuey
Bob Morgan
Benn Oshrin
keith hazelton

Notes

matt - review chunks for next week please

bob - bill yock has been pushing forward an effort to get a contractor to move things forward for getting investors and materials to present to folks. someone with tech/bus focuses to get things organized with schedules, required resources, etc. maybe get a face-to-face with that person or some folks in the next few weeks. one person has been interviewed.

eric - so the resource will help push the projects forward

bob - getting over the hump to get more real. interest in KDs was there, but folks always want to know more. get more solid on the business side.

eric - my observation at KDs was there there are a lot of people interested in the outcome and contributing, but in order to do that we need to have something more defined to bring in the investment.

bob - everybody has needs for a better registry, when and what is this thing going to deliver, that's what we need to know.

lucas - UCSF, no real updates on their registry group…

benn - 2 weeks ago berkley and sf folks had a face to face with the folks that wrote the alignment document…aus ex-bankers or something. as far as registry is concerned they still want to do more research and analysis looking at PSU and OpenReg. Did a bit of work on reference architectures for the 2 groups. Reaffirmed the need to resolve the reg and ….did talk about the identity match a bit and both schools want that, feel that they can move forward on that relatively quickly (given resources). there is a proposal for how that'd work. being the end of the year, no real magic happening soon, but after the first of the year, we could make rapid progress on the search/match piece.

lucas - that really covers it

renee - PSU w/Jimmy plans to share their code to Lucas and Dedra as of the 16th of December with the knowledge that the services still need to be developed.

jimmy - share before the holidays, but the meat of the work won't begin till the start of the new year.

rob - i'll give a shot at a summary. as we've talked through how we look at provisioning work in general and along with the rest of the OSIdM4HE projects. What part of the problem space should be provisioning and what should be registry and how will they talk to each other. the idea is to figure out as a group how these should work together instead of working on the same idea different ways.

steve - where do we put all the rules that control provisioning? for me that's one of the key decisions of defining the boundaries of the two areas. in the end that's the key question here.

been - if we look at what we're trying to do with the idea of loosely coupled pieces that folks can use. does that help or make things more confusing.

keith - the reg should be the authoritative source of info. provisioning should be a service. if you take that model then the integration patterns which has the merit of apache camel implementation. reg is the source where provisioning grabs the patterns from the source.

eric - from the prospective of the reg, i thought the rules would live outside of it. is that consistent with other's thoughts?

rob - should the repository of which systems can access data be part of the provisioning or registry? that's a piece i see in the registry. if it's stored in the reg, then the provisioning engine doesn't have to keep up with contracts.

steve - i'm on with keith as the reg being a data repository. i think of provisioning of 2 components connectors that are specific to each target system and the second being a set of rules. i've seen the rules embedded in the connectors, but in the model i like is to not put the rules in the connectors but in a separate place. i'd like to see the business rules not embedded in code at all but in it's own rules engine that is readable to a functional user.

eric - would that be an implementation decision? do we want to force the architecture that a separate rules engine has to be used?

steve - good question. to extent do we want to be authoritarian about these things? in my experience if you embed those rules you get yourself in trouble with the maintenance and setup. others may have other ideas, but that's what I was thinking

renee - i'd like to think of it as an intelligent registry, not just a person registry. we're talking about doing both at PSU, some embedded but some in it's own rules engine.

eric - are we tripping over terms? do we need to think of what the reg includes? we could say that the reg is a bunch of different pieces that work together…that that's the reg.

bob - any modern system is that the API's contracts define the system. the core scheme is there, but you can use those to get information in and out.

lucas - i agree with Keith in this, i want to mention that over the years, the connectors have been the big selling points. but when they get to it, they decide not to use it. it seems that not having them hooked together makes the most sense. the loosely coupled thought needs to be something we use.

bob - a UW, provisioning is stuck onto the service management not part of the registry element.

rob - we're seeing software as a service vendor offering provisioning as a service.

bob - we'll be getting rid of those completely...

steve - the connectors used to contain ugly logic in how info was stored and organized. more and more all the ugly is hidden behind the service. I'm still interested in the rules, which users are authorized to do this in a given system.

bob - that sounds like access management to me.

rob - policy enforcement…if we could have some sort of rules enforcement. there are clearly some rules where the point is close to the target and others where it's close to the provider. however the metadata could live outside of both pieces.

steve - what i like is that there is metadata that stores all of that stuff it's easier to see who has what access privileges

rob - keith's original talk about closer to identity attributes instead of privileges i believe

bob - i'm hearing consensus here. seems like the reg folks are inclined to keep the reg simple; not to venture into rules about where the data goes and such…does that sound right?

tom - external rules sounds like it will help the provisioning group with their work. not clear where we wanted the rules to exist, sounds like a repository is needed outside of the provisioning that they can query. needs to have workflow with human intervention…

eric - how does this cross over with Access Management? is this a different type of access that we're talking bout here?

keith - i think principals groups roles privileges and how they map together are at the core of access management

bob - seems the packaging of all of this is the big question…if access management is the driver then you'd have a reg that has no restrictions

bob - so we're at the hour…i assume that we have some notes?

matt - i'm trying

bob - hopefully we can distill this all into our requirements

keith - i think we should get to work on the discussions about interfaces. we have a shared conceptual view about this…

benn - the reference arch. of how this all fits together needs to be done.

rob - would it be useful to have another joint call?

bob - seems like this is an all team discussion since we have some Access Management topics here too

keith - seems like this ties into a F2F and someone writing up a pitch would need this

benn - a 2 hour conference call with a virtual white board

bob - we have some working examples to reference to decide what our interfaces would need to be to start with.

steve - it seems to me that before we start with that, we need to have consensus about the over all diagram. seems to me that we need to have a call for proposals for how this would be how the components are/work and then that would help the interface.

keith - seems as a pre-meeting task a proposal based on today's discussion needs to be provided to get things moving.

steve - sure, but I think we need to cast this in black/white to be sure everyone agrees…

bob - i'm hearing a volunteer?

steve - i can give it a try.

keith - put it out in a public space and we can collaborate on it together.

bob - i'm putting somethings together.

keith - linked off the reg?

bob - yes.