Signet Working Group conference call
February 17, 2006

*Attendees*
Lynn McRae, Stanford U. (chair)
Gary Brown, U. Bristol
Brendan Bellina, USC
Tom Barton, U. Chicago
RL "Bob" Morgan, U. Washington
Tom Poage, U. C., Davis
Karel Sedlacek, Cornell U.
Butch Labrecque, Cornell U.
Andrea Beesing, Cornell U.
Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)

Carry Over *Action Items*

[AI] {Lynn} will request a copy of the guidelines for logo use from {Greg Wood}.

[AI] {Lynn} will move the documentation from the Stanford site to the Signet WG homepage.

[AI] Please contact {Ann} if you are interested in registering for the Signet/Grouper Early Adopters Deployment Workshop: <awest@educause.edu>.

[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*

Signet v1.0 has been released (16-Feb); the software and documentation can be found at <http://signet.internet2.edu/>. {Lynn} has fixed a few minor things found, and {Tom P.} is doing some Oracle work, looking at various environments. Plans for the Early Adopters Signet/Grouper Deployment Workshop in LA are underway: <http://educause.edu/content.asp?SECTION_ID=187&bhcp=1>.

What are the next steps for Signet? {Lynn} is soliciting ideas, so as to best devote resources where the Group is most interested in seeing Signet progress. The toolkit API itself needs some work to get to a stable point, as well as several other features needing to be added. The Subject API is still in draft, but there should be a v1.0 spec available within a few months. The integration infrastructure will also be developed further with time. A GUI might provide an easy means for online administration tools without forcing command lines.

Another direction may be to increase Signet’s ability to ask about and display information. It would be useful to have the capability to ask Signet authority questions, e.g., to find out if a person can do X, without making a full request for the privilege document. One thing to keep in mind is that it might be better to offer Signet as a lightweight, generic package, and avoiding a standard implementation involving more complexity and less flexibility. Two components of using the API are 1) managing and making privilege assignments programmatically, and 2) instantiating Signet and reading privilege as part of provisioning as an alternate to parsing the documents. Ideally, a web service would be wrapped around the API, but it is not built in.

Further areas of development include:
- Solidify the Signet toolkit API to a more formal spec/release (for programmatic use outside the UI)
- Feature build-out - lifecycle rules, more proxy capabilities, more limit/choice types, notification, groups/roles
- Subject API (and more integration offerings, e.g., LDAP Source Adaptor)
- Provisioning and other authorization integration, including eduPersonEntitlement
- Administrative tools
- UI customization

How or should the management interfaces merge? In terms of managing authorizations by defining groups and adding people, does one go in and add one-by-one, or will group memberships be loaded by batch? Policy will influence the administration of individual privileges; definition of groups should be clarified.

The Group discussed security management design and how authorities are used. Are groups made for sharing privileges, rather than having a role affinity? Convenience factor no longer exists once a group is created, as membership is separate from policy. What is an ideal level of strictness over control of which groups are available? How will a person making the assignments be able to view via the context in which they are managing privileges, i.e., if one is logged into the Grouper UI, they would want to limit their view in a corresponding manner.

What level of transparency should there be for an authorized individual adding privileges or viewing groups, etc.? Searching for groups is another reason to enhance the API; depending on who is making the query, a response could be tailored based on their privileges. Limiting mechanisms could be put in place, depending on if querying a subject in Signet or Grouper. Exporting permissions introduces privacy concerns. {Karel} inquired about a mechanism to do an external validation of values that are entered when assigning a limit. There is a declared presentation adapter for defining limitChoice type, using DHTML for dynamic use; this still needs some affirmation that it is a viable approach. The integration of Signet and Grouper will introduce the direct association of groups, entitlements, versioning of logic in metadata, defining metadata sufficient to track changes, etc. The deletion of privileges in Signet or Grouper is another area to keep in mind.

The next Signet WG call will be held on Friday, March 3, at 11am ET.