*Attendees*
Lynn McRae, Stanford U. (chair)
Dave Donnelly, Stanford U.
Minh Nguyen, Stanford U.
Tom Barton, U. Chicago
Jeff Van Eeuwen, U. Chicago
Gil Singer, SNtial Technologies
Ann West, EDUCAUSE/Internet2
Michael Gettes, Internet2
Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)
Carry Over *Action Items*
[AI] {Lynn} will follow up with {Michael} regarding how much history should be kept, and just how it is kept. (3-Aug-07)
[AI] {Dave} will add LDAP config samples in the wiki for sources.xml file. (3-Aug-07)
[AI] {Lynn} will share an updated version of use cases for Hooks. (25-May-07)
[AI] {Tom} volunteered a role in vetting Signet with Grouper to have a common JVM. (25-May-07)
Future *Agenda Topics*
- Kathryn Huxtable - Recent Subject adapter/source activity
- consolidating subject stuff from Signet/Grouper under I2mi-Common management.
*Agenda*
1. A taste of dogfood
2. XML generation status, with a brief digression into <subject> in the context of these documents
3. Our general discussion item will be the migration of the Subject facilities to I2MI Commons, an action item I can pursue independent of development (for now). I'll have more in writing [1] before the meeting, but the general areas of discussion are not just the logistics of this, but the why's and what. As a starter list, we have:
- the definition of a Source manager and how that's reflected in sources.xml
- the definition of a Source Adapter and how that shouldn't be reflected in sources.xml
- Signet extensions for attribute mapping that maybe should be migrated into core Source support
- the light-weight/local subject tables used for demos/quickstarts
*Discussion*
-A taste of dogfood: COManage-
{Michael} is working on a project called COManage, which is an effort to integrate Internet2 Middleware (Signet/Grouper, etc.) into a production state for an initial roll-out to manage services for Sympa and confluence. He added that there commitment to get this up and running on the server side, so applications can then make use of it. The main goal is deployment for daily use. Once a few items are successfully integrated, other services will be added. Initially, Signet will not be exposed in COManage.
{Tom} stressed that an important aspect to remember is the non-technological items, i.e., determining who should have which role for which tasks.
{Tom} gave an update on a recent call that raised the surrounding issues that were of greatest impact to the COManage work. They discussed what the internal scope should be, e.g., community Working Group, wiki, etc. They also brainstormed areas in need of support for delegation to resources by Internet2. Further discussion is needed on areas such as federations, where a provided platform or service would help in facilitation. Other efforts in the U.S. and abroad will emerge in time. Just outside these efforts, there is a desire to develop standards that would guide application developers on integration items, such that anyone participating in these areas can do so in a similar manner, for simpler interfacing and protocol exchanges.
The Group briefly discussed funding sources and how that impacts the “in-between” efforts, such as Ldappc, and how they are used or integrated. Until these have a proper home, it will be a challenge to devote sufficient resources to these efforts.
- XML generation status, with a brief digression into <subject> in the context of these documents-
{Dave} has been working with Gil and Jeff at U. Chicago on the XML import/export. He recently shared an API that satisfies their needs and will allow them to build on top of it for work on their Authority Manager. It is designed using JAXB, a set of classes binding to XML, i.e., it writes an adapter layer that can speak to the binding layer and Signet. JAXB is a good tool for rendering an object in XML in both directions.
The ease of using JAXB means that most of the effort can be applied towards dealing with the adapter classes. The schema generated will be extensible, so {Gil and Jeff’s} need to turn Signet XML into Authority Manager XML is possible. They will not need to understand the Signet side, they can just use it.
Regarding assignment permissions, {Dave} is close to wrapping up the import work. He will follow with the export items.
{Lynn} reminded the Group that one aspect of the design of Signet Subject addresses the issue of "enterprise identifier mapping": the fact that different consumers of Signet XML may know subjects by different institutional identifiers, e.g., login vs. employee vs. student ID. Signet configuration can specify the critical "identifier" set (that corresponds to the subject API notion of get- subject-by-identifier), and the developers plan to have this be the default set of attributes included in subjects references in any XML document. This is key for integration efforts.
-Migration of Subject facilities to I2MI Commons-
{Lynn} said they are working to bring the work of attributes around Subject and migration into I2MI Commons, which will advance from the current v0.3.1; see: < https://wiki.internet2.edu/confluence/x/CTQ >.
{Michael} requested that an effort be made to align all I2MI products under the same version number, which would eliminate the need for developers to remember which versions of which products are compatible. Not only would this improve integration work and implementation, but it would act to ensure a certain level of quality assurance that all products do in fact work together properly. For example, I2MI-Commons might be given an agreed upon version number, though the contributed source adapters would be remain independent. {Minh} agreed that both Signet and Grouper should agree to use the same version of the SubjectAdapter implementation; most will use what is simply provided out-of-the-box. Additionally, projects ought to see eye-to-eye on other versioned items such as Hibernate, GH cache, etc.
{Lynn} spoke of taking a local implementation in Signet and combining with the sources of Subject, for a best implementation available in common, with a common version number. As a result, Subject would act as an independent ‘bubble’ between Signet and Grouper.
{Michael} also asked whether the QuickStart should be using an LDAP subject source as opposed to what is now done as an internal source. {Lynn} said the QuickStart is meant to be self-contained, that there is no LDAP equivalent.
The next Signet Working Group call will be on Friday, September 14, 2007 at 11am EDT.
[1] C.f. Lynn’s email on 30-Aug-07, subject: Signet call: subject matters
https://mail.internet2.edu/wws/arc/signet-dev/2007-08/msg00011.html