Presence and IntComm WG

[Peter Saint-Andre <>]

Shumon Huque wrote:
> On Tue, Jul 08, 2008 at 02:19:45PM -0600, Peter Saint-Andre wrote:
> > Shumon Huque wrote:
> > > 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.
> > Correct. So one question is: can the user discover that the remote 
> > domain is PIC-assured?
>
> Well, in the closed federation model, the user could discover this
> simply by the act of whether or not he is able to communicate with 
> the remote domain :-)
>
> > Is identity assurance a property that attaches to individuals or to 
> > services? That is, could (1)  be assured but 
> >  not be assured, or (2) are all users from a given domain 
> > assured if that domain is part of the PIC federation?
> >
> > If (1) then how is assurance created? Does that happen via client-side 
> > certificates (resulting in mutual authentication between Deke and the 
> > upenn.edu service), via Kerberos, or in some other way?
> >
> > If (2) then our lives are a lot simpler.
>
> I hope it's (2). It's certainly simpler. Also if I trust some remote
> authentication system to vouch for the identity of one it's users,
> why wouldn't I trust it to do the same for all of it's users?

Well, there is always SASL ANONYMOUS for instance. I can definitely 
envision some organizations deploying that -- think of things like 
suicide help lines, whistleblowers, even virtual classrooms or TAs.

> If I really want assurance of the identity of individual remote
> correspondents, perhaps the real answer is to use digitally signed
> messages, eg. PGP or S/MIME (RFC3923) .. I'm not sure how widespread
> the usage of signed messages is yet .. do you have any sense of this?

It's not implemented or deployed anywhere AFAIK (in part because it 
really sucks -- I can say that because I wrote the spec). But the XMPP 
developer community has started looking into client certificates for 
end-to-end encryption, and those could be used for strong identity as 
well. See for instance:

http://www.xmpp.org/extensions/xep-0246.html

http://www.xmpp.org/extensions/xep-0247.html

> > > 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.
> > And we have to wonder if the user cares. :)
>
> Yes, I was actually wondering the same thing myself :-)
>
> > > 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.
> > Sure. But that could be done in a different way, via SAML-aware 
> > groupchat services for example.
>
> Right, of course the SAML aware service could certainly use a
> federated authN/Z system. But you don't even need SAML really.
> The pic.internet2.edu groupchat service could just maintain
> a list of domains associated with the federation members (or look
> it up in a directory), and disallow access to any jabber-id whose 
> domain identifier didn't match that list ..

Correct.

Peter

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature