Shibboleth Developers

[Jim Fox <>]

> > 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.

From the discussion of x509 support I'd say that's "painful and error
prone" as well.  We automate the maintenance of the trust files anyway,
so, for us at least, there's little difference.  I suspect that most
sites will do likewise sooner or later.

There are probably good reasons to keep the path validation stuff,
but concern for hand-editing shouldn't' be one of them.

Jim


> 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