*Action Items*
Carry Over
[AI] {Lynn} will contact the development group in Australia about their UI development efforts.
[AI] {Tom} will work on coming to agreement on the subject interface.
[AI] {Group} will respond to Minh’s subject API proposal.
[AI] {Minh} will research at Stanford to see if Sakai has enterprise integration aspects that might also apply to Signet and Shibboleth.
[AI] {Tom} will arrange and send a conference call/agenda to WG for enterprise integration within Internet2 UI contexts for Signet.
[AI] {Lynn and Minh} will provide the written summary of the conditions and requirements for privacy and security.
[AI] {Jennifer} will solicit on site feedback from UC Davis about the UI demo/mock up.
[AI] {Lynn} will send out a revised development roadmap.
[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] {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
Jennifer Vine, Stanford
Gary Brown, University of Bristol
Tom Barton, University of Chicago
Bob Morgan, University of Washington
Steve Carmody, Brown University
Terrie Clark, Internet2 (scribe)
Steve Olshansky, Internet2

*Discussion*
The group discussed how an API should support group method capabilities. Within Signet, a subject API will exist to facilitate identification of individuals or groups. A subject in the subject API could be an individual, a VO or another group-type. The challenge at hand is to determine how to best handle the three types of subjects in terms of identification. Since Signet will assign privileges based on individual’s attributes or group membership, then, at some point in the system, the individuals’ attributes and group membership should be determined. If viewed solely as group subjects, then a single subject could be an individual or a group. Will Signet have a requirement to look at group-type subject for individual membership? Or, can Signet view only the group-type subject? And, how should this structure be reflected in the subject API? How, then can we determine from a subject that it is, indeed, a group?

Signet could have subject types, but this is a complicated development effort. Or, an additional source ID could be used to indicate that the subject is a group, thus, providing membership information about the group. This would require Java class mapping. For each different type of subject that might be available in the subject API, there might be sophisticated requirements for interacting with subjects. Should we build a subject interface with all the requirements and varying levels of sophistication? Or, should we list only basic requirements for the subject API?

It was determined that Signet will need enough details about a subject to reference the subject. Perhaps, the Signet subject API can accommodate wide variances in subject type if programmers can build the necessary hooks into the local group membership infrastructure. This is possible, but may lessen Signet’s acceptance due to limited local institution development resources. If a developer uses Signet’s subject API to get a group’s list of members (name ID) and everything else necessary for the UI to identify a person, then this identifier could be shared by a privilege management system. If more information about the individual or group is desired, then the ID source (LDAP, etc.) should be identified.

Signet could have the capability to ascertain or de-reference a group’s membership and tie that information as a first class subject to other local resources. Or, the local resource could provide group membership information creating several individual subject types identified by group membership. Signet could be configured to locate group information to provide the data to the subject API. And, the subject API could be designed to interface with local database repositories.

If there is a collection of subject types and we know that one of the subjects is a group, there might be independent methods for ascertaining the group’s membership. These independent methods should be further investigated. Otherwise, the subject API could become cumbersome. Or, we could develop a robust subject API that could be adopted by other applications. We can begin by developing a list of basic requirements for the subject API and then evaluate application for future functionality. This could allow the subject API to extend to other Internet2 Middleware Initiative (I2-MI) applications. The WG desires to provide a consistent method regardless of application or implementation allowing institutions to customize applications.

The next call is Friday, April 1, 2004 at 11:00PM ET. The call in number will be sent out with an agenda prior to the call.