Signet Working Group conference call
August 4, 2006

*Attendees*
Lynn McRae, Stanford U. (chair)
Dave Donnelly, Stanford U.
Gary Brown, U. Bristol
Tom Barton, U. Chicago
Andrea Beasing, Cornell U.
Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)

Carry Over *Action Items*
[AI] {Lynn} will request use cases and other agenda topics for the CAMP program. (21-Jul-06)
[AI] Contact {Lynn} if you identify additional functional requirements for your local project. (28-Apr)
[AI] {Bob} will send .htaccess local syntax to the group via the list.
[AI] {Group} will develop use cases for Signet.
[AI] {Minh} will develop a list of requirements for how Signet will interface with LDAP and Grouper.
[AI] {Lynn} will write up a person and function summary to express the relationship of privileges to roles and to determine what gets expressed in the eduPerson entitlement space.

*Agenda*
1. The Signet Wiki!  Jessica will catch us up on this work, possibly with a preview. You can visit the companion Grouper Wiki site at: <https://wiki.internet2.edu/confluence/display/Grouper/Home> to see how a parallel effort has shaped up, so any thoughts, reactions, comments there would likely apply to the Signet site as well.

2. Shared libraries; assembling composite products, e.g., Grouper and Signet linked together.

3. Use-case for a subject-oriented custom LIMIT from Tom, a lead in to exploring custom limits.

*Discussion*
The Signet wiki is under development, and {Jessica} hopes to open the wiki to the Working Group and Public by next week. The Signet documentation for v1.0.1 will find a home here, though some higher-level documents will remain on the Signet web. Navigation throughout the wiki will parallel work in the Grouper wiki. In the Project area, there will be a page with links to the conference call minutes, as well as any other handouts discussed on the mailing lists. Instructions can be found in the wiki to sign up for a login or request additional permissions, such as Edit. Stay tuned to <https://wiki.internet2.edu/confluence/display/Signet/Home> for updates.

As a working group member, the Signet Project space of the wiki will be a place to post various documents, presentations, use cases, suggestions, and other items outside the mailing list discussion. It is suggested that you follow a posting to the wiki with an email to the mailing list, explaining the posting or requesting feedback, etc. Group members will also use the wiki as a place to share code and discuss development issues.

There is work underway to shibbolize the Internet2 wiki and related Working Group spaces, though no final word or timeline has been confirmed.

The Group discussed a common venue for shared 3rd party libraries (cf Tom’s email 24-Jul). Currently, people are running different versions of these libraries as there is no way to see which libraries are being used, i.e., with the exception of looking internally within Signet and Grouper. Finding a common location for these 3rd party libraries to rest will enable better coordination and smoother deployments. This will be an issue not only for coordinating Signet/Grouper, but for any application wanting to embed Signet/Grouper for their API, as they will introduce libraries and 3rd party dependencies. Release notes ought to indicate if two incompatible versions are being used.

{Dave} explained how he views things as either internal (Internet2 Middleware) or 3rd party, which ought to be maintained separate from the middleware projects. He said a developer will likely work from the latest copies on hand, while an end user will want to pick and choose which components they want at that particular time. The strongpoint for an I2MI commons is that all middleware projects could work against external versions; a visit there would remove any need to guess which versions to use.

{Tom} explained a use case involving a need for a subject-oriented custom LIMIT, which may lead to exploring custom limits. At U. Chicago, they are exploring an approval tool, which allows you to designate who can approve xyz, using distributed management. They’ve wrapped a custom UI around this, and in many ways, it strives to do exactly what Signet is doing. One item they are looking at is to put in a limit that would put in potential users who would be targets of that approval relationship. This prompted {Lynn} to ask if does the custom LIMIT API supports this need? Can they develop a custom LIMIT a Nick - develop a tile to represent that? Also, this would use DHTML, and you could have dynamic content (though no coded content yet). It might be a possible reuse of the Subject API, if there is interest in that.

The need to find people is important, in a way that a query might return a relevant population. How might it be stored? As a subjectID reference or an enterprise identifier? A grantor should not be able to have self-approval rights. While some of these ideas seem to intersect with workflow ideas from the recent Advanced CAMP, it is not a goal to reproduce workflow. The data to be maintained would be very flat and binary – and would not use core capabilities. This may even lead to non standard privilege structures, where one object approves another object.

The next Signet WG conference call will be on Friday, August 18, 2006 at 11am EDT.