*Attending*
Mike Olive, Stanford (chair)
Tom Barton, U. Chicago
Ann West, Internet2/Educause
Dave Donnelly, Stanford
Steve Olshansky, Internet2 (scribe)

NOTE: Due to a conflict with Camp in Tempe, we will not hold the call set for 15-Feb. Thus our next call will be Friday 29-Feb 11:00 EST

*New Action Items*
[AI] (Mike) will develop an initial strawman set of test cases to float to the list for feedback. Mike will also contact U. Washington for information on their authority manager (ASTRA), for additional data points about how other systems approach these issues.

*Carryover Action Items*
[AI] {Dave and Mike} will address the status and location of outstanding Jira entries.
DONE. Most were related to the GUI, and have been fixed or superseded by later versions
[AI] {Mike} will contact {Michael Gettes} about potential COmanage requirements to drive Signet functionality.
[AI] {Mike} will contact {Tom Barton} about centralizing a Signet and Grouper [combined] roadmap, perhaps in the I2-MI-Common space.
Mike and Tom discussed this and plan to meet at the upcoming Camp in Tempe to work on this in more detail.

*Discussion*
Dave and Mike met with some folks at Stanford involved in the SDCI VO project and learned more about the role of Signet.

The capabilities planned for Signet v1.3.0 may well resolve some of the issues with earlier attempts to integrate Signet into COmanage. Mike will be following up with COmanage folks about this in the near future.

*Signet 1.3.0rc01 is now available in SVN*
- Simplified Signet Object Model
During the design of SignetXML, many unused cross referenced objects (criss-crossed, actually) were found. For example, a Permission had a list of its Limits and each Limit had a list of its Permissions, each of which in turn had a reference to its Limits, ad nauseum. The new, simplified object model has removed the Limit's references to its parent Permissions.

Dave has cleaned this up, removing unused references, which made things simpler from both runtime and maintenance perspectives.

- SignetXML
1. Import / export various Signet components (e.g. ScopeTree, Subsystem, Assignments)
2. Selective exports (e.g. Active assignments for a specific Subject, or by Subsystem, or...)
3. Command-line utility (scriptable) for ease of use
4. API for programmatic use
5. Separation of XML binding API from core Signet API. Adapter classes tie the two together. This should prove very valuable ongoing for other applications wanting to access the underlying data, e.g. writing small utilities which are able to interact with the Signet XML directly and manipulate it without the need for a running Signet instance.

Q: in the example case of 2 departments that merge, could that scope tree be exported and modified (e.g. pruned), then re-imported back into Signet? What would the effect be on existing assignments?

A: yes this can be done. We would be looking to Hibernate to look at primary key fields (not null or zero) to recognize a new record and do an insert. If you want to rename a tree, this might break existing assignments because Hibernate would not go through the entire dataset to fix them. The assignments would thus need to be fixed as a separate step.

Assignments reference a subsystem, and the subsystem refers to the tree. If you modify the tree it should not affect assignments? Apparently so.

The Signet API has not really changed, other than the removal of methods used to get the parent(s) of various objects of the data hierarchy in memory, which were not being used.

One of the logical next steps would be developing a set of tests to evaluate/validate how well v1.3.0 supports some of these use cases we have been discussing, e.g. changing the scope tree. We will discuss this on the list to gather input.

[AI] (Mike) will develop an initial strawman set of test cases to float to the list for feedback. Mike will also contact U. Washington for information on their authority manager (ASTRA), for additional data points about how other systems approach these issues.