<html>

  <head>

    <meta content="text/html; charset=windows-1252"

      http-equiv="Content-Type">

  </head>

  <body bgcolor="#FFFFFF" text="#000000">

    <p><br>

    </p>

    <br>

    <div class="moz-cite-prefix">On 9/20/16 9:24 AM, Tom Scavo wrote:<br>

    </div>

    <blockquote

cite="mid:CAEtu=dNWgbpBkDvVodaz97vE1yAfjLOSaHfTdtuJ1zX+=-Oo6w@mail.gmail.com"

      type="cite">

      <pre wrap="">Looking at the doc for IdP V3 DynamicHTTPMetadataProvider:

<a class="moz-txt-link-freetext" href="https://wiki.shibboleth.net/confluence/x/o4AgAQ">https://wiki.shibboleth.net/confluence/x/o4AgAQ</a>

Can the base URL for the MDQ protocol start with <a class="moz-txt-link-rfc2396E" href="file://">"file://"</a>, </pre>

    </blockquote>

    <br>

    No.  As its name suggests, that one is all about HTTP.   Not even

    sure how you would expect plugging a <a class="moz-txt-link-freetext" href="file://">file://</a> one into the MDQ option

    would work, since AFAIK MDQ is defined entirely in terms of the HTTP

    protocol.<br>

    <br>

    <blockquote

cite="mid:CAEtu=dNWgbpBkDvVodaz97vE1yAfjLOSaHfTdtuJ1zX+=-Oo6w@mail.gmail.com"

      type="cite">

      <pre wrap="">that is,

does the metadata provider support file-based metadata retrieval?

</pre>

    </blockquote>

    <br>

    The HTTP one doesn't, and won't.  But there is a concrete plan for a

    "local dynamic" one to resolve from a local filesystem.  It's

    probable that it will be in 3.3.  You'll configure it with a base

    directory, and then the metadata is resolved as the file content of

    that directory.  Individual entity descriptor files will be named

    using a function-based transform of the entityID, by default the

    SHA-1 hash.<br>

  </body>

</html>