<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 1/27/16 6:21 PM, Janusz Ulanowski
      wrote:<br>
    </div>
    <blockquote cite="mid:56A950F2.5000109@heanet.ie" type="cite">On
      27/01/16 23:12, Brent Putman wrote:
      <br>
      <blockquote type="cite">
        <br>
        <br>
        Supporting it would probably be very easy, I think.  Whether or
        not it's
        <br>
        a good idea (security-wise, etc).... I don't know.  That's
        beyond my
        <br>
        Javascript.  I guess if it's turned off by default, and the
        consumer
        <br>
        takes responsibility for doing the right thing, then maybe it's
        ok.
        <br>
        Maybe the main concern would be about exposing the IdP data to
        pages
        <br>
        that don't live on the SP itself...?
        <br>
        <br>
        <br>
        <br>
        [1] <a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/JSONP">https://en.wikipedia.org/wiki/JSONP</a>
        <br>
        <br>
        <br>
        <br>
      </blockquote>
      <br>
      I'm not sure if there is security concern - if DiscoFeed is
      enabled you can still get the list with a direct request. To me
      it's just other way to represent data and for client is even more
      secure (AFAIK).<br>
    </blockquote>
    <br>
    That's true, there might not be issues with the IdP data itself
    exposed, since it's (I think) already public by virtue of the
    DiscoFeed.<br>
    <br>
    But I was thinking mostly of all the complex front-end web security
    stuff one has to think about.  The threat(s) are really to the
    application consuming the disco feed. It's basically being handed
    back a Javascript function which it just executes. If there were a
    bug in the SP, or other mechanism by which to insert malicious code
    into the JSONP feed, then the consuming page has to be concerned
    about things like that.  For that, there's all the CSP [1] and CORS
    [2] stuff to consider, which are also beyond my Javascipt, but I
    know they're there and what the general concerns are.<br>
    <br>
    But those are going to implemented (I think) at the web server level
    (i.e. send back headers) and so not really with what the SP is
    directly concerned. So maybe it would just be an "implementor
    beware" thing - using such JSONP support would mean you need to know
    what you are doing....<br>
    <br>
    [1] <a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/Content_Security_Policy">https://en.wikipedia.org/wiki/Content_Security_Policy</a><br>
    <br>
    [2] <a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/Cross-origin_resource_sharing">https://en.wikipedia.org/wiki/Cross-origin_resource_sharing</a><br>
    <br>
    <br>
    <br>
  </body>
</html>