*Attendees*
Nadim El-Khoury, U. North Carolina - Chapel Hill
Steve Olshansky -- Internet2
Tom Barton -- U. Memphis
Jill Gemmill – UAB
Ameet Kulkarni, Anand Chavali, Kim Norton, and Mudassir Fajandar, U.
Colorado – Boulder
Nate Klingenstein - Internet2
Art Vandenberg, Georgia State
Samir Chatterjee -- CGU
Jeanette Fielden - Internet2

*Discussion*

The call flow diagram authNZ framework tjb v0.1 sent to the list by Tom has three sections – registration, lookup, and connection. This is a high level view of the call flow. All Shibboleth elements in the diagram are based on current capabilities. All Shibboleth/SHAR objects utilized are not included in the diagram for the sake of simplicity.

Steps 1 – 4 are the registration process. There is an initial web services registration followed by a video registration. The interaction between web and video layers is intermediated by a shared database, such as an LDAP directory. This interaction relies on SIP Proxy + Registrar and H.323 gatekeeper implementations that are constructed to reference an LDAP directory. Steps 1 and 2 are optional initially, while 3 and 4 are critical. The registration process could be focused mostly on gatekeepers with minimal requirements of clients. Steps 5 – 9 are the lookup phase. If the user requesting access is authorized, the lookup retrieves information from a database. Steps 10 – 16 are the connection phase. The attributes needed for the authorization decision are obtained in step 11 using existing Shibboleth functionality.

Differences from the previous call flow diagrams occur in the call setup. There are the two points of interaction that occur between the web services layer and the video layer. The video web service point "signals" the proxy or gatekeeper to allow an authorized call to proceed. Data is placed in the shared database in step 12 that proxy/gatekeeper looks at for authorization information. This functionality would need to be developed. The actual initiation of the video portion of the call happens in step 14. This uses an URN style element of html returned by the target video web service point to the initiating user's browser. When the user clicks on it the video client is then launched. Steps 15 and 16 perform a caller id function and allow the target user to deny the invitation based on the caller id.
After discussing how the call flows work, it was agreed to focus on key server elements, such as gatekeepers and proxies, going forward. Consensus was also reached that integrating the gatekeeper with a video LDAP directory should be a component of the flows. Integration with LDAP will require a lot of new development though some elements may already be in place. A key consideration is: How easy will it be to modify the proxy server to add things such as authentication between proxies? Single sign on will be left out for moment because of complexity and security issues. Additionally, the group also decided that authentication would happen within the local domain. The initial position is that if you have authenticated with a trusted domain everyone from that domain is acceptable.

A scenario-based bake-off was proposed. It was established that the next step for the group is to define what exactly they want to the final end product to be able to do. Then scenarios/proposals can be evaluated and independently assessed for functionality and feasibility with the best aspects of the each being incorporated.

It was decided to start with the four Prioritized Work plan Scenarios published last January, for evaluation as potential starting points for further development.http://middleware.internet2.edu/video/draft-internet2-vidmid-vc-prioritized-workplan-scenarios-00.html.
Discussion of scenarios will continue on the next call.