Shibboleth Developers

[Scott Cantor <>]

> Naturally, we still need to work out the format for AQMs and ARMs (i.e.,
> the SAML binding for Jabber/XMPP). But I think the preceding scenario
> would work if we add a SAML module/plugin to the server and whichever 
> components need to do SAML (groupchat, publish-subscribe, et al.).

Maybe I'm confused, but this seems off. There's already a SAML binding that
works for basic synchronous query/response, and since defining new bindings
is a harm to interop, it hasn't been done since the original one was
defined. Not to say it'll never happen, but it will have to be something you
can't do with SOAP/HTTP.

If you're doing an Attribute Query, it's not a message between two jabber
entities, it's a SAML client and a SAML authority. We shouldn't need any new
protocol work for this.

The model I think you want to achieve is for the user to get a credential of
some sort (could be a SAML authentication assertion, but doesn't have to be)
delivered to the chatroom that enables the chatroom to either directly
evaluate its authz policy, or perform a query for a different assertion
(such as attributes) so that it can.

Additionally, the benefit we want here is trust delegation. Rather than
having the jabber servers trust each other directly, the goal is to let the
chatroom trust only the SAML authorities (via a federation, bilateral trust,
or whatever) and then it can use that trust fabric to allow the other server
to talk to it about a user. Otherwise, you have to implement n x n trust
relationships among all the application servers, and federations don't
really buy you much.

-- Scott