*Attendees*
Klaas Wierenga, SURFnet
Seth Vidal, Duke
Chris Williams, U. Buffalo
Steve Carmody, Brown
Derrick Brashear, CMU
John Paul Robinson, UAB
Brendan Bellina, Notre Dame
Peter St. Andre, Jabber
Ann West, Educause/Internet2
Neal McBurnett, Internet2
Jeanette Fielden, Internet2
Steve Olshansky, Internet2

*Discussion*
Internet2 IP reminder.

Peter provided a brief IETF update on XMPP. He has received some feedback from the IESG (Internet Engineering Standards Group) that is being incorporated. Changes are mostly clarifications.

Use Cases:
Steve Carmody and Peter are working on a use case for Shib enabled XMPP. Once it is well defined it may be abstracted to the more general case. It’s complicated since there is overlap between XMPP and other areas. Once the case has been through a couple of iterations it will be sent to the I2IM list. Follow-up discussion will happen on the Shib dev list because of the overlapping areas.

Klaas provided an overview of the authenticated user case. The starting analogy is e-mail. A user logs into a server and sends a message that has a valid from address. The same thing is wanted for authenticated IM, which might be characterized as connection oriented e-mail. Log into a server run by your company, that has policies in force, and then send messages with a validated identity. Options might include establishing only where you’re from, not who you are, for a group where individual identity doesn’t matter, such as within the same university community.

How does connection oriented relate to the pseudonymous case? How is information about the endpoints in that session restricted? There will be issues with statefullness, time-outs and needing to expire the identifier at some point to prevent tracing. What is the balance between resource use to track/maintain identifiers and maintaining the integrity of the identifier for future use? Situations where you might want to maintain the identifier is, the originator wants to reuse it with the same receiver; a user is disconnected and wants to reconnect with the same identifier; a user has multiple unique sessions and wants to track them individually. There could also be a concept of session that is associated with a specific topic. An identify might be used for a topic, and then for a new topic a new identity is generated.

Steve Carmody pointed out that there is a persistent opaque identifier in Shib that the site origin software can map back to a specific user. Since the identifier is opaque it can’t be deconstructed by the end user and traced back to the source. A different identifier is generated for each target. This would not solve all the mentioned issues.

The key question is are these cases compelling enough to undertake the scope of work needed to implement them?

John Paul pointed out that the tricky part about IM is that the session is almost implicit. The connection is the session in most ways, which makes hiding information from the endpoint difficult. Identifier management responsibility would be on the originator. Peter shared that there is something of a concept of session as different from connection though it is not yet well defined. They have developed some protocols for encrypting connections though they don’t have the concept of negotiating the session outside of the encryption. One parameter could be an alias for the originator.

Most of this focuses on the one-to-one case. For one to many there is a notion of having an alias, a room NIC, which is different from regular address. This is a different context that might be of use to the one-to-one context.
[AI] (All) Send comments on authenticated use case to the list.

Pseudonymous Case
Brendan expanded case two with sub cases to make clear no information is returned in the event that someone has refused to allow pseudonymous communication. The error message does not indicate that the address tried is valid. The intent is to prevent situations such as a spammer fishing for valid addresses by trying random ones. Additionally, the intent is to prevent using the IM address to track down the physical location of a user. An example might be a stalker trying to locate someone through his or her IM address.

In case three the hotline operator will need to use interview skills to get location information since it will not be otherwise accessible.

Case seven where there is only one student in a class from an institution was added. The entire handle will need to be obfuscated since revealing where the IM is from would revel whom the originator is. The target system may need to know that they are a participant in the class, but hide all other information.

Another consideration is how to enable follow-up by the professor to the student. So a mechanism to restart the session from the receiving end might be needed if it’s feasible.
[AI] (Brendan) add definitions for pseudonymous use cases.
[AI] (All) Review use cases and e-mail comments to list.