XML Parsing Error: prefix not bound to a namespace

[Cantor, Scott]

On 5/7/20, 8:47 AM, "users on behalf of Mak, Steve" <users-bounces at shibboleth.net on behalf of makst at upenn.edu> wrote:

> Iif that is what this email thread plays out to be what our issue is?

Well, it just speaks to a lack of care and planning around a strategy for metadata. It also suggests you may want to spend a bit of time on an XML basics site. XML expertise is an absolute requirement to run Shibboleth, it's a total disaster for anybody without that.

Everybody has their own strategies.

The vast majority of commercial and cloud SPs have poor or non-existent metadata support. The ones that do I point at InCommon, and certainly the MDQ service now, but the fact is that doesn't even work for ADFS because it's so broken, so there's just not a lot of options for most of them. I have them carefully documented as broken, I lock our signing key for those systems so that it won't change if I change the default key, and just generally have a strategy in place for managing all of them as best I can. I had to, we have over 100 of them.

For campus SPs using Shibboleth or other compliant code, I maintain an on-campus metadata file I sign with a long term key I've used since 2004 and that is used as a trust root. That file has nothing to do with our IdP deployment other than it's hosted on the same web server. I do that so I can make alterations for on-campus behavior that don't immediately impact InCommon services.

There is no value whatsoever in using the /idp/metadata trick, which is why we need to deprecate it. If people want to host metadata there they can slap a file in the static tree of the webapp and call it "metadata" if they want.

Unsigned metadata, metadata with no validUntil, etc, are all worthless or actively harmful in my opinion. Others have different opinions.

https://wiki.shibboleth.net/confluence/display/CONCEPT/TrustManagement

-- Scott