Signet Working Group conference call Friday, September 30, 2005

*Attendees*
Lynn McRae, Stanford U. (chair)
Andy Cohen, Stanford U.
Linh Pham, USC
Andrea Beesing, Cornell U.
Stephen Barrett, Cornell U.
Butch Labrecque, Cornell U.
Joy Veronneau, Cornell U.
Karel Sedlacek, Cornell U.
Tom Barton, U. Chicago
Blair Christensen, U. Chicago
RL "Bob" Morgan, U. Washington
Gary Brown, U. Bristol
Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)

Carry Over *Action Items*
[AI] {Bob} will send .htaccess local syntax to the group via the list.
[AI] {Tom} will send a few brief Signet case studies to the group via the list.
[AI] {Group} will develop use cases for Signet.
[AI] {Jennifer} will solicit on site feedback from UC Davis about the UI demo/mock up.
[AI] {Minh} will develop a list of requirements for how Signet will interface with LDAP and Grouper.
[AI] {Tom, Jennifer, and Gary} will discuss the modularity of Signet’s UI and the internationalization of code for Grouper and Signet. There will be a separate call for this item.
[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.

*Discussion*
Signet v0.6 is in the final stages and a target release date within the next two weeks is expected. New features to be included are proxy functionality and support for internal roles – administrator and subsystem roles. Signet v0.6 unifies assignment display code to include proxy and allow switching between assignments you have and assignments you gave, and eliminates a UI bias towards people who are grantors. A logged-in user may not actually have granted nor been given privileges – they may only be looking at assignments given to another person.

Signet release v1.0 may only include functionality for the UI, allowing time for the API to support backward compatible functions. The Group is still working on defining a varied set of use cases, so as to provide corresponding solutions.

The Subject API will have its initial release soon after the Signet 1.0 release, and will be a critical addition to Signet and Grouper alike. In the future, it might be extended to express relationships between subjects as a possible simple approach to supporting both tree and group structures through a common API.

At the Fall Internet2 Member Meeting, there was discussion about which kinds of technologies or documentation structure are available. It might be advisable to look to the future and plan on incorporating those I2MI technologies that could benefit Signet and Grouper. Attendees also expressed concern regarding the scope of integration for Signet and Grouper – how well do other applications plug into Signet? What are the complications of integrating Signet across multiple applications?

{Tom} mentioned that a generic loader is needed to move information from other sources into the group registry, at least until people are writing their own loaders. {Minh Nguyen} had discussed the possibility of having an XML revision of a subject loader for the local subject table in Signet. {Minh} and {Jessica} are working to identify exactly how much configuration is necessary or desirable, versus simply having a pre-loaded template.

There was a question about terminology - whether the subject ID, opaque subject ID and unique ID have the same meaning – they do. Consistency in terminology across the application will be especially useful to the users as they map namespaces across applications. Given a unique internal key, you would have a bag of attribute with a known set of information, such as login ID or university number. The set of attributes would contain enough unique information that the authenticated user can be identified, by more than simply the login ID. It is an individual choice under the scope of interoperability, whether there is a campus-wide ID that is shared with other applications.

Discussion turned to a situation resulting from having a requirement to implement a Subject API binding of a local user. There needs to be a way to associate the login ID (Tomcat) with the LDAP entry. This led to talk of degenerate cases where, for example, in Grouper, anyone who is the agent may be able to view things – publicly – which is an unauthenticated situation. Is there a need for anonymous authentication? Currently, the emphasis is not so much who you are, but that you are able to authenticate – through login passwords or Kerberos, etc. Gaining access to the application is addressed separately from giving privileges.

{Lynn} asked if there was interest in or a need for a principle identifier – if you are sharing a set of IDs for use in multiple systems through provisioning, you may also want to know which identifier is the login ID. This presents a use case for mapping several identifiers.

The next Signet call will be held on Friday, October 14, 2005 at 11am ET.