Presence and IntComm WG

[Shumon Huque <>]

On Mon, Jul 07, 2008 at 08:02:16PM -0600, Peter Saint-Andre wrote:
> Steven C. Blair wrote:
> >[[scb]] In my opinion they mean that the authentication system used
> >in domain someschool.edu confirms that user newstudent was able to
> >provide verifiable credentials to join the domain. The presumption is
> >that domains which receive traffic from 
> >
> > can
> >assume newstudent's identity has been validated.
> 
> It's still not clear to me exactly what that means in practice.
> 
> Does that mean myschool.edu won't accept connections from yourschool.edu 
> if your school doesn't adhere to the best practices defined by PIC.edu?
> 
> Does that mean myschool.edu won't accept connections from any other .edu 
> domain if the domain doesn't adhere to the best practices defined by 
> PIC.edu?
> 
> Does that mean myschool.edu won't accept connections from any other 
> domain (say, gmail.com) if the domain doesn't adhere to the best 
> practices defined by PIC.edu?

Hopefully none of those things :-)

Identity assurance is easy for your local jabber service. For
inter-domain, I think the identity assurance thing only works
if you have a closed federation and trust the authentication
systems and other identity vetting procedures of all the other
federation members. In that environment, server-to-server
connections could also be authenticated by TLS certificates
issued by a federation operated CA.

The upenn.edu jabber service isn't currently part of closed 
federation. It can interoperate with any XMPP service on the
Internet. Moving away from that model would be a huge loss in
functionality in my opinion.

If we become a part of a PIC federation and want the identity
assurance property to hold for the limited set of federation
participants (but still allow communication with arbitrary
XMPP services), then the jabber service needs to have some
mechanism to communicate that assurance to it's participants, 
eg. that 

 is a PIC federation vetted JabberID, 
but 

 is not. Otherwise I wouldn't find it that
useful. How would this be accomplished? I can imagine a few
ways. But the client interface needs to indicate it to the user
in some fashion.

One somewhat compelling use case that was discussed recently is
the use of a federated authorization system to construct members-
only (eg. PIC/Internet2 members-only) chat rooms.

--Shumon.