Shibboleth Developers

["Scott Cantor" <>]

> That's standards for you :-)

Actually, that's people for you. I have no problem with DDDS, I have a big
problem with sysadmins who think that their service exists only to provide
them stress-free employment. If it's not there to be leveraged, I don't know
why it's there. To the extent that it isn't made available for new uses, we
have no choice but to reinvent.

> Out of curiousity, why metadata in particular and not something else?

I think the answer lies in how metadata is defined. It's not "an XML file"
or a particular schema, it's just "the set of material that allows SAML
components to safely/securely interact at runtime".

The problem is that that, for obvious reasons, no existing trust
infrastructure was designed to do that. A CA infrastructure (even if one
existed that scaled) does not suffice because it leaves out endpoints,
capability negotiation, and other things. The metadata schema was designed
to do these things as well as exchange trust material (but only in a very
simplistic way).

Note that I think DNS can do all this too (see above).

> I appreciate the desirability of eliminating the dependency on PKI (user
> confusion, CA fickleness, etc), but PKIX is one trust system of many. Is
> this an operational concern (simplest to keep entity configuration and
> trust in one place?) or something else?

I think that experience has shown that operationally, yes, it is much easier
if all of the material is unified. But even more than that, it's a design
consideration.

We have dozens or more implementers out there completely left to their own
devices as to how to "make SAML work" and you can write OpenID, WS-Fed, or
Cardspace into that sentence as well. We're all trying to find a coherent
way to architect the stack so that we don't preclude what people want to do
but at the same time interoperate reasonably. So far, this is the best
option I've seen for separating concerns.

-- Scott