Signet Conference Call October 29th, 2004

*Action Items*
New
[AI] {SteveO} via email will introduce Lynn to individuals working on the Tufts University Sciences Knowledgebase (TUSK) project.
[AI] {Howard, Julian, Keith and Lynn} will discuss the Croquet/Signet implementation before the next call.
[AI] {SteveO} will follow up with Lynn and MACE offline to determine if the current version of Signet will be included in the upcoming NMI-EDIT release.

Carry Over
[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.

*Attendees*
Lynn McRae, Stanford (Chair)
Andy Cohen, Stanford
Jennifer Vine, Stanford
Rene Shuey, Penn State
Mark Poepping, Carnegie Mellon
Chas DiFatta, Carnegie Mellon
Keith Hazelton, U. of Wisconsin – Madison
Howard Stearns, U. Wisconsin – Madison
Julian Lombardi, U. Wisconsin - Madison
Steve Carmody, Brown University
Bob Morgan, University of Washington
Tom Poage, UC-Davis
Tom Arons, UC-Davis
Albert Wu, UCLA
Terrie Clark, Internet2 (scribe)
Renee Frost, Internet2
Steve Olshansky, Internet2
Ann West, EDUCAUSE/Internet2

*Discussion*
Queens University in Ontario is unable to participate as an early adopter of Signet at this time.

Stanford University’s installation of Signet has been slightly delayed due to hardware issues. It is anticipated that these issues will be resolved by early November.

The next NSF Middleware Initiative (NMI) EDIT release is set for early December. It is hoped that Signet and Grouper will be the keystone software elements of the release. The group discussed that a complete production-level Signet software release may not be ready in time to meet the early December date. However, a Signet introductory evaluation version and demo might be ready for a preview release.

The group discussed Virtual Organization (VO) scenarios for Signet. Are there sufficient requirements defined to Shibbolize Signet? How are members of a VO initially identified in terms of attributes issued? As a VO is established, are all participating members’ attributes required for Signet expressed by membership in the VO? One type of VO (heavy weight) is described as a multi-institution project with adequate funding for architecture and support staffs; and operating with their own directories and infrastructure distinct from the respective home enterprises (although likely linked in some meaningful way). Another type of VO (light weight) is described as multi-institution VO with inadequate funding for architecture components and support staff. This VO leverages a middleware infrastructure at the VO’s home institution(s). Signet’s functionality addresses the second scenario description.

A lightweight VO will use cooperative identification with common attributes assigned by group membership. How does this accommodate dynamic provisioning of a user? Signet might not have prior knowledge of a particular new user, but as an unknown user logs in for the first time and is recognized as having a valid credential from the user’s home security domain, then Signet can acquire information (i.e. attributes) about the user and store that information for use later. In this scenario, the VO name should be established preferably as a URI so that there are no group naming conflicts. An alternative can be to define the membership in advance and determine what information about the membership will be provided to Signet. An assumption driving this scenario is that there is a host institution providing primary directory and other required services for the VO. The host institution is also providing Signet with local attribute management. Attributes are asserted intra-realm as well as inter-realm . Signet provisions access to a campus resource as a resource manager evaluating attributes and thus assigning privileges to pass to the system housing the resource.

Will each resource have its own Signet system? And, how will Signet be used for VO projects where project resources are distributed throughout separate institutions? One way to manage/share the resources is the have one location hosting group privilege management software supporting the entire VO. However, will the resource owner relinquish management control over the resource if the privilege management software is not located near and managed by the resource owner? We can provide metadata describing assertions that a VO uses and use the Shibboleth system to support the passing of attributes for use by the VO resources in making access decisions. This might provide the ability to find a subsystem in XML facilitating multiple institution participation in a VO with each institution managing access to its local Signet.

The local Signet administrator can develop/maintain access control pollicies for the sub-system. What if some institutions do not have Signet? And, what if there are users outside the known identity domain? How will a remote resource’s Signet receive attributes? Can an individual’s UID be used to determine group membership and therefore privileges? How can additional privileges be added through dynamic provisioning? Course management systems require the ability to register individuals from a remote institution so that the individual is placed on the resource provider’s list prior to requesting access to the resource. For more information please see Scott Cantor’s “Use Cases for Course Identifying Attributes in Shibboleth” - http://usfs2.us.ohio-state.edu/MACE/draft-cantor-courseid-usecase-00.html.

The resources themselves can respond to roles and attributes at the time of initial user authentication and can subsequently assign privileges. Can these functions be separated? One way is to manage sub-privileges through individual attributes. Or, a sub-privilege can be a role-based attribute. How does Grouper know who all of the members of the VO are? And, how is membership information for a Grouper group relayed to appropriate institutions to become part of an individual’s attributes used to access a resource? There may be a distinction between managing privileges that map to functions and determining the individual’s position holding the privileges. Ascertaining arbitrary attributes and privileges requires further discussion.

The next Signet call will be Friday 12-November Noon EST.