*Attendees

Doug Sicker - U. Colorado - Boulder
Ameet Kulkarni, Anand Chavali and Mudassir Fajandar, U. Colorado -
Boulder
Nadim El-Khoury, UNC-CH
Art Vandenberg, Georgia State University
Steve Olshansky, Internet2
Ken Klingenstein, Internet2
Bob Morgan - U. Washington
Egon Verharen - SURFNet
Jeanette Fielden - Internet2
Tom Barton, U. Memphis
Michael Gettes, Georgetown

*Discussion*

Interim VC Flow Diagram:
The diagram is a simple logical model of a video call to solicit feedback on how such a call might be structured. The purpose of the diagram is to prove that this web services wrapping approach is viable for initial demonstration purposes to the video community. Browser interactions may be moved into the video client at a later point. Issues that will still need to be addressed include user interface issues on the call acceptance side and security concerns.

In the flow diagram UserA authenticates with Security DomainA, receives a credential then self-registers into a border video directory, receives an acknowledgement, and initiates a call to UserB. There is a mechanism to locate UserB’s Border Video Directory. The UserA directory asks the target directory do you know who/where UserB is? The UserB directory then asks UserA to authenticate. The authentication request goes back to the UserA browser, which presents the credential it received earlier.

The initial flow diagram was modified so that LookupUserB@DomainB is directed from UserA directly to the DomainB border video directory and the result is sent directly back to UserA. It was also changed to reflect that the video client would be engaged after UserB receives and replies to a ScreenPop (for example) requesting a video call. All interaction occurs at the browser level until the very last step. The video client is invoked only after a call has been proposed and accepted. All actions are border video directory and browser oriented until the actual call session is initiated.

Flow diagram Discussion:
This diagram represents a Web services front end that would handle the Authn/z first as a typical Shibboleth use then utilize the SIP or H.323 (or other) protocol for the actual call. The incoming call could inform the target user in a web window and push information. The initiating user could go through a web page; click on the targeted user, Shibboleth would then gather attributes push it out. The user could be an individual, conference call etc. The difficulty is you may not want the conference call advertised. Authentication and the Shibboleth request for information would have to occur before offering access to the resources you’re authorized for.

One value of unified web based resource discovery approach is that it moves it from being embedded in the protocol to happening up front. In theory you are already authenticated and can just connect to the user. One issues is: at what point does the declaration of what protocol is being used happen? There was discussion of how this could be handled. It was decided that the initial goal does not include native mode authentication or authorization in either SIP or H.323 but use the protocols, as they are operational today. Simple point-to-point connections to demonstrate how this could work are the initial goal. Another concern is that there is no object schema for a multipoint conference. Under Shibboleth, if a multipoint conference is represented as a web resource, then the login names of those that can join are part of the resource management. Concern was expressed that providing access control on information about a conference is not the same as providing access control on the conference itself.

The conversation regarding refining the model will be ongoing. All input is welcome.