Signet Working Group conference call
March 31, 2006

*Attendees*
Lynn McRae, Stanford U. (chair)
Dave Donnelly, Stanford U.
Gary Brown, U. Bristol
Brendan Bellina, USC
Will Norris, USC
Tom Barton, U. Chicago
Joy Veronneau, Cornell U.
Andrea Beesing, Cornell U.
Nate Klingenstein, Internet2
Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)

Carry Over *Action Items*
[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} 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.

*Discussion* {Liene Karels} of Internet2 has worked with the developers to design the new Signet (and Grouper) logos (c.f. Lynn's email 30-Mar). Work is being done to incorporate the logos into the web site and also the UI. Logos can be found in CVS of the next Signet release.

The Signet WG welcomed {Dave} as a new Signet developer; he will be contributing his expertise towards the functionality and packaging of Signet.

{Lynn and Tom} reported feedback from the Signet/Grouper Early Adopters Deployment Workshop, held on March 20-22, hosted by USC. General interest in the API was high, with common components from Internet2 middleware. The installfest proved very useful for everyone – getting groups, designing privileges, representations of data ('edu' entitlements), etc. The Signet and Grouper teams are still looking for more use cases, best practices, and shared experiences.

Signet and Grouper currently have very different installation processes. Grouper has an ANT installer, while Signet is binary. Signet will be moving towards an ANT installation as well, and there was little interest in maintaining a binary form once that is available.

There is a range of technologies to move information from a repository into a space easily accessed by applications. Will deployers prefer to have Signet/Grouper to do the provisioning, or do they prefer to do it independently, campus by campus? {Nate} commented that any provisioning from Signet should aim to use a standard language, such as XACML.

{Jessica} is looking for volunteers to work with her to develop both potential and existing use cases. As she continues to develop documentation for Signet (and Grouper), she welcomes suggestions or comments regarding needed information that can be added to the existing documents. Signet documentation can be found at: <http://signet.internet2.edu/documents.html>.

{Brendan} raised concern over the benefits of storing permissions in a single central location vs. locally per application, which may be an initial question that campuses might ask. Organizing and defining permissions for a centrally located system requires resources and an investment of time up front, as well as for continual maintenance of these permissions as applications/vendors change. Focusing on the benefits to central IT applications may eventually lead departments to look towards centralized permissions management as well.

Discussion turned to how to design authority management information, given the nearness or distance from the source of authority. If it is distant from the source, how should it be managed in applications?

{Lynn} is working through the API wish list and had several questions for the group. How can Signet offer specific experiences (menu displays) or solve specific problems (FL/LF names in text) by way of a generic Subject API? What facilities in a reference implementation of a JDBC or JNDI source adaptor would provide the flexibility that sites would need to make their installations work as desired? The Signet Developers are looking for a balance by providing a good out-of-the-box product with enough flexibility to allow for ease of customizing. Certain design decisions are bound to be local and therefore will vary – people will need to know how and what to expect from the applications.

{Joy} wishes to have a FL format for names – if using the Subject API, what form should the name take, how will the product work with Signet, and how can Signet meet design critical for flexibility? She also inquired if there is a way to configure in such a way that you can know where a subject is coming from in the directory. For example, it might be useful to know who is a guest in the directory, without having to recognize the format of a guest's ID. This points to the results, and not so much the search itself.

{Lynn} suggested the possibility of configuring by type – i.e., combining 3 sources for person, and 3 for group. This would enable you to look at the configuration by type, as well as source and type.

Another example is in Jennifer's design, where a menu lists a name followed by its description. Signet currently makes an assumption by the current JDBC source adapter – can you take the assumptions away and put in a source adapter to still have a displayable description?

The Group also discussed searching, constraints on a query for uniqueness, which identifying attribute best fits the most probable search term, how a provisioning connector can avoid a live query by choosing from the subject identifiers listed there.

The next Signet WG conference call will be held on Friday, April 14 at 11am ET.