*Action Items*
New
[AI] {Lynn} will contact the development group in Australia about their UI development efforts.
[AI] {Tom} will work on coming to agreement on the subject interface.
[AI] {Group} will respond to Minh’s subject API proposal.

Carry Over
[AI] {Minh} will research at Stanford to see if Sakai has enterprise integration aspects that might also apply to Signet and Shibboleth.
[AI] {Tom} will arrange and send a conference call/agenda to WG for enterprise integration within Internet2 UI contexts for Signet.
[AI] {Lynn and Minh} will provide the written summary of the conditions and requirements for privacy and security.
[AI] {Jennifer} will solicit on site feedback from UC Davis about the UI demo/mock up.
[AI] {Lynn} will send out a revised development roadmap.
[AI] {Minh} will develop a list of requirements for how Signet will interface with LDAP and Grouper.
[AI] {Tom, Jennifer and Gary Brown (Bristol)} will discuss the modularity of Signet’s UI and the internationalization of code for Grouper and Signet.
[AI] {Group} will via the list begin compiling scenarios to be used as potential use cases.
[AI] {Keith} will summarize the naming discussion and make proposals to begin defining privilege, task, function, etc.
[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.

*Participants*
Lynn McRae, Stanford (chair)
Minh Nguyen, Stanford
Andy Cohen, Stanford
Chris Phillips, Queens University
Shelly Henderson, USC
Brendan Bellina, USC
Bob Morgan, University of Washington
Steve Carmody, Brown University
Terrie Clark, Internet2 (scribe)
Steve Olshansky, Internet2

*Discussion*

The group decided to use Apache Struts/Tiles as framework for the subject UI. Stanford University developers have applied tiles as a means to create a UI plug-in for individual limits giving Signet a ”look and feel” for certain limit types. The development group agrees on this approach and decided that the next steps will be to document requirements including but not limited to common components that can be shared by Signet and Grouper and providing the desired details for what a user can use. The group is aware of other development efforts integrating a UI with Shibboleth, and other Internet2 Middleware Initiative (I2MI) efforts. For more information please see the minutes of the recent call on this subject: https://mail.internet2.edu/wws/arc/signet/2005-02/msg00007.html.

The UI development issues will delay Signet’s production release by approximately a month. The next version will include implementation of limits, a basic UI for assignment flow, and a daily executable to end assignments at the assignments’ ”end of life.”

The group discussed the multiple related efforts related to the subject UI and decided that while it does not provide all of the functionality required by Signet, the OKI Agent OSID (Open Service Interface Definition) may most closely match Signet’s proposed UI requirements. In utilizing the OKI Agent OSID several questions arise:
- Should the Signet developers adopt the OKI syntax?
- How do we separate requirements?
- Can requirements be adopted on a case-by-case basis?
- What is the value of adopting the agent OSID over alternatives?

Perhaps the group would gain additional tools and the ability to leverage an existing implementation for enhancements. There is little or no value to adopting an existing API wholesale except for the ‘inheritance’ of the agent. The group shared concerns about the development cycle timeline of OSIDs.

http://www.okiproject.org/specs/index.html

Internet2 is receiving queries about the target date of Signet’s production-level (v1.0) release. The group indicated that September 2005 is a viable target release date. The group will discuss what functionality will be available in that release.

The next call is Friday, March 4, 2004 at 11:00PM ET. The call in number will be sent out with an agenda prior to the call.