Presence and IntComm WG

[Peter Saint-Andre <>]

Neal McBurnett wrote:
> On Tue, Jul 08, 2008 at 02:19:45PM -0600, Peter Saint-Andre wrote:
> > Correct. So one question is: can the user discover that the remote 
> > domain is PIC-assured?
>
> I think supporting access to this info is an important element of
> taking advantage of better identity assurance.  Are there good ways to
> do that now in XMPP?

Not yet.

First we need to figure out what it means to be PIC-assured. Does that 
mean a domain has a special kind of cert, which I can retrieve directly 
from the remote domain if I care about identity assurance? Or does it 
mean that my local domain has a special kind of relationship with the 
remote domain, which I can ask my local domain about?

> Also, I assume your model #2 - that every id is assured at a given
> domain.  The bigger question is whether any sort of attributes can can
> be made part of that (e.g. "faculty" vs "student").
>
> > > But the client interface needs to indicate it to the user
> > > in some fashion.
> > And we have to wonder if the user cares. :)
>
> This is related in some ways to cloaks on irc at
> e.g. irc.freenode.net.  People covet cloaks that identify the user as
> an "Ubuntu Member" or identify a bot as approved in some way:
>
>  https://wiki.ubuntu.com/IrcTeam/Cloaks
>
> and others see a user's cloak when they join a room.  Without any sort
> of cloak you have less privacy since your IP address is shown.

Sure. But we don't reveeal IP addresses in XMPP.

> And as others have said, it is perhaps more likely that the
> infrastructure or the user's client would make identity assurances
> useful - e.g. blanket access to chat room roles, etc.  Again, e.g. in
> IRC many chat rooms are configured so that folks with certain sorts of
> cloaks can take on special roles (changing topics etc).

Sure, we do that in different ways in XMPP, all described in XEP-0045.

> > > 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.
>
> A more general mechanism would seem useful, so that user agents could
> also use this sort of info.

But a user agent could also retrieve that general role information via 
SAML if it care, no?

/psa

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