Presence and IntComm WG

[Peter Saint-Andre <>]

Shumon Huque wrote:
> 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.

Correct. So one question is: can the user discover that the remote 
domain is PIC-assured?

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

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.

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

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

Peter

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