Signet Working Group conference call
April 14, 2006

*Attendees*
Lynn McRae, Stanford U. (chair)
Minh Nguyen, Stanford U.
Dave Donnelly, Stanford U.
Jennifer Vine, Stanford U.
Brendan Bellina, USC
Will Norris, USC
Tom Barton, U. Chicago
RL “Bob” Morgan, U. Washington
Joy Veronneau, Cornell U.
Nate Klingenstein, Internet2
Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)

New *Action Items*
[AI] {Tom} will connect {Lynn} with {Frank Siebenlist} to discuss issues of mapping signet-ese into XACML.
[AI] Contact {Lynn} if you identify additional functional requirements for your local project.
[AI] {Nate} will send a link to the list with beginning thoughts on VO implementation.

Carry Over *Action Items*
[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*
The Spring 2006 Internet2 Member Meeting will be held on April 24-26 in Arlington Virginia: <http://events.internet2.edu/2006/spring-mm/>
– Monday 4/24, 10:30 – Grouper/Signet Combined Working Group Meeting: this will be our working group meeting for that week. – Monday 4/24, 3:00
– Signet/Grouper Early Adopters Meeting: this is a closed follow-up session for the deployment workshop.
– Wednesday 1:15 – Managing Roles and Privileges with Grouper and Signet Middleware: this presentation will be netcast.

The Signet Wiki is under construction; further notice will be sent to the list when the wiki is available for viewing and contribution.

{Lynn} emailed the list regarding planning that he and {Dave} outlined through Summer 2006. They listed several items regarding bug fixes, Signet API, Subject API, packaging, features, and administrative aspects (cf. Lynn’s email 13-Apr). {Lynn} welcomes feedback, comments and suggestions regarding items of particular interest.

The Group discussed designing resource as a part of scope. There are two restrictions on transforming current permissions into XACML – what part of a permission should map into a "resource", and when is scope to be considered a qualifier for the permission along with other limits. The Group discussed explicitly designating "resource" as a part of a permission, and adding metadata indicating when scope was necessary for interpreting the permission. {Nate} suggested gathering ideas that could be brought to the standards body. Further discussion regarding proposed metadata and its relation to XACML will be discussed on the next WG call. [AI] {Tom} will connect {Lynn} with {Frank Siebenlist} to discuss issues of mapping signet-ese into XACML.

{Lynn & Dave} will be busy addressing items before the API v1.0 is released. There is much to be explored, regarding properties and behaviors that Signet wants to implement against the API. They are also working on the packaging of Signet using Ant, and making it more flexible.

Localization/globalization is also a key component of the architecture. {Bob} raised concern about differentiating between site customization and language support. English text can be replaced with the language of choice, depending on if it is set up as a resource or not.

Additional work includes testing attribute value assertions against a subject, user notifications, and group interaction. The Group discussed articulation of privileges, both direct and indirect, for a subject. Keeping the focus general will help to address issues that most campuses are facing first.

{Joy} expressed interest in being able to map to a member of a group, in addition to the existing assignments and privileges. Mapping is a valuable tool that should be addressed in the future, though it is not critical at this point. Another item for the future is making sure that an application is customizable through tiles.

Regarding administrative issues, {Lynn} discussed assignments in and out via XML, and convenience of loading. An administrative UI is missing, which might necessitate a sysadmin type for more technical work in the command line. [AI] Contact {Lynn} if you identify additional functional requirements for your local project.

{Nate} asked how Signet plans to interface with Shibboleth – will information be pulled directly from Signet? How might LDAP provisioning to a directory serve these needs? This raised questions regarding why you would want or need a direct Identity Provider connection to Signet. How does privilege transport relate to deployment? Appropriate attributes could be included in the API, which might answer the same questions that an XACML document aims to satisfy.

{Brendan} discussed USC’s future plans for design work of mapping education structure. There is a lot of policy, in terms of what a Service Provider ought to provide, that needs to be addressed. Translating requirements into functions is a challenge.

[AI] {Nate} will send a link to the list with beginning thoughts on VO implementation <https://authdev.it.ohio-state.edu/twiki/bin/view/Main/>. Further discussion may lead to outlining case studies as a next step.

{Lynn’s} second email (cf. 13-Apr) addressed the functional aspects of subject-related properties. How should things be defined to accurately capture the desired functionality? Which factors influence how a subject is defined? The Subject API doesn’t specify subject types; properties define whether a subject is a “person” or a “group”, and if it is not specified, Signet proceeds in a neutral manner with disregard to the actual subject type. For other non-person/group entities, such as an abstract process or organization, they can still be distinguished.

Lynn detailed other properties from the email, including where the Subject API distinguishes which sources from which contexts. These properties tell of populations to be found at log-in or online searching. Signet also is capable of asking which source you would like to search, and if you would like to search some or all sources. There is a set of per-source properties, with behaviors that vary by source. There are additional properties to use for “names”, but if it is not specified, the value returned from the getName() method of the subject API will be used. The UI might have options for properties (subjectPrincipalName or principleName) to present data about a subject, with optional data alongside the “name” or optional identifier information to further identify the subject. Furthermore, it is desired to be able to output selected subject attributes as part of the <Permissions> document. How much mapping capability should be incorporated into the product vs. into provisioning products? Refer to the “Signet properties for using the Subject API” thread for more specifics (13-Apr.)

A previous conversation regarding Subject searching in the Subject API will continue on the next WG call.

The next Signet WG conference call will be on Friday, April 28, 2006 at 11am EDT.