Signet Conference Call June 10, 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] {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
Shelley Henderson, University of Southern California
Brendan Bellina, University of Southern California
Tom Barton, University of Chicago
Steve Barrett, Cornell University
Karel Sedlacek, Cornell University
Butch Labrecque. Cornell University
Terrie Clark, Internet2 (scribe)
Steve Olshansky, Internet2

*Discussion*
The specifications for release 0.1 of the subject API have been sent to the group. One minor planned change to this release is the size of the attribute name within the schema. Anyone interested in providing feedback is encouraged to do so prior to the WG’s next call on June 24, 2005. Version 0.2 of the subject API will include the JNDI implementation. The group hopes to use best practices and perhaps a unique key within and across multiple sources for implemented interfaces as opposed to the subject API. The subject API can only guarantee uniqueness of itself. The method by which an individual creates other sources will also create uniqueness. The subject API will be a component of a larger identity management system.
 
Development of Signet version 0.5 is underway. The core expressions of Signet privileges are represented in the privilege document. How will the privilege document be delivered in various sites? And, what will Signet deliver as its product? The subject API will have a class and a method by which an individual can retrieve the XML for a subject. Are there other expectations for viewing privileges? It is the group’s intention to make available the ability to view privilege documents as part of the UI. Who would benefit from viewing the privilege document? And, should the privilege document be easily viewed? Support organization may wish to view privilege documents. The privilege document could be integrated through http to a web site. The code for this solution will be included in the demo. And, a Java API could be used for the provisioning connector.

Institutional practices for subject information gathering vary widely. It is proposed that perhaps Signet should be SOAP enabled and that connectors be utilized as a web-based solution. A connector utilizing XML could be developed and used for a reference for institutions desiring to support other connectors, for example to LDAP, as well. Information could be transported from a person repository to other systems of record using Perl, Python and C.

How then will Signet access information to return attributes? The group discussed designing a pluggable interface so additional access mechanisms could be ‘plugged in’ in the future as needed. This can be accomplished through URL access rather than in Signet’s core product. Part of Signet’s core product could include a default implementation as a reference. Any documents delivered by URL would be quickly delivered and not a severe computational burden. Issues may exist if the XML returned contains an error message. The XML message will require parsing to ascertain and communicate the true nature of the error message. Perhaps SOAP enabling of Signet will not be required in the near future of the product, although some institutions are migrating from URL based documents.

The group also discussed assignment editing for Signet. When the group first developed the authority model, a model in which every assignment of privileges occurred as an independent granting of privileges was developed. Shared control over resources requires acknowledgement. Individuals who have the ability to grant privileges may be able to do so at the school level or the department level or both. How will Signet process duplicate (equal) assignments granted to an individual (grantee) by different individuals (grantors)? How will the grantor of the equal or superceding privileges be informed of the grantees’ existing privileges? Signet will not permit a grantor to modify an existing privilege. An evaluation of the hierarchy of limits and hierarchy of grantors should occur in the privilege granting process.

Perhaps a scope equality process should be considered, or we could have a limit identified by the subsystem owner as a resource-identifying limit. This could be included in the equality equation. In all cases, assignments should be recorded permanently in the system. It was suggested to utilize a dialogue box to inform the grantor that a grantee’s privilege already exists and to what extent that privilege exists. Privileges should be stored as data and the dialogue box would ‘pop up’ when a new assignment is equal in nature to an existing assignment. Limits and resource limits would be processed on a case-by-case basis. A grantor will be able to view all privileges for a grantee, and the privilege affected by the grantor would be highlighted in some fashion. A different solution for similar assignments requires more thought. Likewise, a solution for groups requires more thought.

The group has plans to archive every assignment. Thus, every assignment will be written to an archive table. This data could be used to set triggers for criteria, however, such an undertaking would require development by an institution.

The next call is Friday, June 24, 2005 at 11:00 AM ET. The call in number will be sent to the group via the list with an agenda prior to the call.