Signet Conference Call May 13, 2005

*Action Items*

New
No new action items.

Carry Over
[AI] {Group} will develop use cases for Signet.
[AI] {Lynn} will contact the development group in Australia about their UI development efforts.
[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] {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
Andy Cohen, Stanford
Mark Jones, University of Texas Health Science Center at Houston (UTHSC-H)
Gary Brown, University of Bristol
Joy Veronneau, Cornell University
Shelley Henderson, University of Southern California
Tom Barton, University of Chicago
Keith Hazelton, University of Wisconsin - Madison
Terrie Clark, Internet2 (scribe)
Steve Olshansky, Internet2

*Discussion*
Signet version 0.4 includes the first version of the Subject API. The development of the Subject API has clarified subject type requirements for Signet. The Subject API standard requires a specific, well-known and registered subject type, for example, eduPerson or eduGroup and Signet. Signet, as an application, also needs to be a subject in the subject API.  Thus, application, in this case Signet, is the third initially defined subject type.
 
A possible fourth, and not yet discussed subject type is an account, for example, a login account.  But it will be hard to image such a subject representing anything other than a person, process or application.  The Signet application will have its own privileges that are assignments within a Signet subsystem. Signet will use privileges assigned in Signet where Signet is the agent itself.

How then will the Subject API support multiple subject sources? Or, could an implementation adaptor support multiple subject sources? The proposed Subject API could support either.

Regardless, presenting the subject source in the UI using abstractions from multiple subject sources might be difficult. The subject source could be represented as an operation or attribute of each subject. As a fully qualified name or identifier of a subject, should the source also be defined? Does the end user need or care to know the source of a subject? If subject sources are simply data stores from which Signet gains subjects, then identifiers will have to be organized so that they are unique to each subject type.

Perhaps it is not necessary to reveal the subject ID in the UI. Since we recommend EPPN as subject ID, then the privileges document might have three sources using the identifier from the same name space. This requires revealing the subject type identifier to the user using a description or in an additional attribute.
 
Perhaps an institution could develop a composite source and then a search could identify different namespaces for sources; one for each population and one for all populations. How will we combine the output for searches across multiple APIs? Should this be the required method of supporting multiple sources in Signet? Should we require the subject adaptor to combine all sources into a single composite source? Or, can Signet search across multiple sources?

It is preferable to have Signet search across multiple sources, although a search across multiple subject sources does imply that the search also goes across multiple supporting systems for each subject source. How will Signet manage different system requirements such as query timeouts and other system outages across multiple systems? These are compelling reasons to use a composite subject source. How will Signet process partial versus complete search results? If one or more searches return a subject, then that subject should be collapsed into a single attribute set. In this case which subject source attribute set does Signet use? Can the UI collapse the attribute set?

Signet does need to ensure that attributes are not duplicated so it understands which attributes to use and which attributes to ignore. A Subject adaptor that resolves all these issues is in reality an identity management system. For now Signet will query only local sources, however at some point it may become necessary to query directories in a federated environment. If Signet's Subject API is required to query multiple local and possibly federated subject sources, then an institution should be required to implement an identity management system.

If a search must return a subject ID for attribute mapping to the Subject API, then how many logically identified identifiers are necessary for translation? The Stanford system uses three; a registry ID, a university ID and a network ID. How many identifiers are required for Signet? At the moment of translation only two are required; a source and a target . Will the privilege document supply all the possible sources and targets? Signet should require unique identifiers, however there are currently no use cases for this.
 
Grouper can list group members in a static fashion. Additionally, members of groups can be determined by attributes of potential members in a dynamic fashion. Both methods can result in a subject ID, although Grouper does not define dynamic groups.

The WG will work on defining a resource and the control of scope during the next call.

The next call is Friday, May 27, 2005 at 11:00 AM ET. The call in number will be sent out with an agenda prior to the call.