*Action Items*

New
[AI] {Jennifer} will follow up with SteveO about the UI mock-ups on the WG’s website to ensure that the mock-ups posted to the site are current.

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] {Tom} will work on coming to agreement on the subject interface.
[AI] {Group} will respond to Minh’s subject API proposal.
[AI] {Minh} will research at Stanford to see if Sakai has enterprise integration aspects that might also apply to Signet and Shibboleth.
[AI] {Tom} will arrange and send a conference call/agenda to WG for enterprise integration within Internet2 UI contexts for Signet.
[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] {Group} will via the list begin compiling scenarios to be used as potential use cases.
[AI] {Keith} will summarize the naming discussion and make proposals to begin defining privilege, task, function, etc.
[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)
Andy Cohen, Stanford
Tom Poage, University of California, Davis
Tom Arons, University of California, Davis
Chris Phillips, Queens University - Ontario
Butch Labrecque, Cornell University
Karel Sedlacek, Cornell University
Joy Veronneau, Cornell University
Tom Parker, Cornell University
Shelly Henderson, University of Southern California
Tom Barton, University of Chicago
Blair Christiansen, University of Chicago
Keith Hazelton, University of Wisconsin, Madison
Bob Morgan, University of Washington
Terrie Clark, Internet2 (scribe)
Steve Olshansky, Internet2

*Discussion*
Signet release v0.3 will be available by early May prior to the Spring I2 Member Meeting. This release incorporates full implementation of limits and comparison of limits to ensure that a user cannot grant more authority than they have permission to grant. The new release incorporates Java Tiles in the User Interface (UI), headers and footers. Also, this release will implement the first Subject API including an adaptor to local subject tables and a reference implementation from LDAP.

Signet’s Product Roadmap, Privilege Management Recipe and static demo will be revised for the upcoming NMI-EDIT release. The most current version of these documents will be published to the WG’s website.

The group briefly discussed email threads that have been sent to the WG’s mailing list. There are concerns about Signet’s compliance with ADA standards. Concerns and possible timing for interoperability with Mac IE, Oracle and PeopleSoft products were discussed. Another common email thread is discussion of the Subject API. Is it recursive? Is a group a source? Input from WG members is desired for this topic. The Subject API discussion will continue with the Grouper and MACE-Dir WGs via their mailing lists.

The first implementation of the Subject API does not acknowledge a group as a subject source. Is the current description of information in the Subject API an eduSubject entity? In terms of supporting the Subject API a method for external schematic element translation is required. If using LDAP, then first an information model should be developed. Challenges exist in determining the appropriate information that is input into LDAP.

It was discussed that perhaps an eduPerson entitlement is not a core source of information for Signet. An eduPerson entitlement could be reserved for contract-specified information between an institution and the institution’s service provider. Selecting eduPerson entitlements to parse and input into Signet is a difficult task. The information could also be expressed in a data string or in XML format. Use of attributes from eduPerson entitlements, data strings and XML will require selecting (parsing) data elements from the larger data population making them available to Signet to be used to define privilege attributes. This could also be accomplished with directories.

At some point Signet will need to support XML and URL data formats to input data into directories. While a comma-delimited data format has been used in multiple applications in the past, it was agreed that comma-delimited formatting has reached its potential in the arena and will no longer serve more advanced applications like Signet. One potential solution is to use a string of data to flatten entitlements and put them in a Signet entitlement statement. Another solution utilizing XML for more complex attribute statements could be used in parallel. In considering the XML solution some external applications might not support XML data parsing. Some developers would prefer an XML solution because it has a defined schema that can be applied to another schema. But, if an institution is not using XML, then what schema can be designed to provide the data to Signet?

An eduSubject privilege could be an attribute within an XML schema. So, it could be parsed from the eduSubject, converted to a flattened string and made available to Signet. The per-subsystem object directory could enable the stored XML to be mapped to Signet’s internal storage, thus providing an object per privilege in the system. Or, there could be an object per subsystem containing all of the entitlements for all subjects in that subsystem. Or, there could be an authorization system as part of the XML structure. Each subsystem could be a separate attribute. We could create a directory entry for each subject subsystem with attributes and privileges.

This would be a good topic for discussion amongst Signet’s potential users. What data directory systems are they using? And, what data directory systems are they planning on using? Perhaps an initial deployment utilizing LDAP can be implemented first. And, some network components might have the ability to apply limits as XML expressed roles and policy decisions.

Do we agree that Signet should have a native document representation of its content? Yes, a privilege document should be one of Signet’s outputs. XML pieces have been sent to the group via the list and can be used as a basis for this document. The document could also be a URL source or values of an attribute. Any comments on the layout or design for XML document are welcome. Is it desirable to have a subject/object/privilege? Or, is it desirable to have a subsystem? This would be a freestanding privilege document. Signet’s data could turn into policy rules. But, it cannot convert data into a policy without a target and an action. Scope definition is critical to the construction of the document.

Greater separation of the UI and permissions could help better define the metadata. A limit could be tagged as a resource, then placed in the privileges document as a resource rather than just another limit. How, then, will the user choose an account limits in the UI? And, how does the user set the limit in the UI? These distinctions should not matter to the user, but the distinction inside Signet is important. As we describe the metadata we could call it a resource, but internally it would function as a limit.

The Signet Product Roadmap does not address the means of accessing a permission document. However, in the demo this information is available as a URL. The WG warns that this is not a suggestion for how this capability should be built into Signet.

There is a Signet WG session at the Spring Internet2 Member Meeting, May 2 – 4, 2005 in Washington, DC. The Signet session is currently scheduled for 1:00PM Monday, May 2, 2005. For more information please see: http://events.internet2.edu/2005/spring-mm/.

The next call is Friday, April 29, 2004 at 11:00PM ET. The call in number will be sent out with an agenda prior to the call.