
<html>

  <head>

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

      http-equiv="Content-Type">

  </head>

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

    <br>

    <br>

    <div class="moz-cite-prefix">On 4/8/16 11:09 AM, Cantor, Scott

      wrote:<br>

    </div>

    <blockquote

cite="mid:9846A6064BD102419D06814DD0D78DE1128B3B4F@CIO-TNC-D2MBX02.osuad.osu.edu"

      type="cite">

      <blockquote type="cite">

        <pre wrap="">Perhaps this is off-topic but will the dynamic metadata query (MDQ)

feature work against a base URL with scheme <a class="moz-txt-link-freetext" href="file://">file://</a> (as opposed to

<a class="moz-txt-link-freetext" href="http://">http://</a> or <a class="moz-txt-link-freetext" href="https://">https://</a>)?

</pre>

      </blockquote>

      <pre wrap="">

Don't know about the IdP, but I doubt the SP would (not to say it couldn't be made to). In fact, that's a really elegant way of implementing a "drop into a folder" model. 


</pre>

    </blockquote>

    <br>

    <br>

    For Java OpenSAML/IdP:  No, it doesn't currently do that, the

    concrete dynamic class is HTTP only.  Note that the IdP config

    schema reflects that, the type is "DynamicHTTPMetadataProvider".  So

    a filesystem-based one would need to be a different config (and

    concrete resolver class) anyway.<br>

    <br>

    However, the dynamic resolver abstract base classes were

    deliberately written such that implementing "dynamic" behavior for

    something other than HTTP resources would be easy.  I had already

    mentioned elsewhere, maybe dev list, that using this to implement a

    filesystem dynamic resolver with the "drop into a folder" model

    would be pretty easy.<br>

    <br>

    The main implementation issue that I know of is file naming. 

    Typical entityIDs (certainly all URLs, some URNs) aren't amenable to

    directly use as file names (depending on the operating system). 

    I.e. you can't literally have

    <a class="moz-txt-link-rfc2396E" href="https://sp.examle.org/shibboleth.xml">"https://sp.examle.org/shibboleth.xml"</a>, at least on Unix/Linux.  So

    you have to decide on a strategy about how to convert the entityID

    to a string that will be used as the filename.  An obvious one

    that's sure to always work would be a hex encoding of some

    digest/hash of the entityID. (I think openssl supports something

    similar for certs in a directory).  A better one would be something

    that still leaves it relatively human-readable.<br>

    <br>

    <br>

    <blockquote type="cite">

      <pre wrap="">Could you file that?</pre>

    </blockquote>

    <br>

    Also against IDP and/or OSJ.<br>

    <br>

  </body>

</html>