Presence and IntComm WG

[Shumon Huque <>]

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?

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?

> >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 ..

--Shumon.