*Attendees*
Ann West - Internet2/EDUCAUSE
Bengisu Tulu - CGU
Jill Gemmill - UAB
Bob Morgan - Washington
Tom Barton - Memphis
Samir Chatterjee - CGU
Tarun Abhichandani - CGU
Doug Sicker - U. Colorado - Boulder
Nadim El-Khoury, U. North Carolina - Chapel Hill
Ameet Kulkarni, Anand Chavali - U. Colorado - Boulder
Jonathan Tyman - Internet2
Steve Olshansky - Internet2
Nate Klingenstein - Internet2
Jeanette Fielden - Internet2

*Discussion*
It was reaffirmed that the group would focus on SIP not H.323 for the moment. There are SIP developers currently available to work on this and we don't have the same access to H.323 developers at this time. As work progresses there will also be efforts to ensure that the results are applicable in the H.323 world as well.

During the last meeting there was agreement that there are 3 policy decision points where authorization can happen 1) origin proxy, 2) target proxy and 3) target user. Example: Bob is faculty - he connects at the source proxy where he is authenticated, and as a result of local authorization policy Bob allowed to go anywhere. If Bob was a student where he can go might be restricted on a number of criteria. The authorization decision at the target proxy could be either based on caller list lookup or on attributes.

There was general agreement that it would be desirable to support more detailed decision making to authorize the user. There was concern over how to achieve this without creating additional complexity in the architecture. One option discussed includes a lookup by the origin proxy, which would require LDAP functionality in the SIP proxy. This creates the issue that if the directory enterprise is at the end of what's being interfaced with, a user id/password would have to passed through to the LDAP server to be able to get any attributes, particularly privileged ones.

A second option discussed was the exchange of attributes between proxies. There are two major concerns with attribute exchange -1) how does the origin know what proxies to push and 2) scalability for a multi-point scenario.

What is the best method to exchange attributes? One possibility is to use OpenSAML but it needs to be verified if it can do attribute exchange. SAML builds the information into a SAML attribute assertion that will have to be disassembled by the target into its component attributes. Another concern was that it may be very difficult to have a pull architecture in place and pull doesn't seem to fit well with SIP.

There was agreement that the Shibboleth resource manager needs to be handed a believable token, defined as something indicating that the origin user has been authenticated to the origin proxy's satisfaction, by some currently undefined mechanism. It is not unreasonable to assume that the set of attributes carried for a videoconference in a certain club could be defined. One option has an out of band agreement over which attributes will be passed.

Preliminary agreement was reached look at creating a small core set of generic attributes that could be included in a SIP invite. The focus is a few key attributes that are the most practical and that each site would be comfortable releasing. There should be general agreement between domains over the type of attributes would be required and that it is the responsibility of the origin proxy to ensure that those attributes are passed along.

The next call is scheduled for August 13, 2002.