Shibboleth Developers

[Ian Young <>]

Scott Cantor wrote:

> I guess I would advocate we build an API for this, presumably just a
> KeyResolver API which I already have, but implement it with metadata for the
> time being.

For what it's worth, I think this is the right approach.  It might make 
sense to get more sophisticated later in terms of where the information 
is stored and how it is retrieved, but that's why you're proposing an 
API *and* an implementation, rather than just an implementation, right?

> The problem with that is simply the point I raised above...once
> we do that, the path validation stuff quickly becomes stupid to use.

I think you've argued something very similar before given that you can 
already use the keys-in-metadata approach for signing keys and the 
benefits of PKI in that situation are already arguable.  I don't think 
that the presence of one facility that can't use PKI will change the 
parameters of that discussion very much: after all, you can't assume 
that everyone will be using that facility so the logic won't be the same 
for every reader.

(from another message)

> it's likely that the
> long term implication is we end up encouraging federations to dump the CA
> approach.

I'm with Keith on this one: if that's the way it plays out, so be it.

Even if keys-in-metadata does turn out to be how things work out, 
though, I wouldn't anticipate it happening soon; any existing production 
federation will take a while to adopt that posture and then 
transitioning will require a whole lot of administrative and technical work.

It might, actually, be interesting to think about how one could manage 
such a transition.  Does the current codebase "do the right thing" in 
the presence of both an explicit key in the metadata and a key reference 
in the form of a key name?  For example, does adding the explicit 
material shortcut the path validation?

        -- Ian