...
- Rob opened with a quick check of the previous call's minutes (to which there was no dissent), and noted that the bulk of the call might well be spent discussing how to arrive at a more discrete project proposal to provide to the strat-org group, but asked if there were any other items that might need attention as well.
- Keith agreed that focusing on a project proposal would be appropriate, and suggested that as things are playing out, the registries group seems to be taking something of the lead for the overall effort, in part because construction of the registry component of the project seems to be both seminal to the overall effort and important in the short term to a number of the players involved.
- Rob introduced the idea that the group might consider entertaining a collection of questions that could potentially fill in the blanks in a more specific project proposal, noting, for example, the question of whether provisioning should be constrained to outbound operations from the registry (making states in other systems consistent with the state of the registry) or whether it should be construed to include also loading data into the registry.
- Keith picked up on the question and noted that the registries group is going to have to load data, and if the provisioning group doesn't provide a mechanism for doing that, the registries group will have to develop a strategy on their own and separately, possibly leading to two very similar but distinct approaches to the same basic problem.
- Rob agreed, but noted that the other (and perhaps equally undesirable) outcome could be that provisioning would be limited to using whatever mechanism the registries group devises for loading its data.
- Keith agreed and added that in either case, it seems as though the provisioning group will have a better sense of how best to handle those issues, since that's our focus.
- Rob then noted that during the Mace-Paccman call earlier in the week, there had been a discussion of the OSIDM4HE work and particularly of the potential interaction between the Paccman effort and the provisioning effort, especially since there's some suggestion that provisioning and access management may eventually be combined within the OSIDM4HE effort. During that discussion, it was agreed that the Mace-Paccman folks would be interested in participating in the conversation at some level, and would like access to the OSIDM4HE-Prov documents in the wiki. Rob had agreed during the Paccman call to consult the group and determine if and how they would be willing to share their content with the Paccman group.
- Keith suggested simply giving the Paccman group read access to the wiki space as a first step.
Wiki Markup
- Rob suggested that Tom might want to provide an update on how things are progressing in the ldappc-ng world, now that Grouper 2.x is out?
- Tom explained that Grouper 2.0.1 was just released (a point-release following the Grouper 2.0 release) and that the plan is to include so-called realtime provisioning with the ldappc-ng interface in release 2.1, which is currently under development.
- Rob asked what issues, if any, Tom is running into in developing a real- or pseudo-real-time interface for provisioning group information from Grouper into an LDAP?
- Tom expressed some uncertainty as to whether we'd want to necessarily say that ldappc-ng should or would be the basis for a more general provisioning interface, especially given that for the moment, he's the sole programmer working on ldappc-ng. He explained that the primary complications he's seeing with realtime provisioning have to do with the capabilities of the two endpoint systems – the source and target – since provisioning can only be as "realtime" as those systems are able to handle. He reiterated an interest in some other efforts, particularly the ForgeRock product (an open-source branch of the Sun IDM code), and suggested that an integration-based approach (using some existing product and integrating it with the OSIDM4HE registry) might be an alternative to designing or developing something from scratch.
...