*Action Items*
New
[AI] {Minh} will look for efforts facilitating subject interface APIs.

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

*Participants*
Lynn McRae, Stanford (chair)
Minh Nguyen, Stanford
Simon McLeish, London School of Economics
Gary Brown, University of Bristol
Shelly Henderson, USC
Brendan Bellina, USC
Bob Morgan, University of Washington
Steve Carmody, Brown University
Tom Poage, UC Davis
Tom Barton, University of Chicago
Blair Christensen, University of Chicago
Terrie Clark, Internet2 (scribe)
Mike McGill, Internet2
Steve Olshansky, Internet2

*Discussion*
The group discussed the subject interface. Grouper and Signet have similar requirements for identifying persons and groups as subjects - as the holders of privileges in the User Interface (UI). The Subject is considered as a separate development from both Grouper and Signet. A core requirements list has been developed. Issues about unifying the subject in group interfaces and collection of subjects to form a group were discussed. How should this be approached? Can the group interface be used? A group is a subject type. If an institution implements Grouper, then it is possible to use Grouper’s subject adaptor class type. If Signet utilizes groups and group repositories to define and retrieve groups, then the subject interface can perform these functions. Will the Grouper subject interface function for Signet? Signet will have a subject adaptor class but its implementation would be to a Grouper group’s interface, which might be different than to its registry and it would have to adapt to be registry rules. Signet might shift to an adaptor class for a group subject type that relies on Grouper as a site might elect to replace the different subject type.

Should the subject type, then, be considered a third development effort that is shared by Signet (and, Grouper)? This is a solution that would function with configuration directories if there were a common subject interface API. Thus, the common subject interface API and adaptor class could be programmed to a repository like LDAP. It might not make sense to duplicate efforts between Grouper and Signet with each having its own adaptor class implementation. Once development of the API begins scope creep can affect the project. However, this might increase implementation requirements for universities. If we were to develop a subject interface API, then would it be applicable to other development efforts? And, do any other efforts exist that might meet the requirements for the subject interface API for Signet and Grouper? Likewise, can we utilize an existing subject interface? How is this different than the uPortal subject interface? It may evolve to larger attribute sets to describe attribute rich persons.

How will subject type be defined? By population? By group? Or, by individual? Will data sources be internal and external to the subject type? The group determined that anything acquired from a group could be considered a subject type. And, that perhaps a new nomenclature/taxonomy for this discussion is required. There are distinctions between population, source and name space. Distinct name spaces with subject IDs might have a subject type matching to an adaptor class. If an institution wants to build an adaptor class representing individuals from three institutions, then it would have obligations inside to create three name spaces.

The group discussed the initial list of functional requirements for the subject interface: Look up service, search service, translation service, and providing a queryer’s information. It is critical that the WG develop a strategy for the API.

Finally, the group briefly discussed the type of queries to be supported by Signet. The group determined that Signet would support simple queries, and that native language would support more complex searches.

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