Shibboleth Developers

["Scott Cantor" <>]

[sending this to shib-dev, as I'd like to try and get more of this type of
coding discussion happening in the open]

I don't want to make this a priority, because I think the viability is
unproven, but if for the sake of argument it really makes sense to think
about this, I'm not sure if the Provider/Resolver split is the best way for
this to work.

If I imagine what a URL-based Resolver would look like, it's different from
what we'd call a URL-based Resolver now, since that takes a static URL or
file and returns a dynamic set of entities (i.e. the federation type stuff
now).

With dynamic lookup, the URL is the entity. So you'd really have just one
Resolver instance, I think, whose job was to do the lookup based on the ID.
So does it even make sense to think about "pre-loading" the cache? I don't
think so.

It seems like, as in the old code, what you have with the Provider is a
wrapper around a bunch of prospective resolvers, each of which would offer
the basic lookup() method. If I hand some dynamic ID to the Provider, I
would expect it to just invoke the Resolvers in turn until it found the
answer, and at some point that would hit this single "dynamic" Resolver,
hand it the ID, and if by some magic that worked, you'd get back (and could
cache) the result.

I don't see any obvious way for it to work the way the current API is
factored, since it assumes that you can get the metadata "ahead of time", I
think.

-- Scott