Shibboleth Developers

[Scott Cantor <>]

> XMPP provides two things: a transport protocol and extensible 
> mechanisms for sending any XML data over the transport. As 
> far as I can see, it makes the most sense to send SAML data 
> over the XMPP transport rather than using HTTP, since 
> entities on a Jabber/XMPP network don't know HTTP (not 
> necessarily, anyway).

Well, except that we *do* have code (in Java and C++) for sending and
parsing SAML messages over HTTP with SSL, and we don't have a SAML authority
anywhere capable of responding with XMPP. So the question is, do you define
a new binding and write new protocol implementations, or drop existing code
into an existing source base?

I don't think it's a tremendous amount of work or anything, but I'm not sure
I see the win in turning a Jabber server into a SAML authority/responder
rather than simply adding SAML request processing to its feature set, the
same as a web server or any other application server.

Putting this another way, if you wanted to integrate with LDAP, would you
make the Jabber server issue LDAP queries or create LDAP over XMPP? I assume
the former, and SAML attribute authorities aren't fundamentally different.

FWIW, if you did do it, I'd highly advocate an existing SOAP-based approach,
if you have one. It seems easier to define the binding as just a SOAP
binding for XMPP, since the SAML/SOAP part is already spelled out.

-- Scott