<div dir="ltr">We've drunk the "metadata driven" philosophy that is facilitated with IdPv3, but we've run into a problem: we drive many of our attribute release policies with entity attributes that we can't control in some metadata sources. We're using the metadata filter approach today to apply the attributes after the metadata is loaded from the source:<div><br></div><div><div><MetadataFilter xsi:type="EntityAttributes"></div><div>  <saml:Attribute Name="<a href="http://login.vt.edu/attribute/bundle">http://login.vt.edu/attribute/bundle</a>"></div><div>    <saml:AttributeValue><a href="http://login.vt.edu/attribute/bundle/vtid">http://login.vt.edu/attribute/bundle/vtid</a></saml:AttributeValue></div><div>  </saml:Attribute></div><div>  <Entity><a href="https://foo.example.edu/shibboleth">https://foo.example.edu/shibboleth</a></Entity></div><div></MetadataFilter></div></div><div><br></div><div>That configuration is in metadata-providers.xml, which isn't subject to the hot reload facility that we have grown to love in IdPv3. Besides, it defeats the strategy of moving the most common configuration points solely into metadata.</div><div><br></div><div>What I'd like to do is define stub metadata entries that have the needed attributes in a metadata source I control and have it merged with the canonical entry from another source. I guess you'd need a couple of different merge strategies (append and replace at a minimum), but it seems like it would solve my problem in a way that preserves the operational goal of being entirely metadata driven. Is that a good idea? Have I missed an obvious alternative solution that's available today?</div><div><br></div><div>Thanks,</div><div>Marvin from Virginia Tech</div><div><br></div></div>