Signet Conference Call May 27, 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
Gary Brown, University of Bristol
Shelley Henderson, University of Southern California
Brendan Bellina, University of Southern California
Tom Barton, University of Chicago
Bob Morgan, University of Washington
Steve Barrett, Cornell University
Karel Sedlacek, Cornell University
Keith Hazelton, University of Wisconsin - Madison
Terrie Clark, Internet2 (scribe)
Steve Olshansky, Internet2

*Discussion*
Two issues remain unresolved with the Subject API. The first is what identifier is the primary ID of the subject? The subject type combined with a subject ID? Or, a source ID combined with the subject ID? What is the recommended practice for interoperability with Grouper and Signet? The second issue is does the Subject API need to associate the authenticated user with a subject?

It is preferable that one unique subject ID exist per authenticated user. It is also preferable that the application-side of the Subject API determines which subject ID to use if an authenticated user is located in multiple subject sources. The debate is over subject uniqueness by subject type or subject source. And, is it the role of the subject API to reconcile an authenticated user's ID, if that user is located in more than one subject type or subject source? Uniqueness may be easier to ascertain by subject type. If the same entity exists in more than one subject source, then the group agreed that the reconciliation should be done by the implementation-site side of the subject API, not by the subject API nor by Signet nor Grouper. Identifying subject sources and types in a federated environment will not be addressed in this version of the Subject API.

Two considerations exist for the privilege document. The first is how will the privilege document account for conditions? The privilege document has been revised to reflect that a privilege is permission, and that permission has a limit, and that there is a value chosen by a user for the limit. Organizing the privilege document in such a fashion satisfies the group's first use case regarding provisioning. Can conditions be included in the privileges document as limits? There is, at a minimum, a semantic distinction between limits and conditions. For example, a limit can be a value for a privilege and a condition can be a time-duration for the privilege. Limits are passed to the application and conditions are passed to Signet only. If we include conditions in the privilege document, then individual permissions would have individual conditions. This would make the privilege document rather bulky, but may be required for audit purposes. Since a condition is viewed by some as a limit, then conditions will be included in the privilege document at this time. The group will discuss developing an assignment document for auditing.

The second question with respect to the privilege document is that of scope. Is scope relevant to the privilege document? If it is relevant, then the scope of a privilege should be captured initially by Signet and documented in the privilege document accordingly. Scope does have a dual nature in that it is the delegation hierarchy and it is a factor in shaping authority (whether-or-not an individual can grant a privilege and to what extent that individual can grant a privilege). Scope could be included in a subsystem, but it might not be required as part of the granted privilege. It can be stated in the metadata that if scope is present and pertains to a declaration of privilege, then the output to scope would be a limit to the permission granted in the privilege. If the scope is not pertinent then there is no required output to the limit. There are use cases in which it would be required to limit a permission of a privilege. Scope might be the driving force of making choices about a privilege, but once the choices are made, they are distinct and don't have to be re-qualified.

What is the purpose of scope? How does scope serve Signet? Are there any other aspects of scope that need to be addressed by the group? Is there a scope that limits Signet, the application, with the authority to subsequently limit a set of potential assignees? Stated differently, if a user has a privilege, then can that user grant the same privilege to another user? And, how can Signet control subsequent delegation of that privilege to yet another user? To accomplish this Signet may need a unified population set and the ability to filter the population set. It is desirable to have Signet constrain the ability to further delegate based on scope or another criteria.

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