New *Action Items*
[AI] {Lynn} will write up his impression of the needs regarding subsystem metadata and assignments, and {Tom} and {Michael} will confirm or further explain.

Carry Over *Action Items*
[AI] {Lynn} will share an updated version of use cases for Hooks. (25-May-07)
[AI] {Tom} volunteered a role in vetting the Signet with Grouper to have a common JVM. (25-May-07)

Future *Agenda Topics*
- Kathryn Huxtable - Recent Subject adapter/source activity

*Agenda*
1. Version 1.2.1 speeds things up

2. We have some immediate urgent requests for facilities to address the programmatic maintenance of subsystem metadata and assignments. I would like to discuss these requirements as we are in the process of formulating development plans. There are several axes to consider --
       - data (assignments) vs. metadata (subsystems, scope, etc)
       - descriptive vs. structural changes (the latter which might affect existing assignments)
       - administrative (offloading/reloading data) vs functional (bulk loading new or changed assignments)
       - input (assignments) vs. output (permissions)
       - test vs. production activities (where you may or may not care to preserve history)
       - XML loaders vs. alternatives

This is the bigger picture - I think the immediate requirements lie somewhere in here, so we want to make sure we understand them properly.  I'll flesh out the above talking points in writing for the call. - Lynn

*Discussion*

-Signet v1.2.1 Released-
{Lynn} announced the release of Signet v1.2.1, available today, and described the release as a short list of bug fixes. {Dave} addressed a few issues related to Hibernate, as well as logout. He said session modeling is an ongoing concern. He does not have the means to test for multiple-user scenarios, a situation that would require a server restart.

-Maintenance of Subsystem Metadata and Assignments-
{Gil and Michael} described the context for requirements around managing data in Signet.

{Tom} said that U. Chicago has had an interest in running something comparable to Stanford's Authority Manager. {Gil and Jeff VanEeuwin} are working to develop similar technologies at U. Chicago. An initial use case details a focus on approval authority. I.e., how do you provision to an external system? Currently, U. Chicago does not have a practice of delivering authority, and so does not maintain lists of hierarchy regarding who has the authority to make approvals. The Authority Manager manages the identity of approvers via the UI and API. They are also interested in enhancing it by placing business rules (hooks, etc.), such that there may be multiple ways to enforce approval. They plan to deploy in the near future, which means that data will need to evolve as new external applications are added, likely integrated through XML. Additionally, policies will need to be created. 

{Tom} also expressed a desire for Signet stem hierarchy to be able to mirror the scope hierarchy, though not necessarily dynamically. It might be possible to use hooks to perform this mirroring. This would be useful in replacing an entire tree. Currently, in Signet, assignments must be pulled out before a tree loads, as opposed to moving with the tree. Another interest is to do batch dumps of subject data, as opposed to singly selecting subjects. Critical is the expense management system, where initially a few departments will learn how to deploy, get organization structure and learn about scoping hierarchy to reflect into the Authority Manager. Later, additional branches will be added, and subsequently text changed, as well as the structure of limits or functions.

The Group discussed how to address incremental updates by perhaps a better style of supporting bulk operations or a utility approach. {Tom} stressed that he is less concerned with the form that the capabilities would take, and more concerned with the actual capabilities and speed thereof. 

There was also a request for a level of interaction that would communicate the impact of an action taken so that the user could make an informed action without regret. Not only would it 'revoke', but it would 'respond'. Another approach may be to create a second function to move assignments into before removing the original function. Preserving a trail for auditing is important to keep in mind, though there may be times when a 'purge' option is desirable.

The Group will try to capture the essential use cases. [AI] {Lynn} will write up his impression of the needs regarding subsystem metadata and assignments, and {Tom} and {Michael} will confirm or further explain. 

{Michael} mentioned a scenario that would support the creation/deletion of a subsystem. This would be limited to a Signet subsystem owner or similarly highly privileged user.

The Group agreed that {Gil, Jeff, and Dave} should work together to identify particulars and decide who should do which work. Real experience from a campus will provide essential insight to any utilities that {Dave} produces. {Michael} asked about the probable timeframe for these outputs, but that is likely to be clarified as requirements are detailed.

The Group agreed that finer query controls should be addressed down the road, as should be scaling issues. Eventually, {Michael} plans to use the collaborative aspects of Signet to better manage services through the use of permissions, i.e., for Sympa, Confluence, eDial, etc.

The next Signet Working Group call will be on Friday, August 3, 2007 at 11am EDT.