*Attendees*
Steve Olshansky -- Internet2
Tom Barton -- U. Memphis
Samir Chatterjee -- CGU
Tarun Abhichandani -- CGU
Jill Gemmill -- UAB
Doug Sicker -- U. Colorado - Boulder
Ameet Kulkarni, Mudassir Fajandar, Kim Norton -- U. Colorado - Boulder
Nadim El-Khoury, U. North Carolina -- Chapel Hill
Art Vandenberg -- Georgia State
Jeanette Fielden -- Internet2

*Discussion*
The consensus was that one converged set of call flows should be used going forward. An issue is the use of Shibboleth, when and how it's invoked. The group decided that there should be both a Shibboleth and a non-Shibboleth version of the flows for comparison and evaluation purposes.

Two scenarios were agreed upon that the call flows should be able to handle. Both scenarios incorporate sign-on, registration, and invoking of a process to pass information. Questions that will need to be considered center around how much information is passed and how is it passed? In the first scenario the request will be passed to the target without further checking once the validity of the request and source is verified. The second scenario will take the additional step to verify the attributes of the caller against policy before passing the request on.
[AI] 24-July-02 (Mudassir) Write up a description of the two proposed scenarios.

There was extensive discussion around the issue of authentication and whether it should be initial vs. single sign on, where it happens and how. The group agreed that there is an initial sign-on that consists of some sort of authentication with a credential issued that gets passed through to the following flow steps, enabling end points to decide whether to trust/accept calls. It is also assumed that the registration is web-enabled and not done through the video client directly. The need is to put in place some mechanism where the target proxy receives some sense of the attributes describing the caller so they can make a decision locally before passing it to the callee and asking if they want to accept the call.

In Shibboleth, the architecture passes the handle through the user's browser on the way back to SHIRE. The browser waits while SHAR and the attribute authority exchange information. The point of passing information through the browser is to provide session information so that SHIRE knows where to connect to when approval comes back through. The key is getting the attributes across to determine if the handle is a member of the community and what level of privileges are associated with the member. It is not clear that attribute information can be passed with the handle in Shibboleth. There is also a need to address how Shibboleth is invoked by SIP. Additionally, the browser may the only way to invoke the SHAR component.

Based on the questions raised, the call flows will be modified before the next call.
[AI] 24-July-02 (CU-Boulder and CGU) Students working with Doug Sicker and Samir Chatterjee will talk this week to refine call flows in advance of the next call.

The next call is Tuesday July 30 2002.

*Action Items*

1. [AI] 24-July-02 (CU-Boulder and CGU) Students working with Doug Sicker and Samir Chatterjee will talk this week to refine call flows in advance of the next call.
2. [AI] 24-July-02 (Mudassir) Write up a description of the two proposed scenarios.