*Action Items*

New

[AI] {Lynn} and {Tom} will develop a presentation for the Signet session at the Fall Internet2 Member Meeting.

Carry Over

[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 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)
Andy Cohen, Stanford
Minh Nguyen, Stanford
Karel Sedlacek, Cornell University
Tom Barton, University of Chicago
Brendan Bellina, USC
Ido Carmi, USC
Gary Brown, University of Bristol
Terrie Clark, Internet2 (scribe)
Steve Olshansky, Internet2

*Discussion*

The group discussed non-technical development issues for Signet. As Signet’s technical development moves closer to the release of v1.0, then it will be necessary to develop the various documentation, public website, and marketing collateral required for a mature product. Since synergies exist between Signet, Grouper and Shibboleth, as the 3 core software development projects of the Internet2 Middleware Initiative (I2MI), it would be beneficial to take what we have learned from the Shibboleth project and develop these materials with a consistent structure and approach. The group will also develop case studies for Signet. WG members will discuss this at the Fall Internet2 Member Meeting, at which there will be a Signet/Grouper BoF. For more information please see: http://events.internet2.edu/2005/fall-mm/. The WG hopes do demonstrate the Signet UI at the BoF.

Efforts are underway to include time-based conditions in Signet. The basic condition requirements for Signet are the ability to grant, extend or revoke privileges based on an individual’s status with an institution, including an effective date and expiration date for the privilege. Signet may be using APIs to record privileges added or revoked based on external factors. A more robust version of this incorporates a simple expression language for rule-based conditions.

Conditions are currently displayed in Signet’s GUI using radio buttons, since selections are mutually exclusive to prevent confusion over the desired duration of the condition. The WG decided that this is a reasonable approach and should be included in Signet’s first release. There are no plans for Grouper to include conditions of membership based on a subject’s attribute. A membership management component of Grouper may at some later time include aging as a time-bound criteria. The Grouper API may be used to enhance current registry conditions. Likewise, a group itself can age. Grouper can manage group lists, and Signet can manage the life cycle condition of privileges.

Are conditions present in the source? Or, are conditions attribute based and definable by a site? If conditions are attribute based, then Signet can look for the presence of a positive assertion like an individual’s affiliation with an institution. By using attribute values Signet has the ability to use a simple expression language and define output in terms of ‘and/or’ (i.e. Boolean) logic. The WG will continue to discuss this.

The WG decided that Signet’s first production-level release will include simple attribute tests for conditions. Future version may include a rule adaptor and a policy repository.

A secondary consideration for Signet’s conditions is how Signet will know when a condition has been satisfied. When a condition is no longer satisfied and the assignment must be revoked.

Conditions are implemented and monitored by the institution. It is possible for institutions to query appropriate databases on a periodic (e.g. nightly) basis. Each institution is unique in this regard. The group can also develop a process for Signet to create and send a task to the privilegeEvaluator. This will be a queuing mechanism driving the work that the privilegeEvaluator (a method in the toolkit) would have to do, so that any mechanism -- batch, event-based, even a brute-force sweep of all assignments -- would only have to record re-evaluation requests in that queue. In either case, this can be accomplished in a real time fashion, or in a batch fashion, depending on the requirements and preferences of the institution.

Cornell University is evaluating Signet's use for permit authorization. Once the business requirements for the permit system have been developed, then Cornell will consider using Signet and Grouper to replace the function of the current permit server.

Signet will also manage meta-privileges. Since Signet cannot initially grant privileges to individuals without first understanding a hierarchy, it is required for Signet to grant ‘super’ privileges to the individual who will subsequently grant privileges to other members of the group. This involves granting privileges (in this case, the power to grant privileges) to a subsystem, but not using any privileges in the subsystem. Perhaps the meta-privileges could be granted by the system administrator and viewed proxy-like to appear that Signet itself granted the meta privileges.

The WG will discuss the LDAP subject adaptor during the next call. The next call is Friday, September 2, 2005 at 11:00 AM ET. The call in number with an agenda will be sent to the group via the list prior to the call.