Action Items
New
[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.

Carry Over
[AI] {Group} will via the list begin compiling scenarios to be used as potential use cases.
[AI] {Keith} will summarize 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 University (chair)
Minh Nguyen, Stanford University
Andy Cohen, Stanford University
Chris Phillips, Queens University, Kingston, Ontario Canada
Julian Lombardi, University of Wisconsin - Madison
Keith Hazelton, University of Wisconsin - Madison
Shelly Henderson, University of Southern California
Tom Pogue, UC Davis
Bob Morgan, University of Washington
Tom Barton, University of Chicago
Steve Olshansky, Internet2
Terrie Clark, Internet2 (scribe)

Discussion
November 1, 2004 is the target date for a working demo of Signet including basic pages to navigate and assignment functionality without limits. The release date target for functioning code is mid December. There will likely be a NSF Middleware Initiative (NMI) release in December that will include Signet and Grouper. Early adopters of Signet are encouraged to provide design ideas, subsystem privileges and function names for the demo. So far, Queens University, UC Davis, USC and the University of Wisconsin (with the University of Minnesota and the Croquet project) have been accepted as early adopters of Signet per the recent CFP.

USC Update – The XML schema is being reviewed to evaluate possible implementation opportunities. Options include a RADIUS dial up server, online documentation for system administrators and a locally programmed network billing database. Selection criteria include technical amenability for, and potential to, articulate lessons learned from the pilot implementation.

UC-Davis Update – A network billing application is being discussed as the pilot application. The telecommunications staff seeks to develop an applicationproviding network contact information to be accessed campus wide. The telecommunications group will provide data with VLANs and departments assigned to those VLANs. Account representatives and network administrators will partition subnets and assign system administrators. The system will have multi-level permissions.

Queens University Update – Queens University is considering a delegated administrative application to grant application owners outside of the IT group access to their applications. In granting them privileges, they would be able to delegate other privileges. The University is looking for use cases for this potential application.

Croquet Project Update – The University of Wisconsin - Madison and the University of Minnesota are developing an online, peer-to-peer technology deploying secure communication within the Croquet environment. They are integrating the architecture with the existing CMS technology to create a scaleable, persistent and extensible interface to network-deliverable educational resources and tools for social presence. This application moves beyond the web page paradigm. Instead of delivering only web pages it can extend and link 3D-type spaces containing resources, simulations, and web pages with each other in a way that is easily authorable. The project will use Signet to manage privileges in a flexible manner. For more information please see www.croquetproject.org.

The group discussed the notion of supporting assignments to groups to not only record the assignment, but also manage the permission on an individual basis. When monitoring a group’s membership in an ongoing fashion, a privilege document is generated for an individual. The document would represent all of the permissions that the individual has received directly by individual assignment and by group assignment. This would enable prerequisites and conditions to be applied on a case by case basis. The assignment could go to a group as long as the individual is at an institution, but if the individual stays in the group but leaves the institution s/he loses the privilege(s).

Another approach would be to simply report the assignment to the group as a group privilege document. This would determine if an individual is a member of that group and acquired their permissions through the group. The responsibility of maintaining accurate membership lists falls to the group, not the application. Signet can support both approaches. If a target system has roles that equate to groups, then Signet can be used to assign privileges to that group, thus implying that membership in a group is ascertained by the presence (or lack of) of an assignment. Roles and business objects can be represented as functions in Signet -- then group assignments become unneeded. What happens when the primary origin of identifiers is not within Signet? How does Signet work with a separate repository of identities?

Even with released attributes, the application would understand that a Shibbolized application can access any other application based on a permission list. It would be the same as the application looking this up in a directory. Should we continue exploring this? It was decided to wait before we decide to broaden the model and requirements of Signet. A privilege document can be about a group and can be populated with usable attributes in a directory.

What fraction of the Grouper API is required for Signet conformance? What are the requirements for management of groups? Signet should define the group interface and adapter.

Signet requirements state that an identity management system is required. How does Signet learn of individuals joining VOs without an identity management system? Signet as currently envisioned cannot be that imprecise. This is a topic for the next call.

The next call is Friday, October 29, 2004 at 11:00AM ET.