Presence and IntComm WG

[Jorj Bauer <>]

Mark, Jorj, Peter, Michael, Neal, Tim, Deke on the call.

Deke tried to describe the point left off two weeks ago and email
discussion.  Momentum behind a "low bar" to participation.

Deke asked, are we talking about a jabber server package, cookbook,
client recommendations.  Or are we additionally talking about all that
plus some "Rules of engagement" like "server operators will
authenticate users to allow audit, and will chase miscreants who
harass others in chat" ?

Peter thinks the package will at very least help jumpstart
organizations which is a good thing.

Michael - identity assurance in presence.  Maybe a SAML assertion from
the authenticating server.

Peter - there's an existing PGP mechanism, mostly to inform users
about PGP capabilities.

Discussed the use of PGP public key sever infrastructure for
lightweight validation.

Discussed what among this requires hacking on servers, what requires
client modifications.

Michael suggests that having such capabilities in servers can be a
reasonable start, to promote new capabilities in some clients later.

Discussion starts about what should be done for the next step of
pic.edu. Assertions should be signed by their servers, and the
server-to-server trust mechanism leveraged here.

  MG: For "phase 1" of pic.edu, Penn should modify OpenFire to provide
  saml-esque assertions, along with PSA and others.

  DK: asks what prevents others from promoting their own (invalid?)  
SAML
  assertions

  PSA: cross-server certificate validation

Discussion turns to how the information is transported (in what part
of the protocol). Initial suggestions involve presence, as everyone
learns what "Presence" means to Jabber.

  MG suggests this information be buried in presence, signed by the  
server.

  PSA counters that presence isn't the best location; it should be some
  other protocol, as is the tunes protocol.

  All agreed that the transport is the item to develop, rather than the
  content, which can be fleshed out later.

  MG suggests the content could be a signed URL about getting more  
AuthN
  information for the session.

  PSA suggests perhaps some small bit in presence, indicating that
  another AuthN-information protocol is available for clients that are
  interested. "Presence", from the Jabber standpoint, is network
  availability information (online, busy, offline). Location  
information
  is not presence in this sense, and AuthN shouldn't be in the core
  presence transport just as location shouldn't be.

  DK is concerned about the availability, from an application
  perspective, about location information. Clients don't make an  
obvious
  distinction the way that PSA does; it all looks like one unified
  presence.

Consensus seems to be to make a new carrier for this data, rather than
piggybacking on something that exists.

  PSA says this "rich presence information" is available (personal
  eventing protocol [Ed: XEP-0163]) on demand by the application.

  MG thinks that this AuthN data should be part of "normal" presence
  because it's identity information.

  MS points out the differention between (1) xmpp traditional presence;
  (2) the pic group's presence, which includes personal eventing; and
  (3) non-changing identification information about the
  individual. Thinks it needs a new carrier.

  MG: You've already got a little pregnant, since you're sending the  
userid.

  MS: if we did it wrong before, we don't have to keep doing it wrong.

  PSA: it's just a username, as addressing information, and isn't  
bloated.

  MG: not wed to the device, but want to see the capability. There
  should be a visual component.

The discussion turns to the direction of the pic.edu project; this
seems to line up with pic.edu's goals. OpenFire should be our
standard, with tiered service; Penn might provide resources to the
development effort.

  DK: does this seem like the best way to accomplish this? It doesn't
  seem bad, and thinks it's in line with the pic.edu project: work on
  new capabilities, either presence or integration of
  communication. We could be doing this.

  PSA: we've [Jabber] talkes about this for a while, but haven't
  gotten underway; struggled with rich profile information, used
  vcard, hoped someone would define better ways to do that so we
  haven't gone down the road of defining it outselves. May have to do
  that if nobody else does.

  DK thinks this is something pic can think about, and if it came
  down to a reasonably-sized project, then some penn resources could
  work on it at some point.

  DK: persuaded for the initial stages, if we're going to get U's
  participating in pic.edu, we don't want to ask much of them. Talking
  about downloading a version of openfire and a cookbook, reading
  recommendations for clients and -- adds -- the bit about our
  expectation that you'll AuthN users and auditing as req'd. Is that
  reasonable?

  MG: does it have to be OpenFire? What does it mean to pic.edu if
  we're cobbling together a proof of concept? The choice of OpenFire
  should be the supported recommendation for pic; tiered service. If
  you want to just communicate, you use whatever version you like; for
  level 2, you need to use version X of our server.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Attachment: PGP.sig
Description: This is a digitally signed message part