The initial problem space for the I2IM group is a fairly narrow band of messaging and middleware interoperating with applications on both an inter-domain and intra-domain basis over a collaborative infrastructure. While Jabber and XMPP are a starting point, the focus is not specific to any one protocol.

The intent is to start with simple scenarios and get the infrastructure to work and then understand the constraints and resulting requirements. There is a desire to avoid third party mappings to do business related interactions.

There was general agreement that there should be information sharing between I2IM and the Internet2 presence working group. Egon Verharen of SURFNet is a member of the presence group and will act as an interface between the two groups.

The difficulty with independent IM vendors is how do you trust traffic from them since they don’t do authenticated identity? E-mail addresses are a form of identifier but are not necessarily trustworthy. Shibboleth could provide the trust fabric between institutions. Applications layered with Shibboleth could also transfer user profiles.

If we use IM to do things we could do via e-mail, and we don’t authenticate e-mail why put the authentication emphasis on IM? There are instances of forging e-mail to fire people, close campus etc. A similar thing could be done with current IM applications. With authenticated IM parameters can be set that say: don’t ever accept anything from me that is unauthenticated.

Possible Cases
1. IM between two authenticated people at different institutions. Michael Gettes as gettes@duke.edu wants Bob at U. Washington to be presented with his authenticated information. Access controlled chat rooms. Any IM client can be used but you have to be able to present an identity to the chat room and your organization has to vouch for that identity.
2. Anonymous and pseudo-anonymous messaging. Could be used by teachers who want to be able to run online office hours that are anonymous, to allow students to ask questions without fear. Business cases exist for medical environments as well: clinical trial reporting, privacy, someone can expose information about what they’re experiencing without giving up their identity. Internet2 medical working groups could be solicited for scenarios. Even in the case of an anonymous conversation there may still be a need for a persistent identifier even if it’s anonymous, so you know it’s still person1 and not a new person.
3. Application to application messaging. This could include things like middleware diagnostics. Message enabled middleware could pass information. The middleware diagnostics could use IM to pass information to help troubleshoot access for case 1. That would go beyond text IM to message passing that could be tagged with authentication, between machines etc. There is work on this in the Jabber space.
4. Research space applications through an API. For example, supercomputer to supercomputer or sensor/instrument to computer.
5. Authorization exposures/issues as they relate to the cases overall. Chat groups – how gain access to that. Member of duke.edu means authorized. How to bring in unauthenticated messages as well.
6. Directory enabled infrastructure like address books.

The cases will start with short write-ups to investigate the idea and then develop into scenarios if appropriate.

Assigned Cases:
1. Authenticated - Egon Verharen and Klaas Wierenga SURFnet
How to bring in unauthenticated messages
2. Anonymous/Pseudo-anonymous (authN vs. non authN) – Brendan Bellina Notre Dame
3. (App-to-app) - Chas DiFatta CMU
Middleware diagnostics
Network statistics (flows, subflows, end-to-end performance)
Any statistics or diagnostics (network, system, application)
Peer-to-peer (Lionshare, Chandler)
4. Research
API for exposing data (instruments to/from)
5. Authorization exposures - Steven Carmody - Brown
Chat groups (members of)
6. Directory enabled infrastructure? Address books
Things like attribute authorities??
IM enabled course - Bob Morgan will look for someone at U. Washington to write up.