<div dir="ltr"><div dir="ltr">hi,</div><div dir="ltr"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The MDQ is great for IdPs to fetch metadata for SPs on the fly, but the reverse isn't ideal.  SPs need to know all IdP metadata up front in order to provide discovery and the MDQ doesn't really work for that.  The result is that if an SP is to accept logins from any federated IdP, it needs to load a large metadata file.  Luckily InCommon (and maybe others) provide an IdP-only variant, but its still huge.<br></blockquote><div><br></div><div>An SP needing to preconfigure or offer discovery , based on metadata, can use the metadata (and InCommon provide an MDQ 'feed' of all the IdPs - which is also much much faster to get than the old legacy metadata file (!) ) - whilst also allowing their SP to use the MDQ feed itself - to massively improve startup/restart times but also memory usage.   you then have the best of both worlds - as the service will only offer IdPs that are known/configured and the SP SAML stack will be more performant and happily deal with those IdPs when started with eg the SP initiated flow, as it's got them via its MDQ config.</div><div><br></div><div>alan</div></div></div>