Presence and IntComm WG

["Steven C. Blair" <>]

> -----Original Message-----
> From: Peter Saint-Andre 
> [mailto:]
> Sent: Monday, July 07, 2008 10:02 PM
> To: 
> 
> Subject: Re: [wg-pic] ongoing PIC.edu federation discussion
>
> 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.
>

 [[scb]] Me either.

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

[[scb]] I would think accepting or rejecting "connections" would be a local 
policy decision an myschool.edu. The policy might require "identity 
assurance" to be enabled. In our SIP world we loosely use the Remote-Party-ID 
at the boundary of our network. Passing this to a remote site by no means 
guarantees the identity of the sender but it is a first step.

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

 [[scb]] I tend to be a little funny about saying what one site may or may 
not do. I think that question will be addressed by policy at the local sites. 
To me the issue is whether or not the systems can provide some identifying 
information to each other which can then be checked against local access 
policy.

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

 [[scb]] Oh gmail, absolutely. :-) Just kidding.

 [[scb]] In a past life my employer would establish connections to other 
parties for the duration of a contract then disassemble the connection. When 
the Internet came along they stopped building dedicated circuits and instead 
built a system of access controls which were backed by policies within the 
local IT security department. If the policy allowed access it was granted for 
certain applications with sufficient logging to perform audit and compliance 
checks. I think we are talking about a similar approach.

[[scb]] As an example suppose Penn as an institution has a local policy 
regarding host access. The policy may indeed block access from gmail but 
offer "complete"  PIC.edu functionality to other sites.

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