Un-scoped Microsoft IdPs and ePPN

[Scott Cantor]

> On Jan 20, 2026, at 8:50 AM, Allan West via users <users at shibboleth.net> wrote:
> 
> Other than maintaining a separate, scoped copy of the remote IdP's metadata, is there a programmatic way to assert a scope on behalf of these IdPs?

We don't have a metadata filter for adding the Scope extension, but we should. We do have local filtering rules that can be added on a per-issuer basis to apply a specific rule, but that would also require turning off the metadata-based rule for those issuers, so it's awkward.

And nobody has ever requested one either, so there's that. Not requesting something is how it gets repeatedly forgotten and falls off our list every release. That's more about the IdP of course as the SP is frozen in this form.

I might be able to manage to slide something into 5.2 so it's there for the SP, I only have a couple of days to get it in though.

Having said that, I have to repeat the plain fact that it is patently impractical to safely consume self-asserted metadata. Metadata has to come from a third party federation under a signature and any remote metadata outside of that context will usually be wrong at best and insecure at worst.

Leaving trust aside, OpenID gets away with self-hosted metadata only because it's operationally baked into the spec such that if you get it wrong, you probably won't interop well with RPs. SAML just doesn't have that property.

The point of a filter would be override a proper source of metadata in cases where it was required (e.g., a federation that didn't support the extension), not allow improper ones to be used safely.


-- Scott