Attendees: Giuseppe, Heather, Ivan, John P, Hannah, Christos Regrets: Scott Note: 0 - Agenda bash 1 - Status of architecture documentation All this started around the idea of middleware; these will be a configurable set of things. Ivan continues to develop his ideas on this, has not yet started writing these down. Will also be creating an identifier for any request that comes in; that will allow us to mark requests as unsolicited as needed, and change how we process it. Microservices look like middlewares, just not at the network level. Alternatively, may start developing something called interceptors instead of middlewares; Ivan still investigating the possibilities. Look to the wiki space in Satosa GitHub for upcoming documentation. May also be creating diagrams (using https://plantuml.com/)  that will explain at least part of the flow. We still need better basic documentation to get people started; problem is Satosa is so complicated, it’s hard to put together good documentation. In terms of diagrams, Ivan is also looking at: - https://www.websequencediagrams.com/ - https://plantuml.com/ - https://app.diagrams.net/ - http://blockdiag.com/en/blockdiag/index.html - https://www.lucidchart.com/ - https://www.gliffy.com/ - https://creately.com/ - https://miro.com/ One question about using signals to help automate the documentation, but that won’t work for Satosa, which doesn’t use a framework that would support that. Note that Rainer created some graph diagrams for Satosa as well about a year ago ( https://github.com/IdentityPython/SATOSA/pull/263) 2 - GitHub review    a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc)    b. Satosa - https://github.com/IdentityPython/SATOSA https://github.com/IdentityPython/SATOSA/pull/322 People are bookmarking the discovery service as their initial landing page to a service, but that leaves the SAML backend confused as to which front end the discovery service belongs to in that scenario. Scott, Ivan, and Matthew have talked about whether the backend should have its own discovery flow. We would need to define a list of strategies on where to get the target service, and the backend would need to make that part of the context so the front end would know what to pick up and send back to the service. This is doable, but not trivial to code. Could throw an error that lets the user know they need to start at whatever service they want to go to. Not sure this would work either, because the user may well not know the URL to the service URL. Alternatively, have a generic landing page that contains links to all the services and let them pick from there. This page would be created by the deployer, and not automatically generated by Satosa. Can be implemented in the same way that the unhandled exceptions will be handled. Ivan will need to finish writing up and then implementing middleware, and then we can work on this issue.    c. pySAML2 - https://github.com/IdentityPython/pysaml2 Ivan has been looking at refactoring name_id_format (https://github.com/IdentityPython/pysaml2/issues/669) Ivan has a patch, but it is a breaking change. New option is called name_id_policy_format. The policy format specifics what happens with an authN request is created, and the name_id_format options is only used to define what’s in the metadata. Name_id_format can have multiple values (the order of the values matter) while the name_id_policy_format only takes a single value which, if not specified, will not be set. The “none” string is now gone. Ivan plans to do a non-breaking release first with some other changes, and then will introduce this breaking change. Also looking at https://github.com/IdentityPython/pysaml2/pull/628 that will allow us to disable weak algorithms. This is a good initial step, but it’s not really enough. pySAML2 defines different algorithms that it knows how to work with, as does xmlsec. We currently ask xmlsec to give us that list, getting a different set depending on xmlsec version, and then we compare it to what pySAML2 knows how to handle. If we follow this pattern, we will need to update pySAML2 with the list of what it can handle. Alternatively, we can store a restricted last that will focus on what to disable, rather than what to support. The trick is that we need the proper namespace names out of xmlsec rather than the short names we get now. We also need to define proper defaults (right now, the default is SHA1). We should disallow md5. Hopes to have something by the end of the week that will get us moving in the right direction by configuring the choice of algorithms.    d. pyFF - https://github.com/IdentityPython/pyFF 3 - AOB Thanks! Heather