<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>
    </p>
    <div style="-en-clipboard:true;">Attendees:
    </div>
    <div>Christos, Johan L, Roland, Heather, Martin, Ivan, Rainer
    </div>
    <div><br>
    </div>
    <div>Notes:
    </div>
    <div>0. Agenda bash
    </div>
    <div><br>
    </div>
    <div>1. Introductions (if needed)
    </div>
    <div><br>
    </div>
    <div>2. Project review
    </div>
    <div>- Satosa (Satosa PRs - <a
        href="https://github.com/IdentityPython/SATOSA">https://github.com/IdentityPython/SATOSA</a>)
    </div>
    <div>Roland still waiting to hear from Ivan on creating a federation
      aware front end to satosa; they will discuss at a f2f meeting next
      week. 
    </div>
    <div><br>
    </div>
    <div>Many things are on the list. Ivan has been working on the
      configuration options, which have been intermixed with config
      options for pySAML. The way we specify how we want to sign an
      assertion is also messes up with the other options. Satosa should
      only dictate what values go to the configurations and pySAML
      should handle the encryptions. Ivan will roll out the small
      changes separately, then will later start deprecating the current
      options in Satosa and only use the pySAML options. Ivan will
      discuss this further with Johan. 
    </div>
    <div><br>
    </div>
    <div>After the options are sorted out, will work on logging (which
      will also impact pySAML - want to use the same logger, using the
      same format, throughout the whole stack).
    </div>
    <div><br>
    </div>
    <div>Martin has an issue regarding creating a better, default/common
      template for direct user interfacing. This starts again through
      pySAML and how it handles exceptions; this needs to surface up to
      Satosa for interpretation, otherwise Satosa doesn’t actually know
      anything about this. Does Satosa actually need to handle the
      error, or can it just present a static  error page? Maybe. Rainer
      points out that SAML has an error URL in metadata; it shouldn’t be
      the responsibility for a transparent proxy to engage in user
      interactions. Ivan suggests that the error should be in a JSON
      format that can be presented to something else for handling (e.g.,
      display or redirection, etc)
    </div>
    <div><br>
    </div>
    <div>Instrumentation discussion: instrumentation is different than
      error handling; it is more like log handling. Ivan will probably
      define various stable things during execution (e.g., PID,
      statistics of system, request ID) and then provide more context as
      things are processed. The logging will (probably) be in JSON
      format. This is higher priority than error handling. If we go
      forward with structured logging, we have more options for
      monitoring the service. 
    </div>
    <div><br>
    </div>
    <div><br>
    </div>
    <div>- pySAML (<a href="https://github.com/IdentityPython/pysaml2">https://github.com/IdentityPython/pysaml2</a>)
    </div>
    <div>PR 485 - may be able to do this in a more efficient way, but it
      works as is. Ivan will likely refactor in a future release. In
      particular, handling redirect binding request with Satosa.
    </div>
    <div><br>
    </div>
    <div>Other small changes around general code quality, and updates on
      examples to make them work with Python 3. It is a big question
      about moving from Python 2 to Python 3 exclusively. Python 2 will
      no longer be updated past 2020 (see <a class="moz-txt-link-freetext" href="https://pythonclock.org">https://pythonclock.org</a>).
      Would like to reach out to other projects using pySAML; there is
      something in GitHub (<a
        href="https://github.com/IdentityPython/pysaml2/network/dependents"
        style="font-size: 13px; color: rgb(49, 51, 53); font-family:
        Helvetica; font-stretch: normal; font-style: normal;
        font-variant-caps: normal; font-weight: normal; line-height:
        normal;">https://github.com/IdentityPython/pysaml2/network/dependents</a>)
      that would help with this, but that list needs to be cleaned up.
      Can there be a deprecation warning that appears during pySAML
      upgrades? Not sure; Ivan will follow up. Alternatively, put a
      warning in the install log and have the install fail, redirecting
      the user to another package. 
    </div>
    <div><br>
    </div>
    <div>PR 556 and PR 548 and Issue 549 - name handling. Ivan will be
      going forward with this, but via a transition phase. Some changes
      will be made to make warnings surface. 
    </div>
    <div><br>
    </div>
    <div><br>
    </div>
    <div>- pyFF (<a href="https://github.com/IdentityPython/pyFF">https://github.com/IdentityPython/pyFF</a>)
    </div>
    <div>Martin opened two PRs for pyFF last week. Reloading metadata,
      and fixing the command line parser. 
    </div>
    <div>Leif is still working on splitting the pyFF code to separate
      the discovery component from the metadata handling component. 
    </div>
    <div>Still hoping that Leif moves away from CherryPi to flask.
    </div>
    <div><br>
    </div>
    <div><br>
    </div>
    <div>- Governance docs (<a
        href="https://github.com/IdentityPython/Governance">https://github.com/IdentityPython/Governance</a>)
    </div>
    <div>Had the first governance meetings. No hard decisions yet, but
      hopefully by the next meeting we will have decisions re: the CLA
      and the IPR home. Notes are in the mailing list archive (<a
        href="https://lists.sunet.se/pipermail/idpy-board/">https://lists.sunet.se/pipermail/idpy-board/</a>). 
    </div>
    <div><br>
    </div>
    <div><br>
    </div>
    <div>3. AOB
    </div>
    <div>TIIME - Rainer has reserved a room for us. 
    </div>
  </body>
</html>