<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 5/6/20 9:14 PM, Lohr, Donald wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:bcde5c62-d86e-77dd-9bfb-6a19c22f2dd5@jmu.edu">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <br>
      The first url returns this message in a web browser and does not
      load the metadata:<br>
      <br>
      <tt>XML Parsing Error: prefix not bound to a namespace</tt><tt><br>
      </tt><tt>Location: <a class="moz-txt-link-freetext"
href="https://it-federation-dev.jmu.edu/idp/pub/it-federation-dev-metadata.xml"
          moz-do-not-send="true">https://it-federation-dev.jmu.edu/idp/pub/it-federation-dev-metadata.xml</a></tt><tt><br>
      </tt><tt>Line Number 5, Column 13:</tt><tt><br>
      </tt><tt>            <shibmd:Scope
        regexp="false">jmu.edu</shibmd:Scope></tt><tt><br>
      </tt></blockquote>
    <p><br>
    </p>
    <p>I used curl to download that file in its pristine form and, <b>it
        has no namespace declarations whatsoever</b>.  It does not even
      have namespace decls for the standard ones like SAML and XML
      Signature.  It is utterly invalid.  I don't know where/how you got
      it, it doesn't come from Shibboleth software.</p>
    <p>Additionally, as I alluded to in my original response, the
      Shibboleth software does not publish anything at /idp/pub like
      that.  Whatever is being done there, it's something that is local
      to your deployment.  Did you perhaps inherit this from someone
      else?  We do not and can not know where that file is coming from,
      or how it's being published like that.<br>
    </p>
    <p>You'll need to figure out what is going on in your local
      environment and configuration with respect to this URL and file. <br>
    </p>
    <br>
    <p>
      <blockquote type="cite"><br>
        The second url returns this message in a web browser, but loads
        a metadata file:<br>
        <b><br>
        </b><tt>This XML file does not appear to have any style
          information associated with it. The document tree is shown
          below. </tt><br>
      </blockquote>
    </p>
    <p><br>
    </p>
    <p>Just guessing that that is:
      <a class="moz-txt-link-freetext" href="https://it-federation-dev.jmu.edu/idp/shibboleth">https://it-federation-dev.jmu.edu/idp/shibboleth</a><br>
    </p>
    <p>That one seems at least seems to be valid XML.  That's the URL
      for accessing the "starter" IdP metadata file that our software
      does know about: idp.home/metadata/idp-metadata.xml</p>
    <p><br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
      cite="mid:bcde5c62-d86e-77dd-9bfb-6a19c22f2dd5@jmu.edu"> <br>
      3) On the only Shibboleth SP (3.1.0) server we are testing with
      running the shibd -t command returns the following message:<br>
      <br>
      <tt>2020-05-06 21:03:10 ERROR XMLTooling.ParserPool : fatal error
        on line 5, column 42, message: <b>prefix 'shibmd' can not be
          resolved to namespace URI</b></tt><tt><br>
      </tt><tt>2020-05-06 21:03:10 ERROR OpenSAML.MetadataProvider.XML :
        error while loading resource (<a class="moz-txt-link-freetext"
          href="https://dummy.jmu.edu/idp/pub/dummy-metadata.xml"
          moz-do-not-send="true">https://dummy.jmu.edu/idp/pub/dummy-metadata.xml</a>):
        XML error(s) during parsing, check log for specifics</tt><tt><br>
      </tt><tt>2020-05-06 21:03:10 WARN OpenSAML.MetadataProvider.XML :
        adjusted reload interval to 600 seconds</tt><tt><br>
      </tt><tt>2020-05-06 21:03:10 CRIT Shibboleth.Application : error
        initializing MetadataProvider: XML error(s) during parsing,
        check log for specifics overall configuration is loadable, check
        console or log for non-fatal problems </tt><tt><br>
      </tt><br>
    </blockquote>
    <p><br>
    </p>
    <p>Any namespace-aware XML parsing software is going to fail with
      the exact same type of error on that first /idp/pub URL.  It's
      fundamentally broken.<br>
    </p>
  </body>
</html>