Shibboleth Developers

["Scott Cantor" <>]

> FWIW, we at UW could get by just fine with the "MetaData Alone"
> implementation, and just bag all the CA stuff.
> 
> Any SP wanting any useful information will have to register with
> us anyway.  We can get its public key then.  If it uses a cert
> from our own CA then we already have the key.  We already implement
> pubcookie this way.

With a PKI hierarchy as small as almost any in real use, it is a small
optimization to use a CA with this, and most of it is due to there being no
tools to maintain the XML files. Hand-entering keys is painful and error
prone.

I think the issue here has to be, is that a sufficient reason to go off and
do a lot of work, or are there real likely deployments in which the PKI is
actually non-trivial. And in the former case, shouldn't the work be better
spent on metadata tools?

The number of people that will use the PKI code for anything important is
probably tiny. But we already implemented some of this and InCommon and
others are using it, despite the fact that nothing is really gained doing
it. So the uncomfortable problem is that we'd be removing functionality
that's in use.

I'm still mildly in favor of removing it, because I think PKI simply isn't
usable and my time is better spent on things that are. But we have to
decide. Having misunderstood Howard, I now believe that the only other
option here is where we are now, standard path validation plus making sure
that roots don't have to self-signed, which is legal anyway.

-- Scott