Nadim El-Khoury and Tyler Johnson from the University of North Carolina in Chapel Hill presented information about the creation of the LDAP and SIP directories to be used at UNC. There is also an effort underway to create an H.350 directory to support presence-enabled SIP user agents as part of a project planned in conjunction with the Presence and Integrated Communications (PIC) Working Group.

This topic was initially proposed as a demonstration for the Fall member meeting. However, vendor issues prevented a demonstration at this time. The demonstration was designed to have registrant information populating an LDAP directory and subsequent SIP server. This generated many questions from BoF attendees:

Is a SIP client required for all registrants? Yes.

For devices already loaded with SIP clients, will these SIP clients support multiple SIP servers? There are SIP clients that will support multiple SIP servers; however, a comprehensive list of vendors providing this technology is not available at this time.

If this is to become a requirement of SIP technology, how then should we communicate this to SIP technology vendors? And, how do we resolve account management issues?

If H.350 is used as an enabling technology, then it is possible to demonstrate this technology. It was discussed that once participants experience the ease of use of the technology supported by H.350, then this may prove to be a driver for the on-campus applications of the technology to be created. Since there are clients supporting multiple SIP servers, then why not create an H.350-enabled open SIP server? Concerns over multiple LDAP directory enabled SIP servers and an incomplete XMPP URI definition must be resolved prior to implementing an open SIP server.

The presentations also included discussions about federated secure Internet conferencing. The WG seeks to gain consensus about the best way to accomplish secure multimedia conferencing. A security agent operating outside the particular communication protocol was discussed. The vision of a federated solution supports several real-time collaborative applications like VoIP, Video oIP and possibly IM. The federated model might include a thin client or API between local authentication and the conferencing application. In evaluating the options for federated security, participants discussed the role of client support. Will all video conferencing applications be required to support federated security protocol? Is it realistic to hope that vendors will support firmware updates? Will vendors support retrofitting existing components and software? Since the deployed base of H.323 is so significant, then are retrofits and support obstructive issues? The goal is to have an authentication standard and an open source implementation of the standard. This interrogatory discussion led to the larger question: Is federated authorization a design goal? If so, how should it be implemented?

At Ford Motor Company campuses, authentication is accepted from vendors. However, from an authorization perspective, Ford desires to permit access to e.g. only the vendor’s engineering staff. A common taxonomy is desired by the participants to support this model. It is viewed as the role of a federation to provide a common taxonomy. What level of detail should be provided within the taxonomy? The participants also sought information about the impact that this solution might have on underlying quarantine networks.

Participants agreed that, at this time, an individual department of an educational institution would seek to develop a similar solution. And, the department would need the assistance of a central IT department to facilitate deployment. It was felt that this might be counter-productive to a ‘grass roots’ development effort. A federated approach would provide rules and a trusted structure for authorization. What is the driving need for federated authorization? Students accessing professors in a conferencing application? Professors accessing other subject-matter experts? Documenting a business case for a federated approach to video conferencing and for video conferencing in general is difficult without understanding the underlying need for both. Policy drives the technology. Do we know of existing example policies for which an architecture could be designed?

Could we build an authorization system contingent on identity and authentication? A security agent could not possibly implement all possible policies. The function of a security agent is to acquire some limited information beyond identity. Once the identity and authentication are solved, then the authorization could potentially happen more easily. If authentication is a system level service, then is authorization a pure application level service? Or, can these be layered on top of each other. What are the implications for end user equipment? Should we address this as a hardware solution?