Signet Conference Call
August 5, 2005
*Action Items*
New
[AI] {Bob} will send .htaccess local syntax to the group via the list.
[AI] {Lynn} will review the July 8, 2005 conference call minutes.
Carry Over
[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] {Lynn} will contact the development group in Australia about their UI development efforts.
[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 Brown (Bristol)} 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.
*Participants*
Lynn McRae, Stanford (chair)
Minh Nguyen, Stanford
Brendan Bellina, USC
Ido Carmi, USC
Linh Pham, USC
Bob Morgan, University of Washington
Gary Brown, University of Bristol
Simon McLeish, London School of Economics
Steve Barrett, Cornell University
Lynn Freshour, Internet2
Mike McGill, Internet2
Steve Olshansky, Internet2
Terrie Clark, Internet2 (scribe)
*Discussion*
Signet’s current privilege document available through the Signet demo expresses an association between a subject and a privilege. Incorporating a privilege element into the privilege documents will be discussed during a future WG conference call.
An updated copy of the Signet specification sheet including a comparison of Grouper specifications is available now, and was sent to the WG list on 5-August for review. The WG desires to gain a more thorough understanding of institutions’ operating environments to facilitate Signet’s adoption in the R&E community. Since Signet does not require use of JSTL (JSP Standard Tag Library) as a template language, it should be able to operate on Apache Tomcat v5 using Java Servlet v2.3. It is thought that this will enable broader acceptance of Signet. Signet has been developed to operate on Servlet v2.4. And, changing to Servlet v2.3 might alter the web XML configuration file. The WG will attempt to verify this prior to the next WG conference call.
Grouper uses XHTML because it is more accessible and more formal than XML. Development efforts to change Signet to XHTML are thought to be minimal. Browser capability with Firefox is desirable.
The WG will soon decide what features and functionality should be included in Signet’s v1.0 release. Some of the features being considered are conditions of dates and subsequent related status of an individual based on the date, and the affiliation of individuals and the designation of drivers. There are two types of designation of drivers. The first is the functionality of permitting an individual to grant another individual’s privileges, for example allowing a CIO’s administrative assistant to grant the CIO’s privileges. The second designation of drivers is a temporary proxy - like granting of privileges for individuals on leave of absence or holiday. Should these features be included in Signet’s v1.0 release? How would the designation of drivers be reflected in the privilege document? The group will prioritize these and other feature enhancements along with performance tuning and installation simplification during the next call.
If an LDAP adaptor is developed for Signet’s subject API, then Grouper may utilize it as well.
The group also discussed implementing simple date-based conditions to verify the status of an individual at an institution. Generally speaking, once an individual leaves an institution, their privileges affiliated with that institution are revoked. The WG proposes a simple set of rules that will evaluate attribute pairs found in the subject interface. If an individual is associated with a source in the subject interface through the subject API, then this becomes a testable set of assertions. How are status changes known in an ongoing way at most institutions?
If an institution has ongoing messaging and there is a message about the change in an individual’s status, then Signet could respond to the message and reevaluate that individual’s assignments and take appropriate measures, although it may lessen Signet’s acceptance by institutions if such a messaging system is required for Signet’s implementation. Perhaps the WG could develop a stand-alone feature of Signet that can reevaluate the status of all individuals on a periodic (e.g. nightly) basis. This solution does not seem to scale easily. But, early adopter institutions of Signet may already have an individual status monitoring system.
The group discussed the desirability of consistent mapping possibly provided by Signet, Grouper and perhaps other institutional systems. The current method of mapping at most institutions can be described as inconsistent.
It might be worthwhile for Signet to use the same expression language that Grouper supports. It is desired to keep the syntax language for rules evaluation simple, perhaps a Boolean or parenthetical representation of name and value ID attributes. Sun Microsystems provides a library that can evaluate expressions. This type of evaluation can complicate implementation for a metadata assignor. At most institutions the conditions will be maintained by individuals who might not know expressional code languages. The group has not yet addressed input to express conditions. Perhaps Signet’s v2.0 releases may include a GUI to simplify the expression conditions expression language for the metadata definer. The group is evaluating options for conditions and expression languages.