Presence and IntComm WG

[Peter Saint-Andre <>]

Steven C. Blair wrote:
> ________________________________________ From: Peter Saint-Andre
> []
>  Sent: Monday, July 07, 2008 5:21 PM To:
>
>  Subject: Re: [wg-pic] ongoing PIC.edu federation
> discussion
>
> Deke Kassabian wrote:
>
> > The major goals when considering federations was, I think, identity
> >  assurance in an inter-institutional way, and IM spam (spim)
> > avoidance.
>
> As mentioned, we really don't have spam yet on the network. We have
> some small amounts of abuse in chatrooms, but those problems are
> fairly easily solved through active room administration. It's still
> not 100% clear to me what folks mean by or expect of "identity
> assurance".
>
> [[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?

> > The majority of those expressing an opinion, notably including
> > Rodney McDuff (before the call), Peter Saint-Andre and Michael
> > Gettes all appear to be recommending a very "low hurdle" for a
> > variety of good reasons.  I think I'm coming around to this notion.
> > If PIC.edu had guidelines to those deploying, advice and best
> > practices, perhaps we could avoid technical barriers to entry that
> > will only tend to frustrate users and organizations and accomplish
> > little.
> >
> > I think the goals are good goals.  I guess I'm concerned that if
> > there's no hurdle at all and we want to create one or raise the bar
> > a bit later we'll have trouble doing so.  That is, those who
> > deployed PIC.edu with us in the early days but are unable or
> > unwilling to get slightly more strict in terms of user
> > authentication, chasing misbehaving users, or (much later)
> > inter-institutional server-to-server authentication will make it
> > harder for us to achieve this higher level without considering 
> > "kicking folks out" of PIC.edu.
>
> IMHO, if you choose the same bar as is used on the open XMPP network,
>  then there really is no such thing as PIC.edu as an island in the 
> broader net. Whether you find that valuable or not is another
> question. But it opens up possibilities to connect to the growing
> variety of XMPP services out there.
>
> [[scb]] While I don't necessarily know what this bar is all about I'd
> say set it at least as high as the bar used in the open XMPP network.
> PIC.edu as a project may want to demonstrate enhanced services with
> interconnections to the open XMPP network.

The bar on the open network is that you provide proper DNS settings so 
that other servers can verify the identity of your server using the XMPP 
server dialback protocol:

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

It's the only bar necessary to enable inter-domain communication with 
popular services like Google Talk, Live Journal Talk, Twitter, and the like.

But if you folks want to build something a bit more exclusive, that's 
quite reasonable too, and we have the technology to do that.

/psa

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