**Signet Call, 23-May-2008**

**Attending**

Mike Olive, Stanford (chair)
Dave Donnelly, Stanford
Chris Hyzer, U. Penn
Josh Drummond, UC-Irvine
Michael Gettes, MIT
Steve Olshansky, Internet2
Emily Eisbruch, Internet2 (scribe)

*New Action Items*

[AI] (MikeO) and (SteveO) will talk about logistics for the release of Signet version 1.3RC.

[AI] (Dave) will write up his understanding of what Chris is asking for in the area of notifications and will add this to the requirements as something that has been deferred.

[AI] (Chris) will send out 1) an example of a long-running transaction and 2) an example of what an asynchronous hook would look like under his suggested approach.

*Carryover Action Items*

[AI] (Mike) will send a note out to the list with some context about auditing issues and requesting folks to talk with their respective auditors for their perspectives, and report/discuss via the list.

[AI] (MikeO) 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.

[AI] (MikeO) will contact {Michael Gettes} about potential COmanage requirements to drive Signet functionality.

**Discussion**

Signet 1.3RC is going out soon. It will feature general XML import/export and metadata update utilities.
[AI] (MikeO) and (SteveO) will talk about logistics for the release of Signet 1.3RC.

There was continued discussion on hooks and plug-ins requirements.

Michael mentioned that hooks and plug-ins were analyzed in the fall of 2007 and that rehashing extends the length of time needed to move forward.
Chris asked about plans for handling long-running transactions, with multiple assignments in one transaction. Dave responded that each assignment goes thru the API and is handled as a separate transaction. A question was raised about the best way to handle cases where if one of the transactions fails, the entire group should be cancelled.

It was noted that in Grouper, even within one business transaction, there are a couple of things going on that can be rolled back, and that Grouper goes outside of the Grouper API to commit Grouper transactions.

Concern was raised about the reliability of notifications in Signet, and the problems when a notification is issued and later there is some failure and an assignment is not actually completed.

Dave stated the plan was to provide hooks so the plug-ins could handle notification but that Signet itself would not include a notification/queuing system.
It was agreed that the best plan would be to phase the development –- to provide the hooks, continue to assess, and possibly implement a messaging/notification/queuing system later.

Dave stated that the bare bones, simple, pre- and post-hooks as originally defined, would take about 2 weeks to implement.

[AI] (Dave) will write up his understanding of what Chris is asking for in the area of notifications and will add this to the requirements as something that has been deferred.

Chris clarified that we will be using same terminology in Signet and Grouper, but with different capability/functionality, and that this must be clearly described. Chris stated that based on the current plans:

- Signet will not be able to make a reliable notification based on a post-hook.
- Grouper will be able to make a reliable notification based on a post-hook.
- In Signet, post-hooks will be outside the database transaction.
- In Grouper post-hooks will be inside the database transaction.

Order dependency when there is more than one plug-in or listener was discussed. It was decided that to simplify things, for the time being, one hook point should have only one plug in. If a deployer wants to extend a plug-in, then they should modify the plug-in code instead of registering a new plug in.
Chris noted that with only one plug-in, all events are essentially synchronous.

[AI] (Chris) will send out 1) an example of a long-running transaction and 2) an example of what an asynchronous hook would look like under his suggested approach.

The next Signet Working Group call is scheduled for Friday, June 6, 2008 at 11am EDT.