On Monday August 19, the following were present at the meeting:
Jill, John-Paul, Tyler, Nadim, Samir

(1) Face-to-face coordinating meeting in October is confirmed. Please plan
to arrive on Monday, October 7 in time for a 6:00 PM dinner (if possible)
and please plan your departure flight so that you can remain at our meeting
until at least 2:00 PM the afternoon of Wednesday October 9.

(2) We need to either make Groove work or give up on it and work with
something else.

(3) Next Meeting - Monday is Labor Day & many of us will not be at work. I
suggest we move that meeting to September 9 (for those who are available)
and then again, as scheduled, September 16.

(3) Most of the meeting was a conversation about possible approaches for
authentication and security. I think we now appreciate that this is not an
easy problem to solve given constraints. Below is a first attempt to
summarize the issues we need to address in our requirements document, and
some consideration of possible approaches.

First, let's review our deliverables:
* commObject classes for H323, sip and perhaps vrvs/accessgrid/mpeg
* standardization of commObject
* SIP-based application prototype
- working prototypes able to set up & transfer calls using a proxy
- use of "standard authentication tools" & implement inter-realm
authentication; interface w. campus directory service
* evaluation of Shibboleth as security architecture for Videoconferencing
* Testbed: implement commObject in LDAP infrastructures; include H323/SIP
gateways for all services
* Testbed: Directory entries for ViDeNet users and support for guest users
* Videoconferencing 'white pages'
* Reference H.323 and SIP endpoints
* TESTbed results summarized & documented in Cookbook

My understanding of Shibboleth pro's and con's are:
* It is really the only model fully based on federated, inter-realm
authentication where each realm can select its own method for authentication
(so, one realm can use username/password while another uses certificates)
* This flexibility arises from use of SAML; SAML assertions can range from
very simple "the user was authenticated" to very complex simply by addition
of attribute information rather than by adding complexity once the
architecture is in place
* there is no API, really; the architecture is web based and communication
is via HTTP.
* Shibboleth has the "added value" feature of user anonymity or user control
of the amount of information about the user that is to be presented; my
personal opinion is that the videoconferencing application is not the most
compelling illustration for when this is needed, but the point is this
feature comes as part of the Shibboleth package.
* Shibboleth is just now being put into pilot use as working code.

Shibboleth and SIP:
*After much discussion, the AuthN/AuthZ group seems to have settled on a way
to include SAML assertions in either the SIP invite (Header or MIME
portions) that could be used with the Shibboleth architecture. The
AuthN/AuthZ group will continue developing some flow models for SIP that we
hope will be useful for considering the H323 side of things.

H323 authentication standards:
*Annex D (username/password): For integration with with enterprise
directories, we'd like the gatekeeper to actually user the enterprise
directory for authentication when it's available rather than replicate
passwords inside the gatekeeper. The passing of passwords on a hop-to-hop
basis among gatekeepers is not scalable. So there may be a means to
authenticate users at their home gatekeeper, but how to convey that
authentication across gatekeepers using Annex D is not known.

* Annex E (certificates): This approach is very clean for end-to-end user
authentication and encryption. However, PKI is not well established for
client use and it is likely that this approach would be more for purposes of
demonstration than large-scale roll out. A nice inter-realm authtication
approach for PKI has been demonstrated by the Higher Education Bridge
Certificate Authority/Federal Bridge project; some of the needed components
are open source.

* Annex K (web ): This seems to be mostly applied to the web interface for
H.323 appliances or managing gatekeepers/gateways? Some hope was expressed
that Annex K could be used to access the Shibboleth infrastructure.

* "Interesting Element" - It was brought to my attention that the H323
standard includes an "IE" option that allows a developer to invent almost
anything and make it fit inside the standard. Not really sure we want to go
there, but thought it worth mentioning.

What other approaches might exist?
* We have heard about "Diameter", which is a Radius to Radius strategy (I
think). I've heard a SIP developer say the SIP folks couldn't figure out
how to make it work with SIP.
* Pubcookie+ ? Pubcookie is also based on web services, so communication is
via HTTP. Pubcookie is a means for single sign-on using LDAP directory
services for a single realm; we at UAB think this could be extended to
multiple directories by signing on as jill@uab.edu where the "uab.edu" is a
clue as to which directory to use for authentication.

Things to think about:
* Which parts of the problem need to be solved end-to-end versus the parts
of the problem that need to be solved hop-by-hop. Hop-to-hop authentication
could be done by using server certificates.

This is just a start - have I left out anything else that should be
considered?