*Attendees* Jonathan Siegle, Penn State
Michael Gettes, Duke
Klaas Wierenga, SURFnet
Chris Williams, U. Buffalo
Brendan Bellina, Notre Dame
Bob Morgan, U. Washington
Peter St. Andre, Jabber SF
Diego R. Lopez, RedIRIS
Seth Vidal, Duke
Steve Carmody, Brown
Mark Poepping, CMU
Jeanette Fielden, Internet2
Neal McBurnett, Internet2
Steve Olshansky, Internet2

*Discussion*

The charter will be updated to emphasize that the I2IM work is technology agnostic but will focus initially on open source efforts.

Peter St Andre gave a quick IETF update. Last call on the XMPP specs is finished and they will be considered for RFC in December. There are preliminary discussions about how to improve inter-operability between SIP/SIMPLE and XMPP.

Peter has been reworking the overview documents on Jabber.org and will send links to the list when they're ready.

There was discussion about the utility of being able to connect with Jabber to other IM providers. Some universities have individually approached IM providers about inter-connection with no success. It was agreed that if a large group of institutions interconnected their environments and then approached IM vendors the likelihood of success is much greater.

At the federal level there is the Interoperability and Standards Working Group (ISWG). They're interested in moving away proprietary vendor solutions to standards based solutions in the areas of IM, voice integration, voice chat, white boarding, doc mgmt, collaboration tools, updates when docs change etc.

[AI] Peter will send the I2IM information about joining the ISWG mailing list.

There was discussion of the anonymous/pseudo-anonymous use case Brendan wrote up. There are three scenarios: 1. A student wants to correspond anonymously with a professor, and is a member of the professor's class. 2. A student reports an incident to a campus hotline. 3. A true anonymous contact with a suicide hotline. The first two cases are pseudo-anonymous since the users have authenticated to the system in some manner.

The first case does invoke a group of criteria, so the case needs to be clarified to acknowledge the relationship to the "member of" group issues. For instance privacy may not be maintainable if there is only one person in a group. The first two cases depend on being able to pass enough information to the target so the target can decide whether or not they want to chat. Is the third case of an anonymous chat truly possible or are they all pseudo-anonymous?

Is there a requirement to preserve the confidentiality of someone outside the institution? InCommon would likely require agreement to terms that would require confidentiality. The intent of the case is not to set policy but to ensure that the technology enables institutions to implement the policies they want to support.

With the persistent handle the intent is to create a unique identifier that would be specific to communication between two users, consistent over time and could be generated based on a combination of information about the two parties. A person would not be assigned a permanent random anonymous handle that might be compromised through comparison. The receiver would not know who the sender was just that it’s the same sender. A different handle would be generated each time a pseudo-anonymous conversation is initiated with a new receiver. Bob mentioned that Liberty Alliance has a design for doing this that should be investigated. They generate an identifier that is bound to the triple of the identity supplying organization, the service providing entity, and the actual user.

Peter indicated that Jabber uses from addresses like use e-mail addresses. The server has the right to rewrite those addresses on the fly so the authenticated address can be masked. The user can be obscured but the domain cannot be obscured or spoofed.

The masking would be addressed at the origin server. It would then communicate with the receiving server and expose the attributes that would allow the receiving user to decide if he wants to receive a pseudo-anonymous IM. For example, the receiver would know the message originated from an authenticated user at Duke.edu, but not that the user is gettes@duke.edu. Duke.edu would be vouching that the user is a legitimate authenticated user at Duke. This information would go to the receiving server, which could append information that Duke has validated this, and then hand it to Brendan@nd.edu. Brendan would know that the sender is from Duke but not that it is gettes@duke.edu. The only entity that needs to do address cloaking is the one at Duke. That does not exist today, so there would need to be development work. The mechanism for doing that negotiation between the client and server also does not exist.

Klaas felt that something as simple as distinguishing between authenticated and un-authenticated users, as opposed to a role based approach, could be the place to start.

Mark believes there simply needs to be an argument and test case for why there should be a truly anonymous case. Why should anonymity be precluded if the receiver had the ability to refuse an anonymous connection? There could be a policy switch that could be set to allow/disallow anonymous communications. Is there a case for the individual receiver to reject anonymous stuff and/or a policy decision for an entire system to reject anonymous communication?

A client will also need to understand how credentials are forwarded and the interaction between attributes and policies. If Duke and Notre Dame are in the same club there has to be a way to propagate policies as well.

[AI] Mark will write up his questions about anonymity and mail to the list.

[AI] Brendan will revise the anonymous/pseudo-anonymous use case and mail to the list.