signing IDP metadata

Herron, Joel D herronj at
Thu Apr 28 23:46:12 UTC 2022

Thanks peter, that’s what I assumed.

I wish we could just use the incommon MDQ service, but in the infinite wisdom of this former maintainer we have two entity IDs one for incommon which only 5% of our SPs use and our primary  which is fed by this custom aggregator/generator. Yeah it’s a mess.


From: users <users-bounces at> on behalf of Peter Schober via users <users at>
Date: Thursday, April 28, 2022 at 4:28 PM
To: users at <users at>
Cc: Peter Schober <peter.schober at>
Subject: Re: signing IDP metadata

* Herron, Joel D <herronj at> [2022-04-28 23:12]:
> The previous implementor of our IDP signed both of our
> idp-metadata.xml files (standard and 4096 certs) with a custom xml
> generator which I’m looking to retire.

If you wanted to keep signing (see below9) you can always use
or the SP's samlsign or other "non-custom" tools.

> Is this a common practice?  I’m not seeing anything in the
> documentation that suggests that’s a something to even consider
> doing. I can see the benefits in theory but that would require SPs
> to actually check the signing.

This. Also, you'd want to sign+expire[1] then, meaning you'd
periodically (e.g. daily) add/set EntityDescrptor/@validUntil a few
days/weeks into the future, sign and publish.

But why self-publish your IDP's metadata at all? I.e., why not point
the SP to the *signed*, constantly *updated* copy of your IDP's
metadata in InCommon's MDQ service?

> If I were to not sign it going forward I assume the risk would be if
> some SP actually implemented the signing check it would fail for
> them.

Highly unlikey as that would break the service for all their
non-signing customers (i.e., the other 99.9999%). ;)

For Consortium Member technical support, see
To unsubscribe from this list send an email to users-unsubscribe at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list