Signet Conference Call July 8, 2005

*Action Items*

New
[AI] {Tom} will send a few brief Signet case studies to the group via the list.
[AI] {Lynn} will via email review carry over action items and remove completed and obsolete action items from the list.

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
Jennifer Vine, Stanford
Tom Barton, University of Chicago
Joy Veronneau, Cornell University
Steve Barrett, Cornell University
Karel Sedlacek, Cornell University
Butch Labrecque, Cornell University
Terrie Clark, Internet2 (scribe)
Steve Olshansky, Internet2

*Discussion*

The group discussed Signet developments to date. A privilege-bearing subject (privilege subject) is an entity within Signet that has privileges and assignments and can grant assignments. This is the basis for the privilege document. Additionally, the privilege subject provides the basis for privilege and assignment caching. Signet will have assignment references available.  Additionally, the privilege subject provides the basis for caching name and other descriptive
information about subjects so that this information does not have to be looked up via the source adapter whenever it's needed to display an assignment or privilege information. Caching provides data redundancy and ensures its availability in the event that a source’s system is not available. The privilege subject also facilitates the ability to make an assignment, as a part of provisioning to an arbitrary string, in the absence of a given subject with no source.

Perhaps the concept that a source’s system might not be readily available at the time of a query requires further exploration. What is the value of the data if the source’s system is unavailable? What if an assignment is removed? It may be problematic to remove an assignment when a source’s system is unavailable. If Signet is regularly monitoring the status of an individual to ascertain requirements of assignments, then what happens if that individual’s source system is unavailable? Is it appropriate to specify that privileges are not available if a data source underlying them is not available? It is possible to develop conditions under which this is acceptable. With caching it may be possible to reduce the negative impacts when a source is unavailable.

What are other considerations to reduce the negative impacts when a source is unavailable? The subject API can provide information as metadata, but it is still largely a function of the application that is using the subject API. The application is doing the caching, not the subject API. The subject API could be modified to cache data, but that will require extensive development.

A privilege history is required for audits and investigations of previously granted privileges. When an assignment is made, its existence is also noted in a history table. Any change to that assignment’s limit or scope is also noted in the history table. Thus, the history table will contain the entire assignment history of a particular Signet implementation. The history table will have date stamps that can be used to create a real-time set of historical data. Signet’s UI has pull down tabs to display assignments given over past several days and inactive assignments. The history table has grantor information as well. Each assignment update will revise the history table’s metadata, not replace it. If an organization is dissolved, then there is still a requirement to record all of the assignments granted to members of that organization. Inactive data could be carried through several iterations of an organization’s tree. Or, a tree adaptor could be altered to get all nodes as opposed to active or inactive nodes.

When is scope relevant to permissions? When is it  necessary to constrain permissions being granted? A permission’s level can require scope as another limit for that permission. This facilitates the ability to use scope in various degrees of permissions.

The privileges document will compress privileges to present a distinct set of privileges. If two assignments have limits that overlap for the same scope, then there will be only one permission output in the privilege document. Future versions of Signet will take multiple permissions with non-intersecting limit values, aggregate them and represent it as one permission with a single multi-valued list. It is desirable to take multiple permissions with non-intersecting limit values and aggregate them. How is this administered? Compression of multiple values for limits might be spread across limits or multiple occurrences of permissions. This concept will be discussed as a potential future development.
 
Privilege document delivery methods will be discussed on a future call.

Scope pertains to privilege management more so than permission management of that privilege. It is about the organization in which privileges are being managed. Scope is not an arbitrary hierarchy applied to a subsystem. For example, one side was looking at managing IP addresses; this is a kind of hierarchy that should not be a scope tree for assignments. It should be the kind of limit to a hierarchy that could be narrowed through a chain of assignments. Scope places managed privileges inside the organizational context. An unexplored feature of Signet is blending limits with scope in the sense that limits validate only accounts.

An additional topic for discussion is that of organizations, committees of organizations, special interest clubs and VO’s. How will Signet represent these types of groups? .

The next call is Friday, July 22, 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.