<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 5/19/15 8:50 AM, Cantor, Scott
      wrote:<br>
    </div>
    <blockquote cite="mid:CBD23152-376F-4572-B982-026B5737972D@osu.edu"
      type="cite">
      <pre wrap="">
I don't think anything in OpenSAML is prescriptive about how you want to implement your software design.</pre>
    </blockquote>
    <br>
    I'd agree, although there is a certain design and intended usage
    behind the messaging API stuff.<br>
    <br>
    <blockquote cite="mid:CBD23152-376F-4572-B982-026B5737972D@osu.edu"
      type="cite">
      <pre wrap="">

</pre>
      <pre wrap="">
In the IdP, a ProfileRequestContext is itself an InOutOperationContext and we bootstrap it at the beginning of each webflow.</pre>
    </blockquote>
    <br>
    I think would be the same in a non-SWF impl.  Conceptually it's
    pretty simple.<br>
    <br>
    <blockquote cite="mid:CBD23152-376F-4572-B982-026B5737972D@osu.edu"
      type="cite">
      <pre wrap="">

An SP, which I haven't even thought about with this design, would have different requirements and probably only implements half-duplex context trees that either end with requests or start with responses, except for Logout or a couple of other rarely implemented protocols.
</pre>
    </blockquote>
    <br>
    <br>
    There's a similar problem with a client side impl like the SOAP
    client.  Some of the code that exists for things like resolving
    signature validation stuff is written as ProfileAction and assumes a
    PRC, so isn't directly usable for a client-side use case.  (This is
    the other major outstanding issue with completing the SOAP client,
    the other being client TLS. I'll be sending out another note about
    this).  I was going to look at whether it was feasible to refactor
    that stuff to be based purely on a IOOC, with the existing
    ProfileActions simply delegating somehow to the new components. 
    Otherwise we're going to have to duplicate code.<br>
    <br>
    I guess if we're going to get serious about a Java SP impl, we
    should factor that use case into all designs as well.<br>
    <br>
    <br>
  </body>
</html>