*Action Items*
[AI] {Group} will via the list begin compiling scenarios to be used as potential use cases.

*Participants*
Lynn McRae, Stanford University (Chair)
Minh Nguyen, Stanford University
Ed Feustel , formerly Dartmouth
Brendan Bellina, Notre Dame
Andrea Beesing, Cornell University
Michael Gettes, Duke University
Steve Carmody, Brown University
Chris Phillips, Queens University, Kingston, Ontario
Bob Morgan, University of Washington
Keith Hazelton, University of Wisconsin - Madison
Jim Phelps, University of Wisconsin - Madison
Tom Barton, University of Chicago
Michael Hodges, University of Hawaii
David Walker, University of California Office of the President (UCOP)
David Wasley, University of California Office of the President (UCOP)
George Brett, Internet2
Terrie Clark, Internet2 (scribe)
IJ Kim, Internet2
Nate Klingenstein, Internet2
Steve Olshansky, Internet2
Ann West, EDUCAUSE/Internet2

*Administrative*
All communication and work of Internet2 WGs is subject to the Internet2 Intellectual Property Framework http://members.internet2.edu/intellectualproperty.html, please review this page.

The working group's charter and deliverables, along with call minutes and related links can be found on the WG page at http://middleware.internet2.edu/signet/.

The next call is Friday, July 9, 2004 at 11:00AM ET.

*Discussion*
The group finalized the charter.
1. It will produce a "Privilege Management Recipe" document that describes the functions of a PM Service and its role in the campus IT environment, and detail deployment and use scenarios. Case studies from campuses using PM Services will be developed. The current draft version of this doc is available on the WG page.

Assigning privilege is recognized as part of an institution’s administration operation using rules and auditing. The traditional political concerns of assigning/revoking privilege exist and should be addressed by the institution. The group will encourage institutions to distinguish between establishing privilege and the decision process for software applications. The group understands that institutions changing from their historical functional distribution may experience resistance implementing centralized privilege management. Political and business issues should be modeled on the basis of campus policies. How each department will interact with another will be of interest to institutions implementing Signet. And, it will be required that Signet support centralized and decentralized privilege management. In naming privileges, the name should suggest the definition of the privilege. Role based policy will be recommend to institutions.

2. It will produce a "Privilege Management Toolkit" (dubbed Signet), a software package that can be customized by campuses to deploy central PM Service, including core data management, user interface, import/export functions, etc.

3. It will work closely with related Internet2 Middleware efforts to ensure that Signet can integrate well with other infrastructures. In particular the Grouper groups-management project in the MACE-Dir WG will provide complementary functions.

The group will develop use cases relevant to integrating Signet, Grouper and existing identity management software. The group will ensure that specific use cases are identified through pilots for the first release.

4. It will establish requirements for Signet support of multi-organizational authorization scenarios, in particular the "virtual organizations" by which much modern scholarly activity is conducted.

5. It will support group-based privilege management, and help understand future Signet requirements for interacting with roles and managing their corresponding privileges.

6. It will help establish standards for representing role and privilege information as eduPerson attributes.

The charter was expanded to include representing role and privilege information within the eduPerson schema.

The group discussed issues of obligation and accounting for the use of permissions. Obligation is a concept that is somewhat controversial. What is the nature of the obligation? The application should account for obligations. How are the services going to make use of the permissions? Signet as envisioned is not an authorization decision engine. How will Signet support other architectures/vendor packages and the permission settings in those systems? What applications/architectures will be recipients of Signet permissions? Auditing is a functional requirement of system.

The group discussed privilege definitions that support an application or functionality. Is this a functional requirement? Or, will this concept require changes to the WG's charter.

The Signet Toolkit Development Roadmap can be found on the WG's website.