Shibboleth Developers

[Thomas Lenggenhager <>]

Ian Young wrote:
> Scott Cantor wrote:
> 
>> [sending this to shib-dev, as I'd like to try and get more of this
>> type of
>> coding discussion happening in the open]
> 
> Odd to think I'm the first person to comment on this, but maybe the
> context is sufficiently arcane for most people to have no comment.  Or
> maybe I'm the only person who cares about dynamic metadata ;-)

Not really, I am interested in getting dynamic metadata as well.
However, I must confess, it was a challenge for me to understand these
lines of Scott. Now with comments from Ian and Chad it became more
obvious for me.

>> I don't want to make this a priority, because I think the viability is
>> unproven,
> 
> Per my comment in another thread, if we're talking about dynamically
> fetching individual entity metadata documents from the URL that is the
> entity's ID, we're probably mainly thinking about scalability.  And,
> most people aren't currently seeing scary scalability issues in their
> future just yet, so maybe they don't see this as worth worrying about
> just now.  I do see scary scalability issues in my future, though.

Me too.

> As to viability at a technical level, my biggest question is that I
> can't see how to combine the fetch-from-the-ID approach with an entity
> retaining its entity ID in multiple federations.  One issue is the
> signing question: the signature profile used in SAML metadata doesn't
> allow for multiple signatures on the same metadata, so how does the
> location being queried for metadata know which signed metadata to
> return?  Query parameters?  Client TLS authentication?  I don't think we
> know.  Unless we declare this a non-problem (and return to entities
> having different IDs in different federations) we'd need to profile
> something and obviously the contextual information you need to pass
> across for this operation would need to be available through the
> resolver API.

Getting the metadata signed for each federation would become a big
problem for content providers offering their service to many federations.
However, having a single entity singing all metadata is probably not the
right approach. But if each federation would decide on a rather small
set of 'trusted keys' accepted to sign metadata on behalf of that
federation, that might scale without CA-bridges.

>> 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.
> 
> If you're doing dynamic, you might be concerned that the first time you
> talk to an entity there will be a delay while you go off and fetch the
> metadata for it.  So, there might be a case for the API allowing you to
> pass in a set of IDs that should always be kept fresh, and reloaded
> whenever they became stale or expired.  You'd pre-load that set, of
> course, at startup.

Such a pre-loading of a limited set makes sense to me, to be able to
offer the most often used entities without any delay.

Thomas