*Action Items*
New
[AI] {SteveO} will update the WG's web site to include a link to anonymous CVS and the Signet v0.1 tarball
[AI] {Minh} will let send the tar ball location to SteveO.
[AI] {Lynn and Minh} will provide the written summary of the conditions and requirements for privacy and security.
[AI] {Jennifer} will send a note to the list soliciting feedback about the UI demo/mock up.
[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.

CarryOver
[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] {Chris} will contact Minh to discuss the technology managing the user experience within Signet.
[AI] {Minh} will contact Shibboleth developers to discuss UI technology management.
[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)
Jennifer Vine, Stanford
Minh Nguyen, Stanford
Andy Cohen, Stanford
Steve Carmody, Brown University
Tom Arons, UC-Davis
Tom Poage, UC-Davis
Tom Barton, University of Chicago
Terrie Clark, Internet2 (scribe)
Renee Frost, Internet2
Steve Olshansky, Internet2

*Discussion*
The demo is available at http://signet-demo.stanford.edu . The group is seeking institutions other than Stanford to test the demo and review the user interface (UI) mock-ups, linked from the WG page. It would also be helpful to gain a user perspective outside of the financial and human resources environments.

The next NMI release is scheduled for Monday, December 13. Unlike past releases, this release will focus primarily on NMI Enterprise and Desktop Integration Technology (EDIT) Consortium components. Grouper version 0.5 and “Signet – An Introduction” including the previously released Signet documents and the UI mock-ups will be featured in this release. The next NMI release will likely occur in April 2005. It is hoped that this release will generate interest for Signet from the Grids and larger R&E communities.

The group discussed creating a Signet-users mailing list and a Signet-dev mailing list at an appropriate time in the future. The group will also create an additional website for Signet to be used as a marketing tool, similar to the Shibboleth site, when appropriate.

Privacy concerns about individuals’ names and the privileges assigned to them were discussed. An attribute management system like Shibboleth can be used with point-to-point systems requiring tight controls. This type of solution can provide differing levels of visibility into individuals and privileges. Signet is being developed as a collaborative application for open privilege management. Signet does need to understand (at least at a basic level) who individuals are. However, as more Signet user attributes are revealed, institutional requirements for privacy and security increasingly become relevant. This could drive a requirement for multiple authority and privilege providers because some of the information in the registry might be more sensitive than other information. An example of this is that some VO members may not be authorized to see institutional information, or information about other VO members.

Another requirement of Signet is release policy controls, so that Signet can work within the pre-existing access constraints of the user community. Signet also has an additional requirement for parallel controls at the subsystem level. This pertains to provisioning related security systems to require appropriate project credentials to initiate a process or access a resource. The concern is that an institution might require more than one Signet system because it will be difficult to engineer one Signet system to perform with multiple organizational security or access control policies. The Stanford internal audit group has raised this issue with the current Stanford system, however no change requests have been made.

Concerns also arise in attempting to provide anonymity to Signet participants, if and as appropriate. There may be solutions outside of Signet that can manage this. Or, Signet can be developed to accommodate an individual logging in under an abstracted username account (e.g. role based: “Purchasing Manager 3” or under an assumed name. Perhaps individuals within a subsystem can reveal identity and not contact information. And, a subsequent UI could provide a hook to a contact information page. The development group will determine the minimum requirement for individual information within Signet. If a user selects their own personal data management interface, then they could have flexibility with the amount of information they can reveal to other users within the system.

Can Signet specify a valid user population to be a target of assignments? And, what are the Signet requirements for visibility into privileges? If privileges are attached to subjects, then how does the system identify who comes into contact with the authority registry, mediated by the API identified as a subject, so that the internal security can be applied to that access?

As the next regularly scheduled call would have fallen the week of the Christmas holiday, the next call is Friday, January 7, 2004 at 11:00PM ET. Due to the I2 office relocation, an alternate conference call service and phone number will likely be used.