*Attendees*
Ken Klingenstein, Internet2 (Chair)
Jon Peterson, NeuStar
Renee Frost, Internet2
Samir Chatterjee, CGU
Tarun Abhichandani, CGU
Jonathan Tyman, Internet2
Steve Olshansky, Internet2
Jill Gemmill, UAB
Bob Morgan, U.Washington
Art Vandenberg, Georgia State
Nadim El-Khoury, U. North Carolina - Chapel Hill
Ameet Kulkarni, Mudassir Fajandar, U. Colorado - Boulder
Jeanette Fielden - Internet2

*Discussion*
The focus of the call was how SIP could be utilized to best advantage. Key issue: How much Authn/z information can be carried as native payloads within the SIP protocol vs. doing something out of band to convey that information?

The environment that seems to be originating on campus is: web-based authentication against legacy schemes where you do a web based authentication initially and leave a cookie behind so you don't have to keep re-authenticating. How can you capture a persistent session over time? Is there anything today in the SIP space that will allow us to use an existing authentication to convey information into the registry?

SIP is a protocol that allows endpoints to discover one another and to exchange information to characterize the session they want to share. In the SIP protocol there are three security mechanisms, Digest, TLS and S/MIME. Digest and S/MIME are the ones actually used and S/MIME seems most sophisticated for end-to-end Authn/z. It is likely that how authentication and authorization will work in the long-term will depend on some combination of S/MIME and OpenSAML artifacts. That exact combination has not yet been determined.

SAML instantiates an artifact binding and a POST binding that can be moved around in HTTP. Most work in Shibboleth has been around the POST binding for that reason. The artifact is essentially a pointer, a unique identifier for an assertion, and can also be regarded as a pseudonym for the user. It can be used in URL's to redirect between protocols such as HTTP and SIP and maintain consistency across them for a single sign-on environment.

Is it reasonable to assume that we can use a web-based application to load the relevant registry information? This is more an application issue than a protocol issue. The first step is having a previously authenticated user supply valid information into a SIP call. There are two options to get the information, intercept the invite message at the proxy and retrieve the information from the registry or as a part of the registration process activate the SIP client and place artifacts that are available to the client.

Functions like privacy can be provided generically within the application that you want to set up with SIP. The reliance is on the application to provide the function, not the protocol. In SIP privacy involves the headers and fields in SIP that divulge information about identity when used in a standard way. Other information can be populated in these fields to give a degree of pseudo-anonymity. However, if the contact URI in the header is altered it could impact the ability to set up a useful session. The security domain can provide privacy, such an opaque handle, to the outside world but ultimately knows who you are.

One area of concern is that focus needs to be on implementation and keeping the scope of the work from expanding too much.

An additional question is the availability of open source proxy and clients. There is a complete suite of SIP stack (linux and unix) available from http://www.vovida.org . It is not clear what is available open source for Windows. The group agreed that open clients for Windows are needed.

There is a recent article of interest in Digital ID World "Shibboleth: Identity the Internet Way" by Phil Becker that includes an interview with Stephen Carmody. The article can be found at: http://www.digitalidworld.com/modules.php?op=modload&name=News&file=article&sid=90&mode=chrono&order=0

The next Authn/z call is August 20, 2002.